Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

41–50 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#42
post #30

Am waiting for Coq developers to start showing up and asking for Rust projects to be rewritten using Coq / Compcert.

Sadly Compcert is not foss, meaning that they will have a huge problem if they try to push it everywhere. I think that the age of non-free languages and implementations meant for the general public is over, even MS has made their C# and F# implementations free.

Re: Why you should, actually, rewrite some of it in Rust

#43
post #29

Has anyone done any in depth explorations of the safety and security of rust code vs well written C or C++?

Well written the hard part there. I am riding on on the idiomatic C++11/14/17 train right now.

Life over here is great, but I can the warts of the language looking backwards. The promised land in the future doesn't look quite as bright as the promises Rust offers. The only thing keeping me from trying it is the giant codebases in my current projects.

Re: Why you should, actually, rewrite some of it in Rust

#44
post #31
post #14

Earlier quoted context omitted.

> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?

Isn't Go pretty much the modern C, with additions in concurrency?

No, not really. Go left a lot of C behind (pointer arithmetic for example), while also being garbage collected and having modules instead of header files. Coincidentally, while being touted as replacement for C and as the "language of the server", most of its converts come from python, ruby, and node.js evironments.

Re: Why you should, actually, rewrite some of it in Rust

#45
post #26

The author focuses on rewriting low-level media decoders in Rust. I have bit of experience in this area. I've been slowly working on an MPEG2 binary subtitle decoder in Rust: https://github.com/emk/subtitles-rs A while back, I ran my subtitle decoder through "cargo fuzz", and I was pleasantly surprised at the results: Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before…

> Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before they could compromise security. If I'd written this code in C, several of those errors would have been exploitable.

Wouldn't the apples-apples comparison be fuzzing a C program? If AFL would catch the same bugs, Rust isn't better than C in this case.

Re: Why you should, actually, rewrite some of it in Rust

#46
post #14

Earlier quoted context omitted.

> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?

I think his comment was facetious. I think the clue is "no true scotsman," which is a type of fallacy. I think the point is that it's assumed to be better because of the use of "modern," and that it's only valuable if it's rewritten in something modern. Perhaps it's a joke about how old code is actually fine, and that people who get excited about the cutting-edge technology could chill a little bit. Maybe it's just a…

No true Scotsman:

"We found a terrifying vulnerability in your codebase. You should rewrite it in modern C++."

"OK, done!"

"We found a terrifying vulnerability in your codebase. It must not have been modern C++!"

Re: Why you should, actually, rewrite some of it in Rust

#47
post #34

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.

All of your questions are addressed in the article. > Why Rust? Why not Idris? Why not Haskell? it can easily call C code it can easily be called by C code (it can export C compatible functions and structures) it does not need a garbage collector if you want, it does not even need to handle allocations the Rust compiler can produce static and dynamic libraries, and even object files the Rust compiler avoids most of t…

All of these except GC also hold true for the languages that I mentioned.

As for GC, I think that Mercury avoids its use https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazu...

Re: Why you should, actually, rewrite some of it in Rust

#48
post #30

Am waiting for Coq developers to start showing up and asking for Rust projects to be rewritten using Coq / Compcert.

Compcert is guaranteed to compile correct C code to correct assembly (given its TCB assumptions). It doesn't say anything about incorrect C code. So in order to benefit from CompCert, first you have to prove that you have valid C in the first place, which is no easy feat. You'd probably be better off using a language that's designed with verification in mind, like Cogent or ADA/Spark, or waiting for lambda-Rust to become production ready, since in those cases you won't have to prove tedious bureaucratic memory safety invariants for the vast majority of your code, and can focus on functional correctness (or, if you just care about memory safety, you can stop there).

Re: Why you should, actually, rewrite some of it in Rust

#50

Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.

No GC, higher performance than either. Most other safe languages have more overhead than Rust.

As for why not use sanitizers and such: That's an ongoing cost of using the sanitizer. Rewriting in Rust is a one-time cost, and can be done incrementally.

Post reply on HN