Earlier quoted context omitted.
What kind of protections as opposed to Zigler?
Rust comes with memory safety. It's one less potential cause that might bring down the entire Erlang VM.
SIGSEGV is a pretty common failure mode alright.
Zigler: Zig NIFs in Elixir
41–50 of 93 posts
Re: Zigler: Zig NIFs in Elixir
#42Earlier quoted context omitted.
It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. Elixir itself doesn’t change too much so these libraries stay solid without needing frequent updates. It doesn’t mean people aren’t using them. Some libraries even put disclaimers that they are actively maintained even if they haven’t seen an update in a long time. It’s something that takes some getting used to for some p…
> It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. This is kind of fascinating and seems worthy of more detailed study. I'm sure almost anything looks stable compared to javascript/python ecosystems, but would be interesting to see how other ecosystems with venerable old web-frameworks or solid old compression libraries compare. But on further reflection.. language metr…
Elixir itself is "feature complete" as of 2019 (5-years now).
https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
It does get the occasional updates, but it's mainly related to developer tooling than language enhancements.
Re: Zigler: Zig NIFs in Elixir
#43For anyone mystified about what a NIF is that doesn't want to go read the docs. The BEAM VM (which is the thing that runs erlang / elixir / gleam / etc) has 3 flavors of functions. - BIFs - Built-in functions, these are written in C and ship with the VM - NIFs - Natively implemented functions, these are written in any language that can speak the NIF ABI that BEAM exposes and allows you to provide a function that look…
It's also important to point out ports, because as you mention, NIFs are a way to integrate external code. But as someone else points out, NIFs can crash the entire BEAM VM. Ports are a safer way to integrate external code because they are just another BEAM process that talks to an external program. If that program crashes, then the port process crashes just like any other BEAM process but it won't crash the entire B…
Why would anyone use a NIF instead of a Port then?
Re: Zigler: Zig NIFs in Elixir
#44Earlier quoted context omitted.
It's also important to point out ports, because as you mention, NIFs are a way to integrate external code. But as someone else points out, NIFs can crash the entire BEAM VM. Ports are a safer way to integrate external code because they are just another BEAM process that talks to an external program. If that program crashes, then the port process crashes just like any other BEAM process but it won't crash the entire B…
Why would anyone use a NIF instead of a Port then?
IPC/shared memory overhead?
Re: Zigler: Zig NIFs in Elixir
#45(Yo dawg, we put a niche language into a niche language so that...) I wonder if the Zig code can be not written inline, as an option. With anything larger than a few lines, I'd want syntax highlighting, LSP support, navigation, etc. It's easier to achieve with one language per file.
Yes, you can put Zig code in a separate file.
Re: Zigler: Zig NIFs in Elixir
#46Great! But, what is a nifs, please? :'D
It's Elixir's[1] equivalent of a Foreign Function Interface.
1. More accurately, NIFs sre BEAM's take on FFI functions, and Elixir is a BEAM language.
Re: Zigler: Zig NIFs in Elixir
#47Earlier quoted context omitted.
> It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. This is kind of fascinating and seems worthy of more detailed study. I'm sure almost anything looks stable compared to javascript/python ecosystems, but would be interesting to see how other ecosystems with venerable old web-frameworks or solid old compression libraries compare. But on further reflection.. language metr…
Elixir itself is "feature complete" as of 2019 (5-years now). https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas... It does get the occasional updates, but it's mainly related to developer tooling than language enhancements.
with the maybe exception of the type system
Re: Zigler: Zig NIFs in Elixir
#48Does anyone actually enjoy using these systems that encourage you to embed programming-language X code in programming-language Y heredocs? I always find actually doing that — and then maintaining the results over time — to be quite painful: you don't get syntax highlighting inside the string; you can no longer search your worktree reliably using extension-based filtering; etc. I personally find the workflow much more…
Syntax highlighting here can work correctly, actually. Also, I'm not sure why it's not better documented in Zigler, but you can also write the code in a separate file just fine.
Links for anyone curious.
> Syntax highlighting here can work correctly, actually.
Highlighting shown here in the 2021 ElixirConf talk posted elsewhere in the comments:
https://youtu.be/lDfjdGva3NE?t=2064
> I'm not sure why it's not better documented in Zigler
Here's the docs for it (though buried in the 'advanced' section)
https://hexdocs.pm/zigler/Zig.html#module-importing-external...
Re: Zigler: Zig NIFs in Elixir
#49Earlier quoted context omitted.
It's also important to point out ports, because as you mention, NIFs are a way to integrate external code. But as someone else points out, NIFs can crash the entire BEAM VM. Ports are a safer way to integrate external code because they are just another BEAM process that talks to an external program. If that program crashes, then the port process crashes just like any other BEAM process but it won't crash the entire B…
Why would anyone use a NIF instead of a Port then?
NIFs are great for things that really feel like a relatively quick function call.
If you've got some mathematical/crypto function, chances are you don't want that to go through a command queue to an external port, because that's too much overhead. If it's a many round crypto function like bcrypt or something, you do need to be a bit careful doing it as a NIF because of runtime. But you wouldn't want to put a sha256 through an external program and have to pass all that data to it, etc.
Something that you might actually want queueing for and is likely to have potential for memory unsafety like say transcoding with ffmpeg, would be a good fit as an external Port rather than a NIF or a linked in Port driver.
Re: Zigler: Zig NIFs in Elixir
#50Earlier quoted context omitted.
It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. Elixir itself doesn’t change too much so these libraries stay solid without needing frequent updates. It doesn’t mean people aren’t using them. Some libraries even put disclaimers that they are actively maintained even if they haven’t seen an update in a long time. It’s something that takes some getting used to for some p…
> It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. This is kind of fascinating and seems worthy of more detailed study. I'm sure almost anything looks stable compared to javascript/python ecosystems, but would be interesting to see how other ecosystems with venerable old web-frameworks or solid old compression libraries compare. But on further reflection.. language metr…
Erlang (and friends) are built with a goal of stability. Operational stability is part of that, but it also comes into play with code and architectural stability.
Maybe it's the functionalness, maybe it's the problem domains, but a lot of the modules have clear boundaries and end up with pretty small modules where the libraries end up having a clear scope and a small code base that moves towards being obviously correct and good for most and then doesn't have much changes after that. It might not work for everyone, but most modules don't end up with lots of options to support all the possible use cases.
The underlying bits of OTP don't tend to churn too much either, so old code usually continues to work, unless you managed to have a dependency on something that had a big change. I recall dealing with some changes in timekeeping and random sources, but otherwise I don't remember having to change my Erlang code for OTP updates.
It helps that the OTP team is supporting several major versions (annual releases) simultaneously, so if there's a lot of unneccessary change, that makes their job harder as well as everyone else's.