It needs to do everything a compiler frontend does, and most languages don't have compilers that are written with this use case in mind.
Even if parts of compilers can be used as a library, they are very rarely written in a IDE compatible way, where you need fast, incremental and very resilient parsing and type checking.
Typescript was written with IDEs in mind from the start, which is a big reason it excels here. C# has a dedicated IDE toolchain called Roslyn.
And for dynamic languages the task is even more complicated, since you need to implement type inference and static analysis.
I even wrote a Zig package for elixir, which plugs into the elixir compiler, and I found that the ls correctly highlights compile-time errors in my Zig code embedded in the Elixir Code. About a month ago VSCode switched to auto-code-loading (instead of hitting save) and now my Zig embedded in Elixir live-highlights mistakes (with about a 500ms delay).
So if erlang-ls is about as good as Elixir-ls it'll be fantastic.
I love Zig, but it doesn't have the security guarantees (yet) of Rust, so I would recommend either running it out of proc or within an in-proc Wasm environment, which actually has other interesting properties.
So this is an Erlang Nif  which runs inside the VM, akin to JNI in Java. This also means that errant code can bring down the entire VM.
Would you be open to a fork of Zigler that targeted a Wasm environment running inside the Erlang env?
I think in general though you should be using zig not rust, because zig is aggressively unopinionated about memory allocators, so when you allocate memory in your code, you'll use the allocator that zigler provides, which makes the BEAM alloc conformant to zig's allocator interface. This means your code will be more performant, because there are fewer trips to the kernel on allocate and destroy, and your code will respect the BEAM's memory fragmentation, cache optimization, etc.
Language servers, along with auto formatting and debugging features should now be first-class design decisions for a new language. They shouldn’t be afterthoughts.
Something Go for right was the formatted, something that they for wrong was debugability.
New languages must make a decision to get these features right from the start.
For dynamic languages the static analysis and type inference would end up looking a lot like in TypeScript.
I wish we could retool TypeScript language server for other dynamic languages, that would make things interesting.
Zero setup, just login via your GitHub account.