13 ms·
Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made
by Veedrac 11y ago
Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made abstractions.
The one everyone mentions is that Rust gets memory safety without garbage collection. But there are cooler things, like being able to implement units in the type system. Rust also gets safety right in the sense that its defaults are good - its primary random number library has ChaChaRng and IsaacRng instead of a Mersenne Twister, for example.
The sensible library design goes everywhere, from Rust's functional roots, high-quality zero-overhead iteration protocol (none of the mess that C++ gives you) to simple things like a well-designed composable hashing standard.
Even stuff like comparing C++'s move, copy and constructor semantics are much nicer in Rust, and in most cases even lower overhead: everything is a memcpy and is implemented automatically.
I can go on. Rust is one of the few languages that IMHO gets string handling right, and has good unicode support from the outset. It's easier to write error-proof filesystem code than any other language I've used. Threading isn't a mess.
There are disadvantages, such as Rust being one of the hardest languages to learn. Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. There are lots of nonlocal typesystem effects, largely due to the thirst for safety.
But it's a good language. Definitely one of the most exciting I've seen in a while.
- ewillbefull 11y ago> Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. Maybe it's because I'm used to it, but do you have an example of why you think this? I think with type inference being pervasive, I've never been annoyed by generics. Additionally with type aliases a lot of pain can be avoided. One of the ugly parts is that call-site type parameters, when given explicitly, have an ugly (but consistent) syntax. This is probably unfixable. Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express, but work is being done to improve this now.
- Veedrac 11y agoYour second paragraph basically lists the difficulties. It's definitely a compromise.
- ewillbefull 11y agoWell, not really, I was just stretching my brain to think of criticisms you might have been alluding to. I still don't know what is overly explicit about Rust's generics.
- Veedrac 11y agoWould you not call this uncomfortably explicit: https://github.com/rust-lang/rfcs/pull/105#issuecomment-64107212 https://github.com/rust-lang/rfcs/pull/105#issuecomment-6410... ? Type inference does make such things easy inside function bodies, but there are a lot of functions so it's not a complete solution. Even some of the uncomposed iterator signatures are uncomfortable. An example: fn partition<B, F>(self, mut f: F) -> (B, B) where Self: Sized, B: Default + Extend<Self::Item>, F: FnMut(&Self::Item) -> bool D gives you Range partition(alias predicate, SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.stable && isRandomAccessRange!(Range)) || (ss != SwapStrategy.stable && isForwardRange!(Range))) which, if changed to only support stable partitions (like Rust), would be Range partition(alias predicate, Range)(Range r) if (isRandomAccessRange!(Range)) Note that I'm _not_ saying D's solution is better. I'm saying I find it more comfortable.
- sanxiyn 11y agoSo it's lack of abstract return types. Thanks for clarifying.
- deleted 11y ago[deleted]
- azth 11y ago> Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express Out of curiosity, impossible to express how? Can't one just store the return value in a variable, investigate its type, then copy-paste that as the function return type?
- Manishearth 11y ago"Annoying to read" can be solved with typedefs, but there are types impossible to express. At the moment I think closures are impossible to express as named types.