Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

unhandledexpression.com

Post reply on HN
Print view View original

151–160 of 300 posts

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

#151

Post by FRex »

akavel wrote: post #18
w8rbt wrote: post #5

If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…

To help protect you from these unsafe programs in obsolete languages I compiled a small list of software in C or C++ that you need to delete ASAP to ensure your safety: 1. Windows OS. 2. Windows kernel (mobile too). 3. Linux kernel (android too). 4. Bash, zsh, csh, fish, etc. 5. C#, Java, Ruby, Python, etc. 6. Parts of Rust backend, namely LLVM :(. 7. Apache, nginx, etc. 8. Filesystems. 9. Most drivers. 10. Router software. 11. Linux graphical environments (most/all are C or C++ and use GTK+ or Qt). 12. Any other kernels/OSes (any BSD, Haiku, iOS, etc.).

Be sure to not use rm, bash, zsh, windows explorer right click + delete, etc. to delete these as that'd be relying on definitely broken software written in obsolete languages too!

On a more serious note: IF you knew C++ at all you'd really know better than to say things like these and I have no idea where did you get the information about UB, overwriting random memory or using exceptions (Qt is famous for using none at all for a good reason) being common in C++. And what people use is the sane subset. When was the last time you've seen outside of some obscure specific place any of: virtual or non public inheritance, pointers to members, switching [] operator arguments for C arrays, placement new, manually calling destructors, using templates or macros to do compile time programming, etc? Considering your ignorance of the fact you use tons of rock solid C++ software daily I'd think you don't know what most or all of these even are.

Rust fanboys like you who speak of C and C++ programmers like of idiots who write unsafe programs that endanger people is exactly why I'm not using Rust (yet?). If a community seems that toxic at a distance I'm not even going to try to come closer. It's even worse than Java or C# fanboys who seem to forget what their VMs are in because they are at least fanboying over HUGE enterprise proven languages. Rust on the other hand does have a few big projects (but Servo is a toy and few lines around hundreds of thousands of C++ in Firefox doesn't make it a Rust project) and looks more promising than D ever did but fanboys are acting like it's the next C++, Java, Julia and C# combined and grasping at straws "one package in choco is in Rust!", "easy to call C code!", ...

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

#152

Post by Rusky »

CalChris wrote: post #141
pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> the syntax is almost as noise-free as exceptions No. const USAGE: &'static str = "usage string"; I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programm…

The comment was about error handling syntax, not constant declaration syntax. The comparison being made is between `result = foo(); if (!result) { ... }`, `foo();`, and `foo()?;`.

> And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C.

Sounds wrong to me. People have done things like booting up x86 with all of the hardware bit-twiddling behind safe interfaces (for example: https://os.phil-opp.com/).

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

#153

Post by idyllei »

I would love to learn Rust, but the learning curve seems a bit too steep for me. The whole struggle with lifetimes is what has kept me from diving in. It seems impossible to me to figure out how to use them correctly. Plus the redundant syntax, I guess. If those things weren't an issue for me, I would gladly try to learn Rust.

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

#154

Post by VHRanger »

moomin wrote: post #148
_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

Show me the programming language community that's a fan of the language it's intending to supplant and we'll talk. :)

D has a much better attitude towards it.

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

#155

Post by FRex »

akavel wrote: post #36
lj3 wrote: post #33

Earlier quoted context omitted.

> Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. Why the sarcasm?

I'm afraid I was not being sarcastic. Sorry. This is a totally honest and dead serious opinion from a long time C & C++ user. ("stars aligning" here means "you must also have luck". As I said: see SQLite.)

Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software. Seriously. I'll let you keep LLVM so you can play with Rust.

There's disliking language or the boilerplate it forces on the programmer which I can REALLY understand in case of these two and there's being a jerk and an idiot and saying any C++ program that isn't few lines is broken by the UB, you need stars aligning to write safe C, they are impossible to write anything substantial, safe and useful in, etc. and anyone who tells you otherwise is implicitly a very bad programmer who does their job wrong and endangers people.

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

#156

Post by rbehrends »

anp wrote: post #81
rurban wrote: post #74

Earlier quoted context omitted.

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

Can you be specific about which languages you include in the category of "fast and SAFE"?

Rather than answering this question directly, let me perhaps explain why Rust is getting so much pushback.

With the exception of dynamic memory, virtually all high-level languages that aren't called C/C++ are memory-safe. Memory-safety is not a new feature. Inherent memory-unsafety was a "feature" introduced by C and its immediate ancestors (and later perpetuated by C++) in order to deal with the performance limitations of 8/16-bit architectures and optimizers that were far more limited than they are now.

For many of the older of us – before C/C++ took over much of the world – safe languages were the norm (with the exception of dynamic memory for languages without automatic memory management).

So, in our experience, Rust doesn't really offer us much except an alternative to automatic memory management that imposes a significant cognitive burden. That tradeoff is not always attractive. It presupposes that any and all forms of automatic memory management are not an option. Not a modern incremental, generational garbage collector, not Swift-style ARC (where unnecessary RC updates are optimized away), not some of the various and sundry automatic memory management techniques that researchers have come with over the years (such as MLKit's regions).

If you have this kind of programming background, the tradeoffs that Rust offers are not at all attractive. Not only are the use cases where you need exactly Rust's value proposition relatively rare, the ongoing and often aggressive evangelism sucks up oxygen in the open source commons, so to speak, that could go towards alternative efforts.

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

#157

Post by steveklabnik »

idyllei wrote: post #153

I would love to learn Rust, but the learning curve seems a bit too steep for me. The whole struggle with lifetimes is what has kept me from diving in. It seems impossible to me to figure out how to use them correctly. Plus the redundant syntax, I guess. If those things weren't an issue for me, I would gladly try to learn Rust.

Lowering the learning curve is a huge objective of this year!

> The whole struggle with lifetimes

How did you try to learn them? I'm interested in trying to make this easier!

> the redundant syntax

Which bits are redundant?

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

#158

Post by CalChris »

Rusky wrote: post #152
CalChris wrote: post #141

Earlier quoted context omitted.

> the syntax is almost as noise-free as exceptions No. const USAGE: &'static str = "usage string"; I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programm…

The comment was about error handling syntax, not constant declaration syntax. The comparison being made is between `result = foo(); if (!result) { ... }`, `foo();`, and `foo()?;`. > And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C. Sounds wrong to me. People have done things like booting up x86 with all of the hardware bit-twiddling behind safe interfac…

setjmp wasn't even supported. I had to use an LLVM intrinsic. This only barely worked if I put the setjmp and the longjmp in separate files.

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

#159

Post by Rusky »

CalChris wrote: post #158
Rusky wrote: post #152

Earlier quoted context omitted.

The comment was about error handling syntax, not constant declaration syntax. The comparison being made is between `result = foo(); if (!result) { ... }`, `foo();`, and `foo()?;`. > And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C. Sounds wrong to me. People have done things like booting up x86 with all of the hardware bit-twiddling behind safe interfac…

setjmp wasn't even supported. I had to use an LLVM intrinsic. This only barely worked if I put the setjmp and the longjmp in separate files.

Why is setjmp such a major issue for you? It's a C language feature, not a "real low level to the metal systems programming" requirement.

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

#160

Post by danenania »

ekidd wrote: 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…

Is there any way to lessen the burden by automating conversion of straightforward portions of a C codebase to Rust? They seem similar enough conceptually and semantically, if not syntactically, that a lot of boring C code might be fairly easy to translate?
Post reply on HN