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

11–20 of 93 posts

Re: Zigler: Zig NIFs in Elixir

#11

Post by throwawaymaths »

Miner49er wrote: post #8
G4BB3R wrote: post #3

Are sigils (~) restricted to one char? To me seems ~Zig would be more clear and short enough.

Erlang sigils are not, they can be any length, limited to characters allowed in atoms. Elixir sigils also allow multiple characters in the name, but chars after the first must be upper case, according to the docs. So for Elixir, it would have to be something like ~zIG

According to the docs, must be all upper case:

> Custom sigils may be either a single lowercase character, or an uppercase character followed by more uppercase characters and digits.

https://hexdocs.pm/elixir/sigils.html

Re: Zigler: Zig NIFs in Elixir

#12

Post by Miner49er »

throwawaymaths wrote: post #11
Miner49er wrote: post #8

Earlier quoted context omitted.

Erlang sigils are not, they can be any length, limited to characters allowed in atoms. Elixir sigils also allow multiple characters in the name, but chars after the first must be upper case, according to the docs. So for Elixir, it would have to be something like ~zIG

According to the docs, must be all upper case: > Custom sigils may be either a single lowercase character, or an uppercase character followed by more uppercase characters and digits. https://hexdocs.pm/elixir/sigils.html

Ah yeah, you're right.

Re: Zigler: Zig NIFs in Elixir

#13

Post by drawnwren »

alberth wrote: post #10
hinkley wrote: post #9

Earlier quoted context omitted.

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.

Hence why Rustler is of so much interest since it provides more protections against this happening. Discord is a big Erlang + Rustler user.

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.

Re: Zigler: Zig NIFs in Elixir

#14

Post by jhgg »

drawnwren wrote: post #13
alberth wrote: post #10

Earlier quoted context omitted.

Hence why Rustler is of so much interest since it provides more protections against this happening. Discord is a big Erlang + Rustler user.

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

Re: Zigler: Zig NIFs in Elixir

#15

Post by derefr »

Does 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 sane if/when you just have a separate file (e.g. `foo.zig`) for the guest-language code, and then your host-language code references it.

Re: Zigler: Zig NIFs in Elixir

#16

Post by alberth »

drawnwren wrote: post #13
alberth wrote: post #10

Earlier quoted context omitted.

Hence why Rustler is of so much interest since it provides more protections against this happening. Discord is a big Erlang + Rustler user.

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.

Do you mean Rustler?

Yes, it's Apache 2.0

https://github.com/rusterlium/rustler

Re: Zigler: Zig NIFs in Elixir

#17

Post by systems »

derefr wrote: post #15

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

I initially agree

But, if all you do is write elixir wrappers around the zig function, to completely hide the foreign language functions, keeping both the wrapper and implementation in the same file, even if two different languages doesn't seem horrible, but again, keeping them in two file doesn't seem like a huge difference too

I think its really a matter of taste, both options viable

Re: Zigler: Zig NIFs in Elixir

#18

Post by toast0 »

derefr wrote: post #15

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

I've done some assembly in C, and for big functions, yeah, I want it in its own file, but smaller things often make sense to embed. I'm not sure if I'd like my nif code embedded into my erl files (assuming this works for Erlang as well), but it could conceivably make the nasty bit of boilerplate around ERL_NIF_INIT in the NIF (which I have to do in C anyway) and exit(nif_library_not_loaded) in the erl go away, which would be nice.

It's certainly possible to get syntax highlighting on the embedded code, but you'll need to work with your syntax highlighter; it certainly helps if you're not the only person using it.

But then again, I worked without syntax highlighting for years, so I'm happy when it works, but when it doesn't, I'm ok with that too.

Re: Zigler: Zig NIFs in Elixir

#19

Post by kristoff_it »

hinkley wrote: post #9
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…

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

Re: Zigler: Zig NIFs in Elixir

#20

Post by bmitc »

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…

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.
Post reply on HN