victorolinasc
Language Server Protocol as a "core" project
Here I come again about the Language Server Protocol ![]()
I’ve seen support for some core language features in editors lag a bit behind the releases of the language. It seems a given that most recent languages are putting some effort on the language server protocol as a means to unite the “experience” of editing source code in any editor.
Rust, JavaScript, Java just to name a few… Even Erlang has a language server in development in its core Github organization (sourcer). There is a huge list now on langserver.org.
The advantages, in my opinion, are these:
- If you like Atom, VS Code, Emacs, Vim, IntelliJ and etc… it is easier to plug the language server with the editor frontend than to create your own language analyser, which will probably lag behind new features. Alchemist-server and elixir-sense are awesome projects (which I am really grateful) but they usually lag behind in support because they are not core.
- You would probably get support for more editors that are not “officially supported”.
- New language features would “automatically” be supported in the editors (like formatting, new core syntax like, say, “with” and so on).
The obvious disadvantage is that it would make the core team responsible for another piece of source code.
Even though, if we had good core Erlang and Elixir language servers, the experience in any editor that supports it would be awesome.
Anyway, it is just something that is on my mind for a while and I hope on the minds of more people.
Most Liked
JakeBecker
Hi all,
First, thanks for the support on ElixirLS, feels good to see people use and appreciate it
I agree with @michalmuskala that it doesn’t belong as part of Elixir core for the time being. Unless that means someone (not me) is going to start working on it full time, it would probably end up slowing the release cycle without much benefit. Also, it seems to me to be a little too broad to be a “core” library, since it pulls in dependencies like JSON and Elixir Sense which would then need to be core projects too, I think.
The core Elixir team have been supportive of the project, in particular helping me add diagnostic returns to the Mix compilers in Elixir 1.6. So if it really does need support from the core team in the future we can continue to make that happen ![]()
michalmuskala
There’s a saying that things go to stdlib to die - it’s very hard to develop or change libraries when they are in standard library, because of the slower release rate. Elixir-ls is still very well into development phase, changes often and implements new features all the time. Even because of this, it’s not a good candidate to include in core. Maybe once it stabilises, this should be revisited, but I’m convinced now it’s not a good time for this.
gon782
https://github.com/JakeBecker/elixir-ls
ElixirLS works well and it’s up to other editors to simply support the language server protocol if they want to tag along. I don’t know that we need it to be part of the core team and I think unless the person/people working on it gets paid specifically for that it doesn’t necessarily make a difference.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








