Hacker News Reader

Comment by sai_c | Hacker News Reader

The problem is most developers and/or management don't care about security. They only care about being done as fast and/or as cheaply as possible.

I'm still not convinced the new languages (Rust & Zig) will change the overall situation.

Why? Simple example in Rust:

    "LOL! I need to get stuff done."
    
    unsafe {
        Really nasty hacks here to circumvent any obstacles.
    }

Example in Zig:

    "LOL! I need to get stuff done. Tests? What tests???"

    zig build-exe example.zig -O ReleaseFast

Trying to solve those security bugs with the help of the language is of course the low hanging fruit. But systems languages will always need an escape hatch for certain problems to be solved. And those mechanisms WILL be abused in the name of "get it done already".

So we really need other means to erase those bug classes. Which ones I don't know.

View on HN

> Trying to solve those security bugs with the help of the language is of course the low hanging fruit.

I'm not sure I follow, it seems to me like it's actually a freaking high-hanging fruit. The amount of engineering and design that goes into creating a safe, fast, low-level programming language (i.e. Rust in this case) is enormous and it requires huge amounts of upfront investment.

The only reason the industry has largely resorted to unsafe languages is because there's many other lower-hanging fruits, e.g. fuzzing, rigorous unit testing, static analysis tools. These help immensely but at the end of the day only take you so far.

Yes, most developers and management don't care about security, that's why it's important to bake the security into the language. Unsafe blocks are inconvenient and stand out, so their usage will be limited, while the remaining code will be safe. 90% safe code and 10% unsafe code is much safer than 100% unsafe code.

Honestly, just let them have a buffer-overflow. That's what we call "junk food" software and if they are negligent, let them fail.

We haven't yet solved the problem of how to most effectively reduce such issues in projects where developers and management do care about security (and there are certainly more now that companies can be heavily fined for data breaches), so let's tackle that one first.

In an iterative development process, it's not the end of the world to get potentially unsafe code out the door and then make it safe later, and there's a huge benefit in having unsafe code labeled and framed in source when security bugs are found.

If you just need to get stuff done in Rust you can just start wrapping things in Rc<>, Arc<>, Box<> or even Gc<>, which introduces runtime overhead on the level of Java. It's safe and allows you to work around thinking about ownership which I think is the main pain-point of using Rust versus other languages. Obviously later if it performance becomes critical you can refactor.

This comment is as low-effort as the hypothetical examples.

Will they do things in that way? Heck, let’s just ask: are they doing things in those ways?

crickets

Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.

This is a problem you can't fix 100%, it has to be taught through catastrophic failure unfortunately. It's a human flaw, rust (et. al.) gives a pathway forward after that.

Reply on news.ycombinator.com