There are several different LSP implementations of Elixir, each with their own pros and cons. Last year they all agreed to collaborate on an LSP; is this going to be the result of that?
The architecture is remarkable. The lengths they’ve gone to for language version compatibility, and protecting app namespaces is especially impressive.
Namespaces aren't so much a concept in Elixir, but this refers to the names used for things like modules. Expert will rewrite the code of its "engine" so that the engine's code and dependencies and those of the application it is embedded into don't overlap.
I’ve been switching between different LSP implementations for Elixir—ElixirLS, Lexical, next-ls—and have been following Expert for a while. Really looking forward to trying it out!
That said, the only thing that feels a bit off to me is the name “Expert.” It comes across slightly arrogant or presumptuous—like it’s implying it’s the only “expert” in the room. Maybe something more neutral would’ve been better?
Still, excited to see what the official tooling brings!
It's not an AI tool. It's an LSP. It is the expert in the room, because it's not a random word generator, not smart, it just follows the rules that the language has.
How did you find out about it in the first place? I remember seeing the Elixir blog post announcing the LSP project ages ago and then nothing since then.
Oo I’m excited for this. The old official language server is fine—it does its job on most of the code bases I’ve worked on, but occasionally I will do something funny that makes the compiler slow down and that pummels the LS performance. I hope this works out some of the kinks that occasionally would make elixir-ls slow.
Nit: there has never been an official LSP implementation until now, only community-authored. Even now no Dashbit employees or language core members are directly involved in this project in an ongoing basis.
IMO that contributes powerfully to the quality of the experiences of using any of the options.
Oh I'm excited for this. Editor support for elixir has never been quite as good as I'd like. I'm really happy to see they're investing in this - no lang with as consistently great a developer experience as elixir should be without a proper, official, well supported lang server.
It has both a justfile and a makefile at the root, even. Most of us seem to want to use it to throw make away entirely.
That said, I consider `just` very language-agnostic and useful because of that, and I consider mix pretty bad at any workflow needs that isn't directly concerned with BEAM.
It's not technically a make replacement (make does do things like incremental build management etc.), but it just goes to show how bad the DX of make is.
There are several different LSP implementations of Elixir, each with their own pros and cons. Last year they all agreed to collaborate on an LSP; is this going to be the result of that?
https://elixir-lang.org/blog/2024/08/15/welcome-elixir-langu...
Yes, that's correct. Pretty exciting.
Yup
The architecture is remarkable. The lengths they’ve gone to for language version compatibility, and protecting app namespaces is especially impressive.
https://github.com/elixir-lang/expert/blob/main/pages/archit...
What are namespaces in Elixir?
Namespaces aren't so much a concept in Elixir, but this refers to the names used for things like modules. Expert will rewrite the code of its "engine" so that the engine's code and dependencies and those of the application it is embedded into don't overlap.
I’ve been switching between different LSP implementations for Elixir—ElixirLS, Lexical, next-ls—and have been following Expert for a while. Really looking forward to trying it out!
That said, the only thing that feels a bit off to me is the name “Expert.” It comes across slightly arrogant or presumptuous—like it’s implying it’s the only “expert” in the room. Maybe something more neutral would’ve been better?
Still, excited to see what the official tooling brings!
It's not an AI tool. It's an LSP. It is the expert in the room, because it's not a random word generator, not smart, it just follows the rules that the language has.
I found the name to be perfect. Just a little fun. It also goes with the ex-prefix you see in libs sometimes.
How did you find out about it in the first place? I remember seeing the Elixir blog post announcing the LSP project ages ago and then nothing since then.
You're overthinking it. I'd rather have interesting than milquetoast.
how about "NotExpert"
How about "Fairly Knowledgeable, Always Humbly Ready to Learn from Others"?
FKAHRLO for short.
Nailed it
Cool to see there's a long term plan for the language and the ecosystem!
Oo I’m excited for this. The old official language server is fine—it does its job on most of the code bases I’ve worked on, but occasionally I will do something funny that makes the compiler slow down and that pummels the LS performance. I hope this works out some of the kinks that occasionally would make elixir-ls slow.
Nit: there has never been an official LSP implementation until now, only community-authored. Even now no Dashbit employees or language core members are directly involved in this project in an ongoing basis.
IMO that contributes powerfully to the quality of the experiences of using any of the options.
Oh I'm excited for this. Editor support for elixir has never been quite as good as I'd like. I'm really happy to see they're investing in this - no lang with as consistently great a developer experience as elixir should be without a proper, official, well supported lang server.
Can't wait to try it out!
Interesting choice to use just
For those not sure what just is:
Website: https://just.systems
Previous HN discussion: https://news.ycombinator.com/item?id=42351101
It has both a justfile and a makefile at the root, even. Most of us seem to want to use it to throw make away entirely.
That said, I consider `just` very language-agnostic and useful because of that, and I consider mix pretty bad at any workflow needs that isn't directly concerned with BEAM.
It's not technically a make replacement (make does do things like incremental build management etc.), but it just goes to show how bad the DX of make is.
IMO 'just' replaces make where make shouldn't be used - generic task runner.
Correct. Make should be used with the filesystem, minimising PHONY.
I think it's hard for me to name better software than make. TeX, maybe? that seems like an insanely high bar to clear.
I would say there's an ocean of software with better UX than those two, so it all comes down to what axis you measure on.
i'm a pretty big fan of just, personally, but do not consider that to be the world's most well-considered position by any means...
No MCP support?
For BEAM MCP you probably want to look at TideWave, which runs _in your application_ to give the LLM context and an execution environment.
https://hexdocs.pm/tidewave/mcp.html
Wouldn't it make more sense to have a single MCP -> LSP adapter rather than having each LSP implement it?
Makes sense, except:
1. too many layers and worse DX
2. harder realtime updates