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

51–60 of 93 posts

Re: Zigler: Zig NIFs in Elixir

#51

Post by [deleted] »

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?

[deleted]

Re: Zigler: Zig NIFs in Elixir

#52

Post by devjab »

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’m not too familiar with Elixir, but I definitely prefer building libraries in Zig and then consuming them in Python, TS, whatever over embedding them inside another language directly.

That being said, you can get IDE language support for embedded code if you use eMacs or vim (and probably other editors as well). As I mentioned I still vastly prefer separating it personally, especially if you don’t necessarily expect your Python or Typescript programmers to be knowledgeable about Zig (or C).

Re: Zigler: Zig NIFs in Elixir

#53

Post by cooljacob204 »

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.

Re: Zigler: Zig NIFs in Elixir

#54

Post by rubyn00bie »

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.

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

Re: Zigler: Zig NIFs in Elixir

#55

Post by travisgriggs »

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…

> Does anyone actually enjoy using these systems that encourage you to embed programming-language X code in programming-language Y heredocs?

Isn’t that essentially any web application?

Re: Zigler: Zig NIFs in Elixir

#56

Post by throwawaymaths »

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.

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

Re: Zigler: Zig NIFs in Elixir

#57

Post by el_oni »

johnisgood wrote: post #34
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.

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

Re: Zigler: Zig NIFs in Elixir

#58

Post by filmor »

kuon wrote: post #33
kansi wrote: post #30

Earlier quoted context omitted.

> I use zig a lot in elixir nif, for things like audio and video processing Sounds interesting, is it open source? I am interested in seeing how the code layout looks like when mixing Zig and Elixir

I don't have open source code base to share but here it how it looks like: // the_nif.zig fn init_imp( env: ?*erl.ErlNifEnv, argc: c_int, argv: [*c]const erl.ERL_NIF_TERM, ) !erl.ERL_NIF_TERM { if (argc != 0) { return error.BadArg; } return try helpers.make("Hello world"); } export fn media_tools_init( env: ?*erl.ErlNifEnv, argc: c_int, argv: [*c]const erl.ERL_NIF_TERM, ) erl.ERL_NIF_TERM { return init_imp(env, argc,…

This won't work on Windows as the BEAM uses a slightly different NIF initialisation method there.

Re: Zigler: Zig NIFs in Elixir

#59

Post by Muromec »

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

Wait, erlang has sigils?

Re: Zigler: Zig NIFs in Elixir

#60

Post by com »

Muromec wrote: post #59
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

Wait, erlang has sigils?

Yeah, there’s a bit of a developer experience push going on in erlang world, which is great!
Post reply on HN