Living with the Rust trademark
Living with the Rust trademark
Posted Jul 22, 2022 13:14 UTC (Fri) by tialaramex (subscriber, #21167)In reply to: Living with the Rust trademark by Sesse
Parent article: Living with the Rust trademark
C++ cannot easily add nice syntax or deprecate bad old syntax, which is why it got e.g. the ugly co_await and why it *loves* re-using existing keywords like "delete" and "auto" even when that's probably a bad choice. In Rust the await keyword was added to 2018 edition, yet a Rust 2015 library could cheerfully name a variable, or a function, or (though it's bad style) a type 'await' and that will just work because that's not a keyword in their edition, even with a brand new compiler and even though you can use that library from your 2018 edition program.
C++ programmers cannot trivially do language upgrades because both the syntax and semantics of the language change from one version to another. Large C++ organisations may have a multi-year upgrade programme, especially for C++ 11 or C++ 20 while ordinary Rust programmers can expect a new Rust compiler to just deliver new features and not break stuff.
As an extreme example of this, one of the proposals for perhaps C++ 26 would be a Try operator similar to Rust's ? but C++ has the ternary operator ?: and so there's a conflict. The author concedes it will be necessary to name it something else, and suggests ??. So that's less ergonomic, needlessly different (other languages have ?? operators but Try is not what those operators do). The result is that the disfavoured ternary operator gets to hog this useful symbol forever, lest incompatibility be introduced.
[ Rust doesn't have the ternary operator, but if is an expression, so you can write let x = if predicate { this } else { that }; ]
Posted Jul 22, 2022 13:29 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (3 responses)
As someone who has regularly done language upgrades in C++, both professionally and in FOSS projects, I do beg to differ. :-) The big holdup is actually getting language support on all platforms you care about; after that it's usually one or two cleanup patches, and the rest is updating code to use the new features.
> Large C++ organisations may have a multi-year upgrade programme, especially for C++ 11 or C++ 20 while ordinary Rust programmers can expect a new Rust compiler to just deliver new features and not break stuff.
Do large Rust organizations even _exist_ yet? Do we have any experience with actually deploying it across a multitude of platforms in large projects and organizations (10k+ developers)? Because that's the scale where you're talking about C++ upgrade woes. Firefox has something like… 350k lines of Rust?
Look, there are lots of nice things about Rust. But the backwards compatibility story is not among them. Forwards compatibility, sure, but forward is not the only way to care about. When I search for a compilation issue and every single answer online is “oh, just use rustup to get the latest version”, I cringe.
Posted Jul 22, 2022 14:29 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
> But the backwards compatibility story is not among them.
The backwards compat is far better than C++ IME. Rust isn't going to stomp on my variable names while C++ instead tries to avoid it, but can still trip up code (e.g., some poor sod that named his struct fields `co_X`). The ecosystem has issues, but so does any ecosystem.
FWIW, there is `-Z minimal-versions` dependency resolution. Getting people to care is difficult, but so is getting people to care that you're still using GCC 4.8 today.
Posted Jul 26, 2022 22:39 UTC (Tue)
by Jandar (subscriber, #85683)
[Link]
And the <=> operator is used instead of < in the STL. I had a very subtle error while using a set of pair<> (*). The result was searching a multi MLOC codebase and writing many new <=> operators to be sure to avoid this problem.
The new automatically derived <=> was an unexpected major pain during transition to -std=c++20.
(*) This concrete problem was facilitated thru the indirection of the comparison operator by pair<>. Why the pair<> was needed to trigger the problem I don't fully understand, the convoluted implementation of the g++ STL has left me addleheaded ;-)
Posted Jul 23, 2022 3:17 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
It's possible you lost count of the digits? It's about 3.5M lines.
You're probably correct that there aren't 10k+ developer organisations using exclusively or even primarily Rust. I'm not sure what a 10k+ developer organisation does, except flail around ineffectually, but I doubt Rust fixes that.
Posted Jul 22, 2022 17:06 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (3 responses)
I've never found this to be true. I've worked on multiple large projects that were started back in the 2000's, so were using C++03 (or earlier!), and have since updated to using C++11, C++14, C++17, and even C++20, and no such "multi-year upgrade program" was needed. In fact, much of the code that was used back in C++03 has not been touched at all. Yes, some of it is using old constructs that we would not use if that code were written today because there are better options in newer versions of C++, but it still works so we leave it alone.
Upgrading to a newer C++ compiler may take a few days' effort to see if there are issues, then you deploy it and over time you adjust the code to use newer features (or you don't bother, since in virtually all cases the old code still works).
I personally prefer the C/C++ trinary operator and think the syntax used by Rust and Python for this is gross to read. If you want a better (IMO) example of ugliness introduced due to backward-compatibility requirements in C++, consider "override" and "final": these cannot be added as full keywords so you have "virtual" as a prefix and "override" and "final" as postfix on methods which is yucky.
Posted Jul 22, 2022 17:25 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
That's certainly down to taste. I think the ?: is nice and terse, but it does have some awfully annoying precedence rules when nesting it last I remember. The other issue is the stuttering of `foo ? foo : some_default;` that I heard was proposed as `foo ?: some_default` at one point, but never got anywhere apparently.
However, usually I see Rust using if expressions for longer blocks of code where `?:` doesn't work anyways. Most types one would use `if` with have methods to do what is needed (like `Option::or_else` and the like).
Posted Jul 22, 2022 22:22 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
It works just fine and worked for years. I'm just not sure if anyone ever proposed to make it formal part of the C++ standard.
Posted Jul 22, 2022 23:44 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
Living with the Rust trademark
> The other issue is the stuttering of `foo ? foo : some_default;` that I heard was proposed as `foo ?: some_default` at one point, but never got anywhere apparently.
Living with the Rust trademark
Living with the Rust trademark