I let LLMs write an Elixir NIF in C; it mostly worked (opens in new tab)

It's more of "yeah it worked, but I had to do a lot of hand-holding" and "it passes the tests but I cannot tell if the code has memory leaks".

Actually, I can tell; I ran split on the C source and got things like this:

disk_space.c:144:16: Only storage bin.ref_bin (type void *) derived from variable declared in this scope is not released (memory leak)

So I'm looking into a Rust version with Rustler now.

I think they can. They steal from GitHub and strip the license, same as an LLM.

> As you said, the very title of the article acknowledged that it didn’t produce a working product.

Then why not say "mostly didn't work"? I read the article and that's the impression I got.

The OP's comment isn't an outage, it's more like you intentionally painted it as an outrage with a comment that reads more like an 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.

how does it work? does it shell out to subagent? or it has full access to cli? what makes it not perform rm -rf /

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

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 do something, my bad experiences won't let me say something is low risk. I worked at Microsoft years ago, and after the zillions of vulnerabilities were attacked by people around the time of windows 95 and computers on the net, we did serious code reviews in my team of the data access libraries. There were vast numbers of vulnerabilities. A group of 3 or 4 of us would sit in a room for 3 hours a day, one person a scribe, and we'd go over this c code that was ancient even then - we found problems everywhere, it was exhausting and shocking. The entire data access infrastructure was riddled with memory leaks, strings that were not length limited, input parameters that were not checked or sanitized, etc. I'm sure it was endemic across all components, not just there. We fixed some things, but we found so much shit.

Thank got I wasn't on the team trying to figure out what to do about those problems. I think they end of lifed a lot of stuff.

> Security is a spectrum.

It's less spectrum and more that it's relative. Depends on attacker and what they seek to gain.

An unsecured server is an unsecured server. But there is a world of difference if they are attacked by CIA or local script kiddies.

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

BEAM loads a shared object, that opens the door to anything.

If you want to use a GC language for NIFs, you'd need to hook up your runtime somehow.

IMHO, it makes more sense to lean into the BEAM and use its resource management... my NIFs have all been pretty straight forward to write. All the boiler plate is what it is, and figuring out how to cooperate with the scheuduler for long running code or i/o can be a bit tricky, but if you can do a lot in a BEAM language, the native code ends up being like

Check the arguments, do the thing, return the results.

I'd say for 90% of times you'd want this, spin it off to a microservice over grpc or rabbitmq.

The issue in this case was Opus was pretty crap at C. It kept introducing segfaults.

Get Pro 5.. it will work I promise

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

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.