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

71–80 of 93 posts

Re: Zigler: Zig NIFs in Elixir

#71

Post by depr »

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…

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.

Re: Zigler: Zig NIFs in Elixir

#73

Post by tommica »

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…

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

Re: Zigler: Zig NIFs in Elixir

#75

Post by sodapopcan »

depr wrote: post #71
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…

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…

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.

Re: Zigler: Zig NIFs in Elixir

#76

Post by MarcusE1W »

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/

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

Re: Zigler: Zig NIFs in Elixir

#77

Post by throwawaymaths »

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

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

Re: Zigler: Zig NIFs in Elixir

#78

Post by sodapopcan »

ellroy wrote: post #65
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…

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

Re: Zigler: Zig NIFs in Elixir

#79

Post by foldr »

MarcusE1W wrote: post #76
kristoff_it wrote: post #63

Earlier quoted context omitted.

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/

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.

Re: Zigler: Zig NIFs in Elixir

#80

Post by tayloramurphy »

This is an incredibly off-topic, but hopefully a fun fact for folks here.

There was a popular motivational speaker in the 80's and 90's named Zig Ziglar[0]. He was influential on Tony Robbins and his career.

Just shows even how a randomly generated name [1] may not be so unique!

[0] https://en.wikipedia.org/wiki/Zig_Ziglar [1] https://en.wikipedia.org/wiki/Zig_(programming_language)#Ori...

Post reply on HN