Comment by ihumanable | Hacker News Reader

Comment by ihumanable | Hacker News Reader

Parent Full thread

For 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 looks like a built-in function but that you build yourself.

- User - User functions are written in the language that's running on BEAM, so if you write a function in erlang or elixir, that's a user function.

NIFs allow you to drop down into a lower level language and extend the VM. Originally most NIFs were written in C, but now a lot more languages have built out nice facilities for writing NIFs. Rust has Rustler and Zig now has Zigler, although people have been writing zig nifs for a while without zigler and I'm sure people wrote rust nifs without rustler.

It’s important to note that while Erlang has protections against user code crashing an Erlang process and recovering, a faulty NIF can take down the entire virtual machine.

There's a series of things that a NIF must do to be a good citizen. Not crashing is a big one, but also not starving the VM by never yielding (in case the NIF is long-running) is important, plus a few secondary things like using the BEAM allocator so that tooling that monitors memory consumption can see resources consumed by the NIF.

The creator of Zigler has a talk from ElixirConf 2021 on how he made Zig NIFs behave nicely:

https://www.youtube.com/watch?v=lDfjdGva3NE

Hence why Rustler is of so much interest since it provides more protections against this happening.

Discord is a big Erlang + Rustler user.

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.

Rustler catches panics before they crash the VM and raises them on the elixir side as an exception. So your process might crash but the vm wont

That's a neat way to get corrupted state in your application, especially when users of said language don't realize that their language has exceptions.

I wrote this recently about Go, but it equally applies to any Rust application that tries to recover from a panic.

https://kristoff.it/blog/go-exceptions-unconvinced/

I don't think this is right. The process will crash, and the Supervision strategy you are using will determine what happens from there. This is what the BEAM is all about. The thing with NIFs is that they can crash the entire VM if they error.

Erlang's (Elixirs) error management approach is actually "Let it crash"

This is based on the acknowledgment that if you have a large number of longer running processes at some point something will crash anyway, so you may quite as well be good at managing crashes ;-)

https://dev.to/adolfont/the-let-it-crash-error-handling-stra...

Yes, but that's not Rust's error management strategy. Most Rust code isn't written with recovery from panics in mind, so it can have unintended consequences if you catch panics and then retry.

This is terrible, actually. And I've run into it, causing a memory leak.

How so? The whole point of unwinding is to gracefully clear up on panics, how did it peak for you?

It's also not like there is much of a choice here. Unwinding across FFI boundaries (e.g. out of the NIF call) is undefined behaviour, so the only other option is aborting on panics.

Yes. Abort early in unit tests, core dump so it never makes it to prod

The panic is converted to an Erlang error exception. You have to explicitly ignore it to make unit tests pass in spite of it.

I am still interested in the situation you observed.

Are they really? Their projects don't look so active

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 people (including myself at one point).

I will second this. I've been using multiple libraries in our production Elixir app that haven't been updated in the last five years. Elixir itself was declared as "stable" feature-wise years ago. It may be argued that the type system being introduced is not in-keeping with that, but not sure. Jose is a very cautious and diligent "benevolent dictator" and you get a lot of backward compatibility guarantees. Erlang is the same. Compared to what some people might be used to with churn in Node/React etc it is apples and oranges.

The semantics can certainly be argued, but a type system is sort of on its own tier of as far as language features go. Most importantly, there is only going to be one backward incompatible change which is the spec syntax, otherwise it is just leveraging how we already write Elixir.

Yes, I'm not worried about it. I've not been following it as closely as I'd like, but from what I've read the core team seems to be taking a very measured incremental approach with the type system.

Yep! It's leveraging pattern-matching and guards as well as looking at code itself for inference.

Erlang is not very backward compatible. At least not at OTP 22.

> 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 metrics like "popularity" are also in danger of just quantifying the churn that it takes to keep working stuff working. You can't even measure strictly new projects and hope that helps, because new projects may be a reaction to perceived need to replace other stuff that's annoyingly unstable over periods of 5-10 years, etc.

Some churn is introduced by trying to keep up with a changing language, standard lib, or other dependencies, but some is just adding features forever or endlessly refactoring aesthetics under different management. Makes me wish for a project badge to indicate a commitment like finished-except-for-bugfixes.

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.

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

Same in Java.

You can find libraries that haven't been updated in 10 years and yet are still the best solution.

Yep. This is one reason I choose Elixir for a project. For a variety of use cases, long term stability is a big plus.

That is not what I meant. I looked at sorted_set_nif which doesn't seem to compile on OTP 26 (we're at 27 now), and fastglobal which has a very old PR with 3 approvals has not been merged. Elixir libraries may not change _much_ but core libraries like telemetry, Ecto, ExDoc, Jason, still get either minor or patch releases all the time.

If libraries get regular updates even if they are minor, it indicates they are in use. If they have inactive repositories and low hex.pm download numbers, they may have been abandoned which can mean you have to maintain it yourself in the future, or the people behind the library found it's not such a good idea after all. This doesn't have to be the case, which is why I asked.

Ah ya, I do see how the optics of this could give off that impression. I don't use this library myself, but the issue is with Elixir 1.15.7 & OPT 26.1.26 which is VERY different than "It doesn't work on OTP 26." Certain patch versions of Elixir and OTP have caused problems before (sorry, I don't have a citation) and this particular issue looks like it's related to dependencies not syncing up on the config change?

I do think more libraries should give that little "We're still maintained" notice as people not totally ingrained in this might not realize. To some, the fact that there have been no issues reported now that we're on OPT 27 and Elixir 17 would be an indicator that all is well.

Rustler wasn't properly forward compatible (only with regard to the build process, a compiled library will work just fine on any newer OTP) until 0.29. They are using 0.22, upgrading Rustler will be enough to get rid of this issue for all future OTP versions.

Thank you for the full story here as I just gave the issue a cursory glance. As someone quite ingrained in Elixir, I see an issue referencing specific patch versions of Elixir and OTP and immediately understand it's very specifically targeting that specific Elixir/OTP combo. But depr brings up a good point that not everyone is immediately going to understand this, especially newcommers to the language and it’s generally hard not to just read the headline.

Yeah I was trying to explain this to another developer that packages end up being “finished” eventually and seem to continue to work exceptionally well without updates for a really long time.

Something about immutability and the structure of Elixir leads to surprisingly few bugs.

I wrote sorted_set_nif, the lack of activity isn’t a lack of care about the library but more just a reflection that the library is done.

With data structures that have some definite behavior unless someone finds a defect there isn’t going to be much activity.

I looked at that library and I found https://github.com/discord/sorted_set_nif/issues/30 which made me think it doesn't work on recent Erlang versions and is therefore not used anymore.

I wish more people knew this, but I feel like junior developers are just chasing stars on GitHub and wherever else.

Is any of this code open source? As an outsider, I'm kind of at a loss for why anyone wants this or what you kids are doing over there and how offended I should be by it.

https://github.com/discord/sorted_set_nif

Awesome! Thank you! My sarcasm got downvoted heavily (poe's law), but I was genuinely interested.

Do you mean Rustler?

Yes, it's Apache 2.0

https://github.com/rusterlium/rustler

TL;DR: Erlang/Elixir/etc are high level languages and the virtual machine they run on, the BEAM, is optimized for speedy IO but is not so great when it comes to intensive CPU tasks. You'll want to write the latter in a good systems language which is what libraries like this provide (you get C bindings out of the box, I believe).

Don't be like me and do a 20ms page fault in a NIF

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

And then there are port drivers which are the worst of both worlds! Can crash the BEAM and need much more ceremony than NIF to set up but they’re pretty nice to do in Zig[1] as well

[1]: https://github.com/borgoat/er_zig_driver

That's true. Haha!

There's another option and that's setting up an Erlang node in the other language. The Erlang term format is relatively straightforward. But I'm honestly not sure of the benefit of a node versus just using a port.

Node:

- can "easily" send beam terms back and forth

- if you want it to be os-supervised separately (systemd, kubernetes, e.g.)

- pain in the ass

Port:

- easy

- usually the only choice if you're not the software author

- really only communicates via stdio bytestreams

- risk of zombies if... Iirc the stdout is not closed properly?

- kind of crazy how it works, Erlang VM spawns a separate process as a middleman

The Erlang term format is straightforward, but if you want to set up another node in another language you need to correctly implement/emulate process linking, binaries, and some other stuff too, it's not just a matter of writing a socket to accept and emit Erlang terms.

It's not impossibly large but it's not something one does on a lark either; if there isn't support in your language already it's hard to justify this over any of the many, many message busses supported by both Erlang and other languages that don't have so many requirements.

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.

Ports are generally great, but you are running multiple apps and communicating between them using STDIN/STDOUT etc. There are certain corner cases where they might not be suitable. I had been using an OPCUA library where the logging had to be turned off because otherwise it was sending the logs back to our Elixir app and we were expecting Elixir terms. Also the shutdown of the remote end of a port can stop the data getting back to Elixir. There are ways around all of this but it's slightly annoying. In general though, ports work 80% of the time and are really convenient.

IPC/shared memory overhead?

Yeap, this is a big one. In Nx we have some facilities for doing zero-copy stuff that only really work if you have, say, Evision and EXLA running on the same OS process.

We do have IPC handles that could enable this over, say, ports, but then there's a whole other discussion on pointers vs ipc handles

Do nifs have the equal process time stuff that regular elixir processes have? Where the BEAM will move the scheduler into another process if it's taking too long?

Forgive me if I'm mixing up my terminology it's been a bit since I have poked at Elixir.

You can write nifs that way but it seems like a pain in the ass

https://www.erlang.org/doc/apps/erts/erl_nif#enif_schedule_n...

After all, many of the BIFs have been replaced internally by NIFs

And there's this, which would scare me:

https://erlang.org/documentation/doc-15.0-rc3/erts-15.0/doc/...

BEAM can't preempt native code, that's why NIFs should either be fast/low-latency to not excessively block the scheduler or be put in what's called a dirty scheduler which just means to run it in a separate thread.

Nope, at least not by default or like one would expect from pure Erlang (when it comes to preempting). Been a while since I dug into this admittedly but I write Elixir daily for work (and have for about ten years now). They don’t do the record keeping necessary for the BEAM to interrupt. You need to make sure the “dirty scheduler” is enabled or you can end up blocking other processes on the same scheduler.

Here’s a link I found talking about using the dirty scheduler with Rust(ler): https://bgmarx.com/2018/08/15/using-dirty-schedulers-with-ru...

Unfortunately Haskell will never be able to have their version of "Zigler"...

Reply on news.ycombinator.com