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.
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.
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.
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.
:disksup.get_disk_info/1 (from :os_mon) just calls into the underlying OS once, grabs the info, and returns it. It’s not a blocking “long-running monitor” the way a NIF doing I/O in a scheduler thread would be.
https://www.erlang.org/docs/26/man/disksup#get_disk_info-1