Erlang LS – The Erlang Language Server • Hacker News Board

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.

Re: Erlang LS – The Erlang Language Server

#4

Post by the_duke » Fri, Mar 13, 2020, 4:52 PM UTC

frou_dh wrote: post #3

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.

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.

Re: Erlang LS – The Erlang Language Server

#5

Post by rapsey » Fri, Mar 13, 2020, 4:52 PM UTC

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

Re: Erlang LS – The Erlang Language Server

#6

Post by Ciantic » Fri, Mar 13, 2020, 4:59 PM UTC

the_duke wrote: post #4

frou_dh wrote: post #3

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.

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…

> 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.

Re: Erlang LS – The Erlang Language Server

#7

Post by dnautics » Fri, Mar 13, 2020, 5:14 PM UTC

the_duke wrote: post #4

frou_dh wrote: post #3

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.

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…

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.

Re: Erlang LS – The Erlang Language Server

#8

Post by 3fe9a03ccd14ca5 » Fri, Mar 13, 2020, 5:15 PM UTC

the_duke wrote: post #4

frou_dh wrote: post #3

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.

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…

> 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.

Re: Erlang LS – The Erlang Language Server

#9

Post by beagle3 » Fri, Mar 13, 2020, 5:48 PM UTC

the_duke wrote: post #4

frou_dh wrote: post #3

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.

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…

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.

Re: Erlang LS – The Erlang Language Server

#10

Post by sitkack » Fri, Mar 13, 2020, 6:00 PM UTC

dnautics wrote: post #7

the_duke wrote: post #4

Earlier quoted context omitted.

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…

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 th…

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