I feel like a lot of the cool things in Rust get obscured in the never ending safety dance. There is some rad stuff in Rust compared to its closest competitors (C and C++) -- cleaner error handling, a standard package manager, no aliasing -- I want to hear about what else Rust can do for me! More safety guarantees, ehhh, I'll take them but they aren't a huge win in our work.
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 programming, everything is unsafe; so you may as well be writing in C.
Go is pretty minimal. They knew how to say no. I like modern C (C99 and C11). It has most of the good ideas from C++.
const USAGE: &str = "usage string";
const USAGE = "usage string";
We don't like it either; there's a replacement coming. We reserved the "macro" keyword before 1.0 and made the current one use the less-good "macro_rules" to help ease the eventual transition.
But.. but.. Scheme macros are so nice!
> 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/).
Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.
And for now, there are definitely ways to handle signals using libraries.
Do you have any source that can confirm that? Because what you wrote seems really wrong. I see linuxes/bsd/unix EVERYWHERE (Android/iOS/OSX/almost all backend servers etc.)
You might want to take a look at this series: http://blog.japaric.io/fearless-concurrency/ .
As a note to others, arithmetic checks doesn't happen in release builds unless you used something like checked_add, add "debug-assertions = true" to [profile.release], or use -C overflow-checks flag with the compiler.
https://github.com/nox/rust-rfcs/blob/master/text/1535-stabl...
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 running with garbage values).
Runtime arithmetic overflow checks have saved me many times. Knowing I have this safety net I can be cavalier about using smaller integer types.
I don't have to free memory explicitly, and yet peak mem usage is as minimal as it can be, and I did not have a leak yet.
And the whole ecosystem is fantastic compared to C. There's a culture of having unit tests. Ease of using dependencies via Cargo, and the zero-cost abstractions, help having dependencies broken down into small and focused libraries.