
Language Server Protocol implementation for Swift and C-based languages - Kryptoshi
https://github.com/apple/sourcekit-lsp
======
jclay
For anyone interested, here is their official announcement back in April 2018
on the LLVM mailing list about their vision and plans for the clangd updates.
As a C++ dev, I'm excited to see this tooling come to fruition. It's going to
make the IDE experience with Clang based tooling far superior on all
platforms.

[https://lists.llvm.org/pipermail/cfe-
dev/2018-April/057668.h...](https://lists.llvm.org/pipermail/cfe-
dev/2018-April/057668.html)

~~~
jclay
Related: It's an interesting time for C++ tooling in general. Based on
conversations with a member of the Visual Studio team, I've come to understand
they're responding to increasing competition from CLion. This was the driving
force behind the decision to prioritize first-class CMake support in VS 2017.
I also think they're taking notice of what's working well with VSCode and
taking that into account for VS 2019 updates.

I've moved away from it for my C++ needs since it's just so complex. The vim
extension works well, but beyond that I can't master any of the keyboard
shortcuts as they're so different than any other editor I've used in the past.
These days I use VSCode with VSCodeVim, cmake tools and clang-query (which is
fantastic). I've been really loving working with this setup. I fire up VS 2017
with `devenv my_proj.sln` when I'm lacking any advanced performance profiling
/ debugging features, but this is increasingly rare.

Overall, with the clang developments in the last few years, you can entirely
replace the MSVC tooling. PDB debugging, ABI-compat, etc. Now clang-query and
this work by Apple will ensure the IDE experience is taken care of too. The
competition is welcome.

~~~
pjmlp
Clion still has lots of catchup to do in mixed language debugging, GPGPU,
multi-threaded debugging, DirectX debugging, COM/UWP development.

From what I see on online discussions, clang still isn't as good as VC++ in
incremental compilation and linking support.

Then lets also see who gets modules first.

Interestingly we had Energize C++, Visual Age for C++ v4 (earlier versions
were different) and C++ Builder. Had they managed to win a sizeable
marketshare and such C++ nice productivity tooling would have been a thing
much sooner.

------
w-m
I was wondering whether that means that Xcode will adopt LSP as well and found
this article: [https://nshipster.com/language-server-
protocol/](https://nshipster.com/language-server-protocol/)

"Getting Xcode to use our new LSP service should make it viable to use other
LSP services as well, and it’s something that we are interested in, but we
don’t have specific plans to announce at this moment."

It would be great if this becomes reality. I currently hate switching
editors/IDEs for a project using several technologies, because e.g. Xcode is
great at C++ debugging but terrible at CUDA editing.

~~~
Joky
Maybe [https://forums.swift.org/t/new-lsp-language-service-
supporti...](https://forums.swift.org/t/new-lsp-language-service-supporting-
swift-and-c-family-languages-for-any-editor-and-platform/17024)

> We are also going to make the necessary changes for Xcode to use this new
> LSP-based language service. Similar to how you can load an OSS toolchain 397
> in Xcode to try it out now, in the future you will be able to load a build
> of the OSS LSP service in your installed Xcode and test any fixes or
> enhancements you make.

------
_asummers
The other interesting protocol in this space I only recently became familiar
with is the Debug Adapter Protocol or DAP [0]. Curiously it doesnt't seem like
there's a standard for test running though? Unless that's supposed to be an
LSP action of some sort.

[0] [https://microsoft.github.io/debug-adapter-
protocol/](https://microsoft.github.io/debug-adapter-protocol/)

~~~
Arnavion
>Curiously it doesnt't seem like there's a standard for test running though?

The code lens API allows you to register commands with code spans of your
choice. There's no specific built-in command for running tests, so it's ad-
hoc.

[https://microsoft.github.io/language-server-
protocol/specifi...](https://microsoft.github.io/language-server-
protocol/specification#textDocument_codeLens)

Eg for the Rust LSP server: [https://github.com/rust-
lang/rls/blob/ea7a0c36aa5f45846b06f8...](https://github.com/rust-
lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/requests.rs#L890-L903)
\+ [https://github.com/rust-
lang/rls/blob/ea7a0c36aa5f45846b06f8...](https://github.com/rust-
lang/rls/blob/ea7a0c36aa5f45846b06f81ab1f58a24a148f3e4/src/actions/run.rs#L39-L52)

------
mikewhy
> felt like something we all should of figured out years and years ago

Before language server there was YouCompleteMe, a plugin for Vim that had the
same ideas. It was eventually ported to other editors, but LSP wasn't far
behind and eventually took over.

I'm no good with Google Trends, but here they are:
[https://trends.google.com/trends/explore?date=all&q=youcompl...](https://trends.google.com/trends/explore?date=all&q=youcompleteme,%22language%20server%22)

~~~
nwah1
YouCompleteMe used fuzzy finding to create something like IntelliSense.

LSP is an API that talks to compilers, and returns actual relevant data about
the code you are working with, and in conjunction with the Debug Adapter
Protocol allows things like setting breakpoints in a standardized way.

EDIT: looks like YouCompleteMe did try to use OmniSharp and racer to provide
better support for certain languages, but it still is different than a
standardized protocol that any language could add support for without needing
to be included in a swiss army knife like YCM.

~~~
mikewhy
> LSP is an API that talks to compilers, and returns actual relevant data
> about the code you are working with

That's what YCM did as well. Well, compilers or other intellisense-adjacent
tools (like Jedi for Python, which Python's language server also used, or Tern
for JS).

~~~
nwah1
YCM includes various non-standardized static analyzers and such, and glues
them together to be a swiss army knife. LSP is a standardized API that
compilers can target, and that means there is no need for a middleware
component that does work.

------
giancarlostoro
Apple implementing a spec designed by Microsoft!?!?! Joking, I love that
Microsoft came out with LangServ though, felt like something we all should of
figured out years and years ago, good thing they wanted to make a cross
platform text editor :) I gotta give Microsoft their props, they hire some
really smart people who do some great things for the software industry.

Props to Apple for doing this too, I am looking forward towards the next
stages for the LangServ v4 spec, not sure what more they could do to make it
awesome, but I'm sure there's plenty that could happen in the future in this
space.

~~~
simonh
For me the takeaway is that Apple is _really_ serious about supporting the use
of Swift outside their own ecosystem. After all XCode won't be using this, at
least for a while, so clearly it's aimed at making it easier to use Swift
outside their own tool chain.

~~~
cm2187
It seems to be a very un-Apple thing to do. Do you know why they would want to
push it?

~~~
wlesieutre
Get more people using Swift serverside perhaps?

I can imagine that having a swift backend for your swift mobile app would be a
lot nicer to work with than converting back and forth from a bunch of
stringly-typed JSON.

~~~
kitsunesoba
Yes, this is it precisely. Swift already has decent momentum for serverside
usage with Vapor, Perfect, and Kitura among others. By adding LSP support,
Apple is adding to that momentum and pushing it closer to critical mass.

~~~
MR4D
I'd love to use Swift on the backend, but I don't want to use XCode.

I only develop part-time, as my main job is financial in nature, but god, it
is really hard to find good learning material for serverside without depending
on XCode. In particular, learning the server frameworks is almost not worth
it. By using one language, I can keep my productivity acceptable.

If anyone has any references, I'd be super thankful!

------
trevor-e
Swift is a really great language and I'm very bullish on it becoming popular
for server-side projects in the next few years, once they improve a few things
(namely performance gotchas and concurrency).

~~~
ken
I see two kinds of programming languages in the world. There are a couple
which were designed with a great concurrency model from the start, and there
are all the rest which weren’t. In these, concurrency remains awkward at best,
and seriously problematic at worst.

I have never seen any programming language retcon a good concurrency model
onto version 6. The actor proposal I’ve seen looks horrendously complex.

I try to be open minded about something I haven’t used yet but I really don’t
think this is something you can just bolt on.

~~~
trevor-e
I do agree with your point, however, I think Swift is in a unique situation
since they intentionally deferred on making concurrency first-class. Now the
language is in a much better position to implement a modern system.

What about the proposal is _horrendously_ complex? The target audience is
meant to be language designers, not the average developer. The actual
suggested API changes looked to be a few added keywords and some new
classes/protocols to use.

------
mikece
Language Server implementation for Swift... meaning that writing, compiling,
and debugging Swift (and Obj-C) in Visual Studio Code is just around the
corner? What other editors/IDEs use Language Server?

~~~
mikece
After Googling I see the list include Eclipse, IntelliJ, vim, and Sublime Text
and VS Code with Atom and emacs in progress.

[https://langserver.org/](https://langserver.org/)

~~~
nindalf
I feel like that page might not give the full picture. I see language servers
that are green on all 6 columns but don't work very well for even medium sized
projects. Still, I'm super excited about the work being done here. It's only
going to get better.

~~~
thangngoc89
That table only shows that the languge server supports the feature, Whether
it's stable or not depends on the language server implementation. You should
report to your language server implementor about the instability

------
sgt
I love the momentum around Swift these days, and the LSP looks very
interesting.

------
beliu
Thanks to Apple for making this open-source. Looking forward to integrating it
into Sourcegraph!
[https://github.com/sourcegraph/sourcegraph/issues/1557](https://github.com/sourcegraph/sourcegraph/issues/1557)

------
linkmotif
I finally installed ALE in Vim this summer and have been so happy with it:
[https://github.com/w0rp/ale](https://github.com/w0rp/ale). Great even for
linters for JS. Always much easier than expected. Shouldn’t have waited so
long...

------
akhilcacharya
This is amazing, I was just wondering why this wasn't a thing a few weeks ago!
Can't wait for Swift to be a great general purpose language for me.

------
milin
This is very exciting! Does this mean it will be possible for users to write
swift using vim in a more painless way vs xcode?

~~~
willio58
I don’t believe vim is an IDE, so it won’t be on the same level, but I’ve been
writing Swift for websites in VScode for over a year now and using the command
line to compile the code.

