Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I let LLMs write an Elixir NIF in C; it mostly worked

overbring.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#41

Post by rs186 »

true_religion wrote: post #22
drumnerd wrote: post #17

I would never ever let an LLM anywhere near C code. If you need help from LLM to write a NIF that performs basic C calls to the OS, you probably can’t check if it’s safe. I mean, it needs at least to pass valgrind.

Security is a spectrum. If you totally control the input going into a program, it can be safe even if you didn't test it for memory leaks. The only errors that occur will be truly erroneous, not malicious and for many solutions that's fine. At the very least, it's fine for personal projects which is something I'm getting into more and more: remembering that computers were meant to create convenience, so writing small…

Outside personal projects, my take is that security really just comes in two flavors: CVE vs no CVE. I pick the former.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#42

Post by overbring_labs »

wordofx wrote: post #36

This was built copy pasting results from chats? Not using an ide or cli like Claude Code or Amp? Why such a manual process. This isn’t 2023…

Because what difference would it make, given the bad quality of code?

Also, is Claude Code free to use?

The manual process has the upside that you get to see how the sausage is (badly) made. Otherwise, just YOLO it and put your trust in GenAI completely.

Furthermore, if there is the interim step of pushing to GitHub to trigger the build & test workflow and see if it works on something other than Linux, is the choice of Vibe-Coding IDE really the limiting factor in the entire process?

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#43

Post by overbring_labs »

SweetSoftPillow wrote: post #40

It's interesting why the author used weaker models (like Grok 3 when 4 is available, and Gemini 2.5 Flash when Pro is), since the difference in coding quality between these models is significant, and results could be much better.

It's just that Grok 3 is faster than 4, so I've set it by default. But point taken, I'll try out the newer ones now that I'm converting it to Rust.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#44

Post by overbring_labs »

brokencode wrote: post #31
flax wrote: post #2

"it mostly worked" is just a more nuanced way of saying "it didn't work". Apparently the author did eventually get something working, but it is false to say that the LLMs produced a working project.

Ok. But what are you even reacting to? Who is saying that it produced a working product? As you said, the very title of the article acknowledged that it didn’t produce a working product. This is just outrage for the sake of outrage.

Amen, thank you for noticing. The goal here was not to produce something of stellar quality, which is anyway out of the question as I don't have the skills/knowledge to evaluate anything other than "it returns the Elixir map I wanted". It was to see if this is feasible at all.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#45

Post by overbring_labs »

weatherlight wrote: post #12

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.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#46

Post by overbring_labs »

SweetSoftPillow wrote: post #40

It's interesting why the author used weaker models (like Grok 3 when 4 is available, and Gemini 2.5 Flash when Pro is), since the difference in coding quality between these models is significant, and results could be much better.

Holy moly, you weren't kidding. Grok 4 is so much better. Thanks!

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#47

Post by SOLAR_FIELDS »

Alive-in-2025 wrote: post #35
true_religion wrote: post #22

Earlier quoted context omitted.

Security is a spectrum. If you totally control the input going into a program, it can be safe even if you didn't test it for memory leaks. The only errors that occur will be truly erroneous, not malicious and for many solutions that's fine. At the very least, it's fine for personal projects which is something I'm getting into more and more: remembering that computers were meant to create convenience, so writing small…

For personal projects, ok security is different. But get out of that, and I'd do it even for that, you need defense in depth. You think you sanitized your input but your C program has a bug and a vulnerability - or your Java program or whatever has bugs. Almost everything has some bugs, and thus your vulnerabilities will hit eventually in your C program, even if you were careful. I'd say absent some temporary hack to…

I mean, what I hear from that is that an LLM who you tell to write as safe code as possible is probably going to do a better job than your average human engineer at it, and you still have to do the same verification work either way. So why not have the LLM write the code and you instead just spend time verifying it? In other words, if I give an LLM and an average C developer the same task who will perform better? Even if the average C developer does better but takes N hours to write it and I still have to spend M cycles reviewing the average C developer's work, I'd rather have N be written by a machine since I have to pay M anyway regardless of whether it came from a machine or human.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#48

Post by weatherlight »

leansensei wrote: post #25
weatherlight wrote: post #12

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.

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.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#49

Post by leansensei »

weatherlight wrote: post #48
leansensei wrote: post #25

Earlier quoted context omitted.

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

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.

Re: I let LLMs write an Elixir NIF in C; it mostly worked

#50

Post by abrookewood »

overbring_labs wrote: post #32
drumnerd wrote: post #17

I would never ever let an LLM anywhere near C code. If you need help from LLM to write a NIF that performs basic C calls to the OS, you probably can’t check if it’s safe. I mean, it needs at least to pass valgrind.

I mean, you aren't wrong. I'm looking into converting it into Rust with Rustler right now.

Yep, was wondering why you didn't go down that path in the first place. Seems way safer.
Post reply on HN