Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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


Why did you write your comment in English? Why not Rust or Zig?


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


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

^ just use this.

:disksup.get_disk_data/0, which caches results in the :disksup server that updates every N seconds (configurable) which is what you are referring to.. https://www.erlang.org/docs/26/man/disksup#get_disk_data-0


The author was trying to learn about https://github.com/elixir-sqlite/exqlite which uses C.


Well, it's in Rust now, thanks to your and someone else's comments! https://github.com/waseigo/disk_space




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: