Hacker News Reader

Comment by throwaway63467 | Hacker News Reader

Does safety matter for this kind of software? It’s mostly internal tooling used by researchers and statisticians. I get it rust is cool but safety isn’t the prime concern here I think.

View on HN

Author's comments are dead unfortunately so I'll repost w fragment from them here:

> It's not about memory safety per se. It's about not losing an hour of analysis because a malformed .sav file or a zero-variance sample triggered a segfault or silent wrong output. SPSS crashes on bad data.

Why not [vouch] the dead comment?

I've done some without any effect. I'm guessing there may be some sneaky moderation in play. I did email the mods though.

A couple days ago we had 0-click RCE in MS Paint. At this point, we must think about safety everywhere, we're entering AI era where vulnerabilities are easy and fast to find, exploit and chain in automated ways, and it only accelerating.

Rust is the prime language for vibecoding because the compiler checks most of the issues for you. This is meant to be part of the ArtCraft suite, so it is intended to be developed and managed with AI agents.

People always seems to confuse correctness as in „it compiles“ vs. „it does what I intended it to do“, not sure how Rust helps with that as it won’t solve mismatch between intent and implementation. Or how could it? Main problem with vibe coding is that you almost always under specify requirements so the agent will fill in the blanks and make choices for you, the language it implements these choices in doesn’t matter much in my opinion, agents will produce correct code from a detailed specification almost always which is why they are so good at translating between languages, they are terrible at interpreting requirements not specified or derivable for complex software though. Rust can’t solve that.

Segmentation faults are super easy to get from AI agents writing C. If you want an agent vibecoding in a compiled language, you have to use Rust. That doesn't mean that the software does what is intended (that requires a review agent and then an orchestrator at minimum) but it makes things a lot easier.

There are MANY safer-than-C alternative languages compiled to efficient native code. I don't vibe code, but vibe coding seems popular with Nim, for example. I'm sure it's a very long list. "Safer-than-C" has been a slogan for PLangs for the entire history of modern computing. { Before people groan about "but, but mem.mgmt", that is often negligible overhead in context (depending on context and overhead). When it is not negligible, the same problems in Rust will usually have "allocations optimization" fiddling and such, so you don't really avoid "fighting memory". Ada people often just avoid dynamic allocation entirely. Java people will spot-optimize certain things. Ocaml, etc., etc. AMM is not even a property of a PLang as much as a runtime since even spartan C has -lgc with Boehm. }

I feel like Nim is too expressive to be a good vibe-coding target. That is one feature that I think is generally good for people writing code and really bad for agents.

You can take a lot more "smart" shortcuts in Nim, that are hard to reason about, and probably even harder when an automated system writes them.

I very much agree at the stylistic and syntactic abstraction levels. One reason I don't do it myself is that I find chatbot "judgement" for such things awful, usually highly contaminated by weaker PLangs. To be fair, there is probably not much sampling data in several relevant directions. Honestly, I think it Araq's personal tastes in tooling drives people to vibe Nim, but I do hear about it a lot.

> not sure how Rust helps with that as it won’t solve mismatch between intent and implementation.

It's not rust specific, but any language which allows you to work on a higher level and with better typing helps close that gap. For example for a long time Linux kernel had an issue with marking user/kernel addresses which opened it up to bugs and security issues. In C those are just numbers. In Rust this is moot and correct by default because user addresses are explicitly UserPtr.

So yes, sometimes a better language allows you make some unintended things explicitly not compile. It won't solve the issue completely, but the scope of the mismatch gets much smaller.

It's not about memory safety per se. It's about not losing an hour of analysis because a malformed .sav file or a zero-variance sample triggered a segfault or silent wrong output. SPSS crashes on bad data. Researchers work with messy data. Rust's Result type makes "handle every error explicitly" the default, not an afterthought. That's why I chose it.

Reply on news.ycombinator.com