> No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C.
Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project:
* String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke.
* For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse.
* Asynchronous programming. Rust has built-in coroutine support; C does not.
* Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail!
* Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy.
* Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.)
I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings.
Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.
Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project:
* String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke.
* For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse.
* Asynchronous programming. Rust has built-in coroutine support; C does not.
* Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail!
* Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy.
* Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.)
I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings.
Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.