Hacker News Reader

Comment by UncleMeat | Hacker News Reader

Bugs absolutely occur in memory-safe languages. Log4j was a thing.

But a huge number of exploitable vulnerabilities are completely prevented by memory-safe languages. We've spent decades trying like hell to come up with other solutions to prevent these kinds of bugs in languages like C and utterly failed. Nobody knows how to write C or C++ programs of any meaningful scale free from memory safety errors without calling for total rewrites and ballooning budgets by 50x.

> Give it 40 years and people will be saying "rust bad, new thing good".

Of course. Rust will have systemic problems and some new thing will mitigate those problems. This is a good thing, not a bad thing. Why should there be any expectation that a language be the desired language for engineering projects until the end of time?

View on HN

I never said new languages are a bad thing. I only made the point that people mindlessly bandwagoning and repeating the same talking points endlessly is an annoying thing.

Is it mindless bandwagoning? "Memory unsafe languages are an industry-wide emergency" should be a more-or-less constant discussion in the industry, IMO.

Memory safety is certainly a topic worth talking about, but on HN it always ends with the same conclusion: use rust. Is that really the only solution?

I've never seen anything quite like the rust community. They're hell-bent on recruitment. More so than any other language platform I've seen. Personally, I'm just sick of it. It's fine if you don't feel the same way. I was just voicing my frustrations.

No it isn't the only option, plenty of languages are available, specially if automatic memory management is an option on the specific deployment scenario.

Usually we land on Rust only discussions, due to more active advocacy that should known better to avoid tiring the audience, or by defensive attittude from unsafe language folks that push back every single reference to write secure software as a sales pitch for Rust.

> No it isn't the only option, plenty of languages are available

My point exactly.

> to write secure software as a sales pitch for Rust.

You guys already do a good job of writing the sales pitches. I'll leave that to you.

I always mention secure system programming languages going back to 1958. Don't remember Rust being that ancient, and have plenty of critical remarks about Rust as well.

So maybe address that "You guys" to someone else.

Seriously! Kinda like those food services people who harp on and on about gloves. Clean gloves prevent this, clean gloves solve that. And they're not content to just use gloves themselves. They keep evangelizing to recruit everyone to their practice.

It gets annoying to those of us who know how to do safe food prep without wearing gloves.

> Memory safety is certainly a topic worth talking about, but on HN it always ends with the same conclusion: use rust. Is that really the only solution?

No. Of course not. It appears to be the most common solution and community matters, so I suspect it will end up being a dominant solution. But you can (mostly) solve this problem with completely orthogonal approaches. Getting all of your code to run on x86 with MTE enabled is another approach that prevents entire classes of problems.

I'm not a member of the Rust community. My actual work focuses more on the Log4j-style stuff than buffer overruns. But I really don't know what people who are upset about the state of memory safety can do to prevent the "ugh, here come the rust nerds" complaints other than simply never raising the problem - which obviously isn't the right approach.

10 years ago the C and C++ community complained about a different thing whenever memory safety came up. "UGH, stop talking about GCed languages. GC advocates are such aggressive recruiters." Now the complaints have just reoriented themselves.

Reply on news.ycombinator.com