Hacker News Reader

> They do require a significant effort to use, but it is significantly less effort than a rewrite in another language

I do not believe this. Most C code by far is not written in a way that makes it easy to formally guarantee memory safety, so the lowest effort path will necessarily involve refactoring it until it does.

And that means that rewriting it altogether into a new language has very few drawbacks, and some additional benefits.

> so the lowest effort path will necessarily involve refactoring it until it does. And that means that rewriting it altogether into a new language has very few drawbacks, and some additional benefits.

No, because while some refactoring is necessary, it is virtually always local. E.g. if the sound checker can't prove that an access is within an arrays bounds, adding a dynamic test just before it (assuming you don't want to add annotations to help the checker) will make it provable.

Rewriting in a new language is certainly one way to reduce or eliminate memory errors, but if your goal is to reduce or eliminate memory errors in existing codebases, there are other ways that are cheaper, more proven, less risky and are applicable to more environments. These tools are already much more heavily used in safety- and security-critical codebases than any new language, so people are slowly getting good experience with them.

I’m not sure what C code bases you’ve worked with but refactoring in a large C code base is almost never local. Especially if it’s a code base that made extensive use of the gcc flags that disable making sure code does not alias.

Providing enough information for the prover does not require a big refactoring, and is significantly cheaper and less risky than a rewrite for an established codebase.

You can also say that for JavaScript, and see how successful TypeScript is.

Yes, you can rewrite everything in Elm, PureScript or even anything that is more similar to JS, but step by step conversion to TS enables a significant quality improvement for large codebases (I personally think it doesn't fare so well on small codebases, where there are some people who use it even for one-off scripts, but at least we can agree on large codebases I think)

> You can also say that for JavaScript, and see how successful TypeScript is.

I'm not sure that's what you meant, but interoperability between C and Rust does seem to be a selling point of Rust (like TS and JS), and allows C codebases to be oxidized gradually rather than rewritten from scratch.

But you can't just add types to C and it becomes rust. It needs serious refactoring. You'd probably go lib by lib, whereas you can rename a JS file to TS and it starts checking types (even without, if you configure it that way).

By the way, I love rust, but I just don't understand the "rewrite all the things" hype. Being battle tested means a lot for low-level libs. You can't guarantee that you ported everything exactly, with bugs and all. Pragmatic solutions like "Checked C" prove a lot in that regard.

> you can't just add types to C and it becomes Rust

You actually can “just” turn C into Rust with something like c2rust. But you haven't gained any safety without refactoring.

Is that not also the case for Checked C?

You cannot be sure that you kept 100% of the semantics when you use c2rust. You need to focus on semantics plus the types. With checked c, you can just keep your focus on the types.

TypeScript doesn't have to solve memory safety problems because JavaScript effectively does not have them. Marking whether things are strings, integers or objects is a much easier problem than e.g. assigning correct lifetimes to C pointers.

P has chronically bad taste when it comes to all things PL-related.

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.

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.

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.

> 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.

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.

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.

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.

I second this: it's because C is a simple language. Modern languages are a cluster-f*k of features and there are still opportunities to code in security holes. Frankly, if you were to boil down the "unsafe" C vulnerabilities it is a small class of exploits, suitable for automated detection.

The interesting thing about C is that it is one of the few languages which has been able to survive without massive changes throughout the years. All these hyped-up modern languages are in flux ALL THE TIME.

> Frankly, if you were to boil down the "unsafe" C vulnerabilities it is a small class of exploits, suitable for automated detection.

Ah, it’s simple, then. We will await eagerly for the non-forthcoming links to all those efforts/implementations.

Or would you like to walk that back to “in principle suitable for automated detection”?

It is certainly not simple, and while there's a limit to what languages can do to assist correctness, C sets a particularly low bar, one that newer low-level languages like Zig and Rust can and do improve upon. Having said that, eliminating memory errors from C is not only doable in principle, but used in practice, so far more than new low-level languages (see, e.g. https://trust-in-soft.com/). It does take a fair deal of work, but for established codebases, the approach is cheaper, less risky and better established than new languages.

I'm a bit hesitant to believe that in the future low level systems programming will be done using languages like Rust, Nim or Zig. I would really love to see that but the programmers I know in that area are very reluctant to accept any additional layer between them and the hardware. It's not even just low level systems programming, but basically any large project with some sort of performance constraints still seems to stick to C++.

Nim is inherently higher-level compared to C, so I understand your point. But how does e.g. Rust or Zig interpose additional layers between the programmer and the hardware? It's not like they introduce complicated runtimes or have expensive FFI. Rust in particular is receiving lots of interest for security-conscious and/or performance-critical projects (browsers, operating systems, cryptography, container technologies, HFT-related stuff). I think that speaks volumes as to Rust's capabilities in this area.

Linus Torlvads on why C and not something else (2012) https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s

C´s success is an effect of UNIX's adoption.

Outside Bell Labs, operating systems were being written in safer systems programming languages, and one of the reasons why Unisys still has enough customers that care to pay for ClearPath MCP, which has a security level no UNIX clone is capable of, thanks NEWP.

Could you explain what additional layer is between me and the hardware when using Rust vs using C? I've written a lot of Rust, and a lot of C, and I can't figure out what you're referring to here.

All the layers that I see Rust and Zig are introducing have to do with the compiler. And if advanced compilation is a “layer” then Mr. zero-cost-abstractions C++ shouldn’t throw stones.

Zig is probably closest to C for the target audience.

Although I wouldn't mind if Pascal or Ada swings back to mainstream's attention.