Hacker News Reader

Comment by dikaiosune | Hacker News Reader

I'm someone currently in the process of drinking the Rust kool-aid, in part because the goals of the language are very closely aligned with what Bernstein proposes here. Further, because of the memory model, the compiler can produce quite competitive performance while still preventing the execution of any undefined behavior (related to his last strawman in the bullet list).

I get that even if Rust offers a panacea to the issues he mentions (which it may or may not, I'm no expert), there's still an awful lot of C code that would need to be deprecated and rewritten. But surely there'd be value in efforts to get away from a language that has such a loose standard?

View on HN

Oh, on Rust being a panacea: here are the areas of the language which are currently a bit under-specified https://github.com/rust-lang/rfcs/blob/master/text/1122-lang...

Surprise: Rust is not a panacea :)

There is, however, a lot of work being done into formalizing Rust. It's just started, however. Hopefully we will end up with a lot of things being formalized someday in the future. Like all efforts, it's gonna take a lot of time.

I wonder how hard it would be to create a C -> Rust transpiler. The output would probably be God-awful, but it could be a start to moving away from C towards Rust.

Yes, the problem with doing this is that Rust really imposes certain kinds of design constraints that makes this hard. Like, you COULD, but you'd make a lot of use of unsafe, in a way that's not idiomatic.

Part of the problem here is that the program may rely on subtleties that make the translation hard. I've seen experienced C or C++ people come into the Rust IRC and ask why certain things aren't allowed, it's often due their code relying on certain aspects of the looser model.

That said, it's very possible to go unsafe first and then refactor. It just might not be easy.

Another way of making the transition is to pick a component and only re-write it. This is the approach Firefox is taking, for example.

A guess: very, very difficult. Writing code to satisfy Rust's checking is not much harder than writing C[1], but converting arbitrary C to satisfy Rust is something completely different.

[1] An' I say it as shouldn't. C is my natural language.

It's probably going to be a hard row to hoe to get any code that doesn't always visibly break out of circulation. That said, I think that's why there's huge value in moving to languages where you do break things more visibly.

Ultimately it comes down to time, and "It looks like it works but might do something wrong sometime" is a weaker argument to delay release than "It will not compile/run".

Reply on news.ycombinator.com