Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zigler: Zig NIFs in Elixir

github.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: Zigler: Zig NIFs in Elixir

#61

Post by the_duke »

photonthug wrote: post #40
sodapopcan wrote: post #27

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

Same in Java.

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

Re: Zigler: Zig NIFs in Elixir

#62

Post by Dowwie »

Understand NIF risks: they can crash your entire Elixir Application, beyond their immediate supervision tree, because they operate in the same memory space as the BEAM itself.

NIF responsibly. :)

Re: Zigler: Zig NIFs in Elixir

#63

Post by kristoff_it »

el_oni wrote: post #57
johnisgood wrote: post #34

Earlier quoted context omitted.

What kind of protections as opposed to Zigler?

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/

Re: Zigler: Zig NIFs in Elixir

#64

Post by ellroy »

kristoff_it wrote: post #63
el_oni wrote: post #57

Earlier quoted context omitted.

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.

Re: Zigler: Zig NIFs in Elixir

#65

Post by ellroy »

sodapopcan wrote: post #27
depr wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Zigler: Zig NIFs in Elixir

#66

Post by ellroy »

abrookewood wrote: post #43
bmitc wrote: post #20

Earlier 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?

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.

Re: Zigler: Zig NIFs in Elixir

#67

Post by b3orn »

cooljacob204 wrote: post #53
ihumanable wrote: post #7

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

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.

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.

Re: Zigler: Zig NIFs in Elixir

#68

Post by johnisgood »

ihumanable wrote: post #32
depr wrote: post #21

Earlier quoted context omitted.

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

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 wish more people knew this, but I feel like junior developers are just chasing stars on GitHub and wherever else.

Re: Zigler: Zig NIFs in Elixir

#69

Post by depr »

ihumanable wrote: post #32
depr wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Zigler: Zig NIFs in Elixir

#70

Post by OkayPhysicist »

harrisi wrote: post #25

Zig is also used in an excellent way by burrito[0]. I've also used zig for compiling NIFs written in C/C++/Objective-C, since `zig cc` makes cross-compiling much nicer. I wish zig got more use and attention in the Erlang ecosystem, but rustler seems more popular.

Rustler is more popular because Rust solves one of the scarier bits about NIFs, the fact that irresponsible memory management in a NIF can kill the entire Erlang VM.

I can appreciate Zig for entire projects that would otherwise be written in C, but for the lengths of code that make sense for a NIF as opposed to a port, Zig seems like a strange point of failure to add to my system. If it's simple enough that I can be confident in my flawless manual memory management, I'd just use C, and for anything else, Rust is the far safer choice.

Post reply on HN