4 ms·

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 exp

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.

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.