bzip2 is tiny, has relatively low overhead in Fil-C (forget exactly what it is but not 4x), and last I checked this Rust version still has >100 uses of unsafe.

▲

galangalalgol 4 days ago | parent [-]

Fil-C doesn't stop the data race problems the borrow checker would catch does it?

Has anyone tried pointing an agentic ai at recreating a c utility by looking only at the man page and using differential fuzzing? It isn't a port, so no licensing issues, and the code would use unsafe, and presumably be more idiomatic. I have no idea if it would ever complete, or just get stuck in an endless loop. Or even if it did succeed, how many joules it would use.

▲

krater23 4 days ago | parent | next [-]

I'm sure when you try to get a AI to recreate such a tool, ths code would be unmaintainable, bloath, slow and shitty, but in the end it would work in some way. Interesting topic, but nothing to go productive with.

▲

pizlonator 4 days ago | parent | prev [-]

> data race problems

No, Fil-C just makes races memory safe.

Also this is sort of changing the topic a bit since bzip is single threaded

	▲	galangalalgol 4 days ago \| parent [-]
		Even if it wasn't single threaded, it would probably have been fine grained OMP style multithreaded which runs into far fewer issues. I was just making sure I understood what Fil-C was doing. I hadn't heard of it. It seems like a great thing.