[HN Gopher] Erlang LS - The Erlang Language Server
___________________________________________________________________
Erlang LS - The Erlang Language Server
Author : lelf
Score : 171 points
Date : 2020-03-13 14:57 UTC (8 hours ago)
(HTM) web link (erlang-ls.github.io)
(TXT) w3m dump (erlang-ls.github.io)
| frou_dh wrote:
| 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 wrote:
| 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.
| dnautics wrote:
| 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 wrote:
| 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_
| n...
|
| 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
| dnautics wrote:
| 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 wrote:
| > _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 wrote:
| 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 wrote:
| 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 wrote:
| 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_d...).
| Ciantic wrote:
| > 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.
| marcrosoft wrote:
| The more I learn about lisp the more I see its insights. The
| interpreter itself is kind of like the language server.
| rapsey wrote:
| Does it work better than:
| https://github.com/pgourlain/vscode_erlang ?
| robertoaloi wrote:
| 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...
| https://erlang-ls.github.io/features/
| durandal1 wrote:
| 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.
| giancarlostoro wrote:
| Source here for those interested:
|
| https://github.com/erlang-ls/erlang_ls
|
| Specifically here:
|
| https://github.com/erlang-ls/erlang_ls/tree/master/src
| robertoaloi wrote:
| 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
|
| Zero setup, just login via your GitHub account.
| sigjuice wrote:
| Is there a way to try it without logging in?
| robertoaloi wrote:
| 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.
___________________________________________________________________
(page generated 2020-03-13 23:00 UTC)