Comment by weatherlight

1 day ago

Why C instead of Rust or Zig? Rustler and Zigler exist. I feel like a Vibecoded NIF in C is the absolute last thing I would want to expose the BEAM to.

8 comments

weatherlight

Reply
overbring_labs  1 day ago

Given the amount of issues the code had when I ran splint on the C file, I agree. The question was for me whether I can get something working to get over the "speed bump" of lacking such a function for the API client I'm writing.

I'm now re-vibe-coding it into Rust with the same process, but also using Grok 4 to get better results. It now builds and passes the tests on Elixir 1.14 to 1.18 on macOS and Ubuntu, but I'm still trying to get Grok 3 and 4 to fix the Windows-specific parts of the Rust code.

qualeed  1 day ago

Why does every post that mentions something other than Rust or Zig get a comment saying "Why not Rust or Zig"?

leansensei  1 day ago

Why not C? It made no difference, we're talking about a few function calls.

  • weatherlight  1 day ago

    because the author self admitted they don't know C! One of the reason why people use the Beam VM is because its robust and fault tolerant.

    a lot of the choice here are made at the expense of VM's health.

    also why wouldn't anyone just use :disksup.get_disk_info/1. (Thats immediate) calling :disksup.get_disk_info/1 won’t mess with the scheduler in the way a custom NIF or a big blocking port might.

    I see the above code/lib and just see reflags all over the place.

    • leansensei  1 day ago

      The post explains why I don't want to use disksup. You have to start an extra application (os_mon) and configure disksup to update the starts more frequently than the default of every 30 minutes.

      Do we really need to do all that instead of the equivalent of a df?

      Agree about the C code, which is why the latest version (on GitHub, the HEAD, not yet released in Hex.pm) is now using Rust and Rustler.