5 ms·

Erlang LS – The Erlang Language Server

238 points by lelf 7y ago

giancarlostoro 7y ago
Source here for those interested: https://github.com/erlang-ls/erlang_ls https://github.com/erlang-ls/erlang_ls Specifically here: https://github.com/erlang-ls/erlang_ls/tree/master/src https://github.com/erlang-ls/erlang_ls/tree/master/src
frou_dh 7y ago
I'm sure this one is good. But something I've noticed from trying Language Servers for various languages is that a lot of them still need to get over the hump to be an overall help rather than a hinderance. i.e. using a Language Server that's flakey and fouls up often is more annoying than not having one enabled at all.
- the_duke 7y ago
  Yup. Writing a good language server is a big task. 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.
  - Ciantic 7y ago
    > And for dynamic languages the task is even more complicated, since you need to implement type inference and static analysis. 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.
  - dnautics 7y ago
    It's not erlang-ls, but having used elixir-ls is a pleasure (for the unaware, elixir runs on the erlang vm). Pretty much everything just works as you would expect, and it's a huge timesaver. Erlang and elixir have static typechecking, which is a slow process from the command-line, but it's integrated and "just works" with the ls, and rather refreshingly fast. 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.
    - sitkack 7y ago
      Wait, please explain/expound on using Zig contained within Elixir?! Is this running in or out of proc? What is your dev/edit cycle like? 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. edit https://www.reddit.com/r/elixir/comments/e955jw/zigler_zig_nifs_in_elixir/ https://www.reddit.com/r/elixir/comments/e955jw/zigler_zig_n... https://hexdocs.pm/zigler/Zigler.html https://hexdocs.pm/zigler/Zigler.html So this is an Erlang Nif [3] 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? [3] http://erlang.org/doc/man/erl_nif.html http://erlang.org/doc/man/erl_nif.html
      - dnautics 7y ago
        You can do what you want :) in practice it's really hard to bring down the erlang VM in zig. I'm also going to experiment with OTP managed OS threads, which I think should allow you to safely run code that panics (but maybe not segfaults), and will clean up the memory resources after you. 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.
  - 3fe9a03ccd14ca5 7y ago
    > Yup. Writing a good language server is a big task. 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.
    - edjrage 7y ago
      Sorry, I agree with you, but I don't understand what your point is. This post is about Erlang, which is far from a "new language".
  - beagle3 7y ago
    Language designers: you may want to see how Nim helps these causes. E.g. it includes a tool called "nimsuggest" which make it easy for VSCode, vim and Emacs modes to (relatively) easily implement intellisense-style suggestions.
  - robertoaloi 7y ago
    I would say that the API and functionalities provided the Erlang compiler and other syntax tools is quite extensive, compared to other languages. There are a few quirks (some of them addressed in the latest versions of OTP), but generally speaking these libraries are reasonably simple to work with. Erlang LS does most of the work by using standard OTP libraries. The project maintains a fork of the preprocessor dodger provided by OTP (https://github.com/erlang-ls/erlang_ls/blob/master/src/els_dodger.erl https://github.com/erlang-ls/erlang_ls/blob/master/src/els_d...).
rapsey 7y ago
Does it work better than: https://github.com/pgourlain/vscode_erlang https://github.com/pgourlain/vscode_erlang ?
- robertoaloi 7y ago
  I would say the major difference is that "vscode_erlang" is tailored for VS Code, while Erlang LS aims at be editor-agnostic (which is the main point of implementing a Language Server). There are currently some differences in terms of features, too. For example, VS Code has support for a debugger, which Erlang LS does not have (yet). On the other hand, Erlang LS provides support for Dialyzer or Elvis and I'm not sure if those are provided by VS Code Erlang. You can compare the list of available features: https://github.com/pgourlain/vscode_erlang#erlang-for-visual-studio-code https://github.com/pgourlain/vscode_erlang#erlang-for-visual... https://erlang-ls.github.io/features/ https://erlang-ls.github.io/features/
robertoaloi 7y ago
If you would like to try it out, you can do it in the browser: https://gitpod.io/#https://github.com/erlang-ls/erlang_ls https://gitpod.io/#https://github.com/erlang-ls/erlang_ls Zero setup, just login via your GitHub account.
- sigjuice 7y ago
  Is there a way to try it without logging in?
  - robertoaloi 7y ago
    I don't think so, unfortunately. Of course you can follow one the installation instructions for one of the available editors. See the "editors" section on the website. Instructions exist for Emacs, VSCode, Vim, etc.
durandal1 7y ago
Configuring Neovim for different languages used to be such a hassle, now with CoC.nvim, all it takes is pointing to the LS, combined with the benefits of having functionality standardized for all languages. I've used Erlang LS briefly, and if nothing else, it's way easier to set up.
marcrosoft 7y ago
The more I learn about lisp the more I see its insights. The interpreter itself is kind of like the language server.
- uryga 7y ago
  couldn't this be said about any language with an interpreter? or do you have some lisp-specific feature in mind?
RickJWagner 7y ago
Awesome. Can't wait to see it in Eclipse Che.
fortran77 7y ago
This is working nicely in MS VS Code! I program in Erlang every day, and didn't know this was available.

238 points by lelf 7y ago

Source here for those interested: https://github.com/erlang-ls/erlang_ls https://github.com/erlang-ls/erlang_ls Specifically here: https://github.com/erlang-ls/erlang_ls/tree/master/src https://github.com/erlang-ls/erlang_ls/tree/master/src

frou_dh 7y ago

I'm sure this one is good. But something I've noticed from trying Language Servers for various languages is that a lot of them still need to get over the hump to be an overall help rather than a hinderance. i.e. using a Language Server that's flakey and fouls up often is more annoying than not having one enabled at all.

the_duke 7y ago
Yup. Writing a good language server is a big task. 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.
- Ciantic 7y ago
  > And for dynamic languages the task is even more complicated, since you need to implement type inference and static analysis. 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.
- dnautics 7y ago
  It's not erlang-ls, but having used elixir-ls is a pleasure (for the unaware, elixir runs on the erlang vm). Pretty much everything just works as you would expect, and it's a huge timesaver. Erlang and elixir have static typechecking, which is a slow process from the command-line, but it's integrated and "just works" with the ls, and rather refreshingly fast. 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.
  - sitkack 7y ago
    Wait, please explain/expound on using Zig contained within Elixir?! Is this running in or out of proc? What is your dev/edit cycle like? 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. edit https://www.reddit.com/r/elixir/comments/e955jw/zigler_zig_nifs_in_elixir/ https://www.reddit.com/r/elixir/comments/e955jw/zigler_zig_n... https://hexdocs.pm/zigler/Zigler.html https://hexdocs.pm/zigler/Zigler.html So this is an Erlang Nif [3] 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? [3] http://erlang.org/doc/man/erl_nif.html http://erlang.org/doc/man/erl_nif.html
    - dnautics 7y ago
      You can do what you want :) in practice it's really hard to bring down the erlang VM in zig. I'm also going to experiment with OTP managed OS threads, which I think should allow you to safely run code that panics (but maybe not segfaults), and will clean up the memory resources after you. 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.
- 3fe9a03ccd14ca5 7y ago
  > Yup. Writing a good language server is a big task. 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.
  - edjrage 7y ago
    Sorry, I agree with you, but I don't understand what your point is. This post is about Erlang, which is far from a "new language".
- beagle3 7y ago
  Language designers: you may want to see how Nim helps these causes. E.g. it includes a tool called "nimsuggest" which make it easy for VSCode, vim and Emacs modes to (relatively) easily implement intellisense-style suggestions.
- robertoaloi 7y ago
  I would say that the API and functionalities provided the Erlang compiler and other syntax tools is quite extensive, compared to other languages. There are a few quirks (some of them addressed in the latest versions of OTP), but generally speaking these libraries are reasonably simple to work with. Erlang LS does most of the work by using standard OTP libraries. The project maintains a fork of the preprocessor dodger provided by OTP (https://github.com/erlang-ls/erlang_ls/blob/master/src/els_dodger.erl https://github.com/erlang-ls/erlang_ls/blob/master/src/els_d...).

rapsey 7y ago

Does it work better than: https://github.com/pgourlain/vscode_erlang https://github.com/pgourlain/vscode_erlang ?

robertoaloi 7y ago
I would say the major difference is that "vscode_erlang" is tailored for VS Code, while Erlang LS aims at be editor-agnostic (which is the main point of implementing a Language Server). There are currently some differences in terms of features, too. For example, VS Code has support for a debugger, which Erlang LS does not have (yet). On the other hand, Erlang LS provides support for Dialyzer or Elvis and I'm not sure if those are provided by VS Code Erlang. You can compare the list of available features: https://github.com/pgourlain/vscode_erlang#erlang-for-visual-studio-code https://github.com/pgourlain/vscode_erlang#erlang-for-visual... https://erlang-ls.github.io/features/ https://erlang-ls.github.io/features/

robertoaloi 7y ago

If you would like to try it out, you can do it in the browser: https://gitpod.io/#https://github.com/erlang-ls/erlang_ls https://gitpod.io/#https://github.com/erlang-ls/erlang_ls Zero setup, just login via your GitHub account.

sigjuice 7y ago
Is there a way to try it without logging in?
- robertoaloi 7y ago
  I don't think so, unfortunately. Of course you can follow one the installation instructions for one of the available editors. See the "editors" section on the website. Instructions exist for Emacs, VSCode, Vim, etc.

durandal1 7y ago

Configuring Neovim for different languages used to be such a hassle, now with CoC.nvim, all it takes is pointing to the LS, combined with the benefits of having functionality standardized for all languages. I've used Erlang LS briefly, and if nothing else, it's way easier to set up.

marcrosoft 7y ago

The more I learn about lisp the more I see its insights. The interpreter itself is kind of like the language server.

uryga 7y ago
couldn't this be said about any language with an interpreter? or do you have some lisp-specific feature in mind?

RickJWagner 7y ago

Awesome. Can't wait to see it in Eclipse Che.

fortran77 7y ago

This is working nicely in MS VS Code! I program in Erlang every day, and didn't know this was available.