Really says something about Microsoft's evolution if you think about it.
I believe a prominent example is NVidia's CUDA compiler. As far as I understand this is just a modest fork of the Clang front end and a big new LLVM back end, and it's proprietary.
However Google has developed an open source alternative CUDA compiler, which is also based on Clang/LLVM: https://research.google.com/pubs/pub45226.html
Also I would have thought that Clang already has LSP support for C++, but maybe I'm wrong.
Previously they had proprietary compilers or gcc forks that they weren't that happy contributing back.
Now they can have their proprietary clang forks and don't contribute anything back.
Plenty of slideware examples at LLVM conferences.
On one side clang was great for improving the whole safety and tooling story for C and C++.
On the other side, if clang was available to Brad Cox, NeXT would never had released Objective-C to the community.
Actually the Stepstone "compiler" was a preprocessor that generated C (like cfront was for C++). Brad Cox never worked for NeXT.
The Objective C front end for gcc was written by Steve Naroff at Next. Later he and I persuaded Jobs that that front end should be merged into the official gcc tree, and so we (Cygnus) worked with NeXT to get merge them and, amazingly, produce Objective-C++ in the process.
Jobs was focused on the goal. When NeXT (and later Apple) were underdogs he was happy to embrace open standards (e.g. JPEG, MPEG, MPEG-3...) when it would help and outside proprietary standards when he thought it was needed (e.g. paid the rtf license).
References? Most of the "custom" compilers are based on some ancient version of gcc.
I haven't yet bumped into an embedded compiler that was clang-based.
> Plenty of slideware examples at LLVM conferences.
Well, the conference can obviously stop that, if they wish.
Not everything they do comes back to LLVM, it depends on the customer willingness to let it happen.
The team at Google published a paper in CGO 2016 detailing the optimizations they’d made to clang/LLVM. Note that “gpucc” is no longer a meaningful name: The relevant tools are now just vanilla clang/LLVM.
There is a Hello World program on that page, which looks good.
Ignoring it just because Micro$oft is attached is idiotic.
True, but to a casual observer it also sounds like something RMS might do.
- RMS' inability to accept that GCC might need to expose an AST to external consumers, and his paranoia regarding how that might undermine his GPL-everywhere ideals.
Using JSON for local IPC -- and requiring IDE language support to funnel itself across that high-overhead IPC connection -- is fey.
For compilers, M is source languages and N is target platforms. For LSP, M is source languages and N is editors.
They both have the same downside. The more esoteric the language feature, the lower the fidelity of support in the common middle.
If you insist on using IPC, then you've incurred a great deal of friction in a place that it matters.
If you insist on using JSON IPC, then you've incurred a great deal of overhead in a place that it matters.
The fact that the HN community seems to have jumped aboard this idea, "yeah let's just require a server to do something simple like format text in your editor", is completely flabbergasting. People just seem to have NO IDEA how much complexity they are adding, and don't care.
Maybe in 5 years our machines will be running 10,000 processes at boot because people will want a server for every operation...
This means that on every single change, a new heavyweight process is created, communication happens over unspecified textual formats, and everything is likely to break with the next update because there is no stable interface.
JSON IPC with a continuously-running process using a well-specified protocol is a huge step up in comparison.
Yes, serialization and communication has a lot of extra cost compared to a function call but consider that (1) the request rate is limited by user typing speed, which means around 10 requests per second tops, low enough that it won't matter, especially compared to running a type checker, (2) all the calls in LSP can take a very long time to complete, you won't be able to turn this protocol into blocking API calls that you do from the UI loop, because of this.
Even with a plugin you would need to run into a separate thread (or possibly threads) and cancel requests after a timeout.
That said, LSP is a terrible protocol. They chose to represent all offset in terms of UTF-16 (!) encoding units, which is truly retarded since most editors won't be reading UTF-16 files nor will they be representing them internally as UTF-16.
Wow, yeah, that's pretty terrible.
Not to mention that a lot of people capable of writing the tooling would struggle to export a C API. I write Scala in my day job and it would take me a while to learn how to do that - and I've done some programming in C/C++ before.
Suppose I have vim, and the Rust compiler. I want to add RLS level of support to vim. I download some vimscript plugin, and what? Do you distribute the rust language server as a compiled plugin that you add to the address space of the editor at runtime? And if there's a bug, and it segfaults, then it takes down my entire VIM process?
It seems like there's some complexity in directly calling the code with an API too. It's actually not to bad to just open a pipe and communicate.
Maybe I'm missing something, but wrangling compiled plugins seems like it'd be a bad time.
And as for your question, the answer is ... yes. Sure. Why not? That's what we already do in nearly all IDEs.
Are there any plugins which are binary compatible between more than one IDE? That seems hard.
Said no IDE user, ever.
> Are there any plugins which are binary compatible between more than one IDE? That seems hard.
No. And who cares?
Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily), and compiler implementation languages are even more diverse than editor implementation languages.
No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol. Building all kinds of crazy, complicated, slow infrastructure in order to get it to successfully speak some other protocol, is a symptom of modern-day clueless programming.
> Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily)
Yes, this is of course a good idea. Why one presumes this requires a separate running process, I have no idea.
This also involves a marshalling cost at the ABI boundary, which may be lower overhead than parsing JSON, but is significantly more brittle. And it's less ergonomic for many plugin/editor authors. And it can't be spec'd with a schema that isn't just "read the headers."
Only for some languages, and that cost should be far far less than running a separate process, shipping json over pipes, and parsing the json
> And it's less ergonomic for many plugin/editor authors
I think that many modern programmers find this more ergonomic than a C ABI is part of what he is complaining about. Let's get comfortable with what is good, rather than make what we are comfortable with?
> Let's get comfortable with what is good, rather than make what we are comfortable with?
I agree in the abstract! I just emphatically disagree with characterizing a C ABI as "what is good."
Why is it "significantly more brittle"? It is a well-specified interface. It is less brittle than talking over a socket because the kinds of points of failure involved with sockets don't exist in this case.
> And it can't be spec'd with a schema that isn't just "read the headers."
What does that even mean? It's a protocol just like any protocol, except you get the added benefit that for many languages it can be typechecked. Why are you claiming it can't be specified or that someone has to "read the headers"? What headers?
The fact that we're typing this, and it works -- without the entire world falling apart because of crashes in complex library code -- demonstrates why this is not remotely bonkers.
Well, different failure modes, maybe. If an external process crashes, then you just have your editor restart it. But if you've linked a library into your editor, and it crashes, then your editor crashes.
I much prefer either keeping that code in a separate process, or having that code written in a memory safe language, where it won't take down your editor when something goes wrong.
Agreed on JSON, though.
Those are separate libraries with support for C, C++, Clojure, Java, Kotlin, C#, JS, PHP, Python, and more.
All of them exposing the entire AST and the entire environment, which is far more than LSP ever did.
The question is important, because otherwise one would constrain editors to be written only in a language which is compatible to the library format.
But if you want a system where I have to transfer gigabytes via a JSON IPC bus every minute, sure. That’s totally not going to destroy performance in projects that are several millions of code long with major auto-generated assets.
The language server protocol is useless for larger interwoven projects. The same issue appears already with JetBrains Rider (a C# IDE where the C# parser is implemented in a separate process)
The fact that Resharper (which powers the Rider language processing bits) blocks the VS UI should tell you that this problem lies elsewhere.
The IDE has to always stay responsive, no matter what is happening, no matter how large the change is.
My current estimation is that the protocol costs are O(1) regarding project size.
Please read this article, which was previously on #1 on HN, and is from a developer who has implemented IDE support for a language by using LSP: https://perplexinglyemma.blogspot.de/2017/06/language-server...
The developer of the rust plugin for KDevelop said he had to rebuild half of the rust parser because the language server protocol is so completely inadequate that it can't even be used to implement half of KDevelops features.
Same with stuff like data stream analysis, how does the language server protocol let you mark a variable and see a graph of where it comes from, and how it's transformed? How do you get proper structural autocomplete?
For many features the IDE needs actual full access to the AST. The language server protocol doesn't provide that, so you have to reimplement half of the language server in your own IDE plugin. And it's far too slow.
The language server protocol is comparable in quality to Kate's language plugins, which is okay for an editor, but completely unacceptable for an IDE. You can't do proper structural refactoring either. Proper structural extraction, proper autocomplete or ast transformations, automated inline functionality across files.
For a lot of functionality you end up having to try and get the AST back from the autocomplete and cursor info that the LSP gives you to fill the IDEs internal data structures, which is ugly, painful, and slow.
However I disagree that LSP is completely unacceptable for IDEs. I work daily with VSCode and it's LSP based language support for Typescript, C# and others. The amount of IDE features that I get for Typescript is higher than what lots of real IDEs provide for their inbuilt languages. The quality of the LSP based addons seems mainly to depend on the implementation of the language servers and not on the protocol, e.g. the language server experience for TS is top-notch, the one for C# is OK-ish and the one for C++ is pretty weak.
I see no problem on integrating any-kind of auto-complete support through LSP: The IDE/Editor just sends the position inside a document which needs to be completed and the language server responds with all possible suggestions. There's absolutely no need to store an AST in the editor for that. The AST can stay in the language server for that. It's the same for references to types, refactoring commands, etc. Yes, if someone needs some non-standard "data stream analysis" the command and results for that might not yet be standardized in LSP - but they could be added if it's worth it for the users. And I guess one can also have non-standardized optional extension APIs between a language server and an editor. In the end it's the same: The editor asks the language server (which has full access to AST): Give me "a graph of where the variable comes from, and how it's transformed", and the language server responds in a well-defined way which the editor just needs to render.
And back to the article: The point of the article is not necessarily that a Rust Language Service plugin wouldn't be good enough for 90% of all users. From my point of view it's more that the author is excited about implementing language support themself in their preferred way and as perfect as possible. That's an absolutely reasonable thing. If one is interested in implementing type-interference for Rust or other complex languages themselves then I'm sure it's a great learning experience. However it will also be LOTS of work, which for a huge language as Rust might be outside of the scope which most mortal developers will be able to do in their private time. If the end result is a half-baked implementation for an IDE which is more buggy or has less features than a language-server based solution (which could be shared between multiple IDEs), then nothing has been won. The language server approach helps here in a way that instead of many 30% language implementations (or even abondoned ones) in singular IDEs work can be contracted on one LSP implementation, which might reach 70-80% feature set.
That would be pretty stupid, though, as every language server would duplicate a massive amount of code.
It seems like the language implementation is the right place to put logic that requires information about how the language works.
Couple this with the fact that limiting "API" to mean "C ABI" forces every compiler author to start exposing complex C structures, unsafe pointers and the like - which if their compiler is written in, say Haskell, or LISP is going to be particularly painful, v.s. implementing text-based RPC over a socket in whatever way is best for them.
If Language Server had been a C API then I seriously doubt it would have got much traction, as it's just too awkward for many compiler authors to implement. Unsafe C APIs are, frankly, last century's technology.
Which is why I see as positive the UWP, iOS and Android models regarding application extensions.
They might be more complex to implement than a straight unsafe C API, but that is exactly the goal, to be a safer alternative.
shipping along with your language, some kind of API that is standardized so that editors can easily add high quality IDE level features to support new languages is a great idea
that this is currently being done via a server + json over pipes or whatever is a suboptimal way to do it, I agree.
It's possible to do a lot of the nice IDE features in vim (and I'm sure emacs) today w/ all sorts of contortions, but a standard way to get this done would be amazing.
Yep, sounds like emacs. (I use emacs, but my god is it a horrible collection of half-broken hacks. Still the most useful editor going, though. If anyone wants to fund me, I'll start a project to make an editor that combines the flexibility of emacs with a rigorous, ruthless obsession with speed and correctness. :)
Boy it's been a while since I've broken out that one ;)
(to flip an old one on it's head).
It instead proposes to have the language server expose the entire AST and environment that is available at each point, and have the IDE uses that for autocompletion, as this is far more powerful than what is currently doable with LSP. (Currently, the editor just transmits cursor position and content to the LSP, which then does all the highlighting, autocompletion, etc. This is not only less configurable, and less consistent, but also less usable, as often the LSP isn’t able to offer as smart autocompletions)
Many IDEs, such as the JetBrains IDEA platform, do exactly this with their language plugins.
That’s called "you can create an entirely new API that’s entirely different, but might use the same name".
That’s the issue here, LSP is so fundamentally flawed you’d have to scrap it entirely to support what is needed for a real IDE.
It's come a long way in the last few months, I'd recommend giving it a shot again.
Would be cool to have a linter that can run file-by-file as well, though that's tough for clippy as a compiler plugin it seems? Maybe just hacking it to only report on a particular file would work.
Do you mean errors next to lines? If so that works today in the RLS variant. You get a red highlight and can mouse-over for details.