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.
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.
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.
Do you frequent elixirforum.com? That’s where the elixir community resides. Jose and Chris post frequently there. As well as maintainers of popular libraries.
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.
Woo super excited for this. Is anyone working on the official vscode extension so we don't have to build and hook that up ourselves, or is that up for grabs still?
Excited to see this after the blog post a year ago – I didn't realize they were working out in the open, because I was wondering how that project was going.
Any news on when we can start to use it in our editors?
As with my comment in another tree, no, none of the Elixir core team or Dashbit employees are directly involved with this effort, though they may be advising informally and will likely submit a PR here and there.
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.
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.
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.
Do you frequent elixirforum.com? That’s where the elixir community resides. Jose and Chris post frequently there. As well as maintainers of popular libraries.
I found the name to be perfect. Just a little fun. It also goes with the ex-prefix you see in libs sometimes.
You're overthinking it. I'd rather have interesting than milquetoast.
How about "Fairly Knowledgeable, Always Humbly Ready to Learn from Others"?
FKAHRLO for short.
Nailed it
how about "NotExpert"
Cool to see there's a long term plan for the language and the ecosystem!
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!
Woo super excited for this. Is anyone working on the official vscode extension so we don't have to build and hook that up ourselves, or is that up for grabs still?
Excited to see this after the blog post a year ago – I didn't realize they were working out in the open, because I was wondering how that project was going.
Any news on when we can start to use it in our editors?
> Any news on when we can start to use it in our editors?
https://github.com/elixir-lang/expert/blob/main/pages/instal...
What does "official" mean? Is it an official elixir-language project? I don't see Jose Valim as one the contributors.
Yes, it is, as you can see by being under the `elixir-lang` github org
Here's a blog post a year ago announcing the merge of 3 LSP projects into an official one: https://elixir-lang.org/blog/2024/08/15/welcome-elixir-langu...
“Official” means built by the creators of Elixir itself
Elixir has more contributors than just Jose (though he is the OG / creator / leader)
As with my comment in another tree, no, none of the Elixir core team or Dashbit employees are directly involved with this effort, though they may be advising informally and will likely submit a PR here and there.
https://dashbit.co/#team https://elixir-lang.org/development.html#team https://github.com/elixir-lang/expert/graphs/contributors
I'm a bit surprised by that. Isn't an LSP for a language like Elixir a close integration with the runtime, compiler, etc?
Interesting choice to use just
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.
For those not sure what just is:
Website: https://just.systems
Previous HN discussion: https://news.ycombinator.com/item?id=42351101
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
Have you tried Todewave? By far the best DX I’ve seen