4 ms·
They are both great languages but rust is clearly the one that experts in both generally prefer. I have some friends who make some strange arguments for c++ but
by alexnewman 10y ago
They are both great languages but rust is clearly the one that experts in both generally prefer. I have some friends who make some strange arguments for c++ but I continue to be interested why people don't want to make the switch. That being said LEGACY
- esrauch 10y agoI would be careful about what you generalize from "experts in both generally prefer rust", as there is likely a survivor bias in there. Since C++ has been around much longer the situation is likely "many C++ experts try Rust, the ones that love it become Rust experts", basically if "preferring Rust" ends up being a soft prerequisite to becoming a Rust expert then those who are experts in both will prefer Rust. I also think there's a bunch of other factors that lead to a similar bias: general pride in favor of the less mainstream languages, for languages like Rust or Haskell it is probably the case that more of the code in that language is written by "hardcore" people, which means code written in that language is higher quality (but not necessarily through any intrinsic benefit of the language, instead through a selection of who is writing that language).
- fiedzia 10y ago> not necessarily through any intrinsic benefit of the language, instead through a selection of who is writing that language I'd say that such selection is intrinsic benefit of the language.
- esrauch 10y agoI just meant to point out that if broad usage actually implies worse average code, then the same thing would happen if rust "wins". You can't use it as an argument for what should win since "has won" will always lead directly to a "shouldn't be winning" argument.
- sidlls 10y agoI have just a couple of points. First, please be careful with the "experts" broad brush. Not all, and possibly not most, experts will agree on many things. Moreover, actual experts will understand that there are pros and cons that are context dependent. I would hesitate to label as "expert" anybody who categorically prefers one over the other for all cases. That's more like zealotry than expertise. Second, for my part the biggest hurtles are in two parts. One is that at the boundaries of speed versus provable safety. At some point I don't need and can't afford the cycles added by boundary checks and other Rust guarantees, and the mechanisms provided to mitigate them are as cumbersome as writing (unprovably) safe C++ code (e.g. "const&", "std::move" and other similar constructs) compared with the equivalent Rust. The other is a more a branding problem: gratuitous maligning of C++ is problematic, and projects a sort of arrogance that I find subjectively distasteful.
- steveklabnik 10y agoMost of Rust's guarantees are provided at compile time and have no overhead, just to be clear.
- sidlls 10y agoYes most, but not all.
- Yoric 10y agoOut of curiosity, have you hit examples in which the runtime cost of Rust's safety was problematic – and couldn't be worked around without losing either safety or clarity?
- UtherII 10y agoThe most obvious case is bound checking. If you have a code with direct array indexing you have to use unsafe code or loose a little bit of performance.
- dbaupp 10y ago