victorolinasc
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.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #elixirconf-us
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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.
dsissitka
ElixirLS is still a little rough around the edges. For example, completion is broken in vim:
https://github.com/JakeBecker/elixir-ls/issues/40
gon782
It seems
vim-lspis misusing the protocol in that case according to the issue. ElixirLS working fine with VS Code (which uses the protocol correctly, presumably) would indicate that’s true.dsissitka
Perhaps, but that wouldn’t explain why it doesn’t work with LanguageClient-neovim.
cs-victor-nascimento
Elixir-ls is a really awesome project. The thing is it will never get support on time of release new versions.
I still think that making it a core project would allow the project to evolve along with the language itself. Right now, Elixir-ls is awesome but not perfect and it is based on elixir-sense which is a project of analyzing the core AST. This kind of task feels to me like part of the core language.
Anyway, I think all the work we have here already is really nice. Just hoping for it to become even better.
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.
mbuhot
In the transition from 1.5 → 1.6 was there anything unsupported by ElixirLS? I recall ElixirLS prompting me to update to 1.6 before it was officially released to get formatter support.
gon782
Indeed that was the case.
edmz
I agree with you, but I got the impression that @victorolinasc suggested that a LSP server was adopted as a core project, not merged into stdlib. Like how GenStage/Flow are (IIRC).
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