Slashdot Mirror
Rust 1.31 Released As 'Rust 2018' In Major Push For Backwards Compatibility (rust-lang.org)
"The Rust programming language team has announced the first major edition of Rust since 1.0 was released in 2015," reports SD Times -- specifically, Rust 1.31, the first edition of "Rust 2018," described by Rust's developers as "the culmination of feature stabilization."
An anonymous reader writes: The Rust team is working hard to maintain backwards compatibility, for example with the way they're handling the ongoing addition of an async/await feature. "Even though the feature hasn't landed yet, the keywords are now reserved," notes the Rust Team. "All of the breaking changes needed for the next three years of development (like adding new keywords) are being made in one go, in Rust 1.31." The keyword "try" has now also been reserved, but "Almost all of the new features are 100% compatible with Rust as it is. They don't require any breaking changes... New versions of the compiler will continue to support "Rust 2015 mode", which is what you get by default... [Y]ou could think of Rust 2018 as the specifier in Cargo.toml that you use to enable the handful of features that require breaking changes."
The Rust language's blog adds, "Your 2018 project can use 2015 dependencies, and a 2015 project can use 2018 dependencies. This ensures that we don't split the ecosystem, and all of these new things are opt-in, preserving compatibility for existing code. Furthermore, when you do choose to migrate Rust 2015 code to Rust 2018, the changes can be made automatically, via cargo fix." Tooling improvements include faster and smarter "incremental" compilation (along with better IDE support), plus the addition of function-like and attribute-like (procedural) macros. There's also a rustfmt tool which can automatically reformat your code's style "like clang format does for C++ and Prettier does for JavaScript," plus an optional diagnostics linter named clippy, and automated code fixes via rustfix. There's even upgrades to Rust's module system and other path clarity improvements.
But this is only the beginning, SD Times reports: With the release of Rust 2018, the team is now starting to look at Rust's future. The team is asking developers to reflect on what they liked, didn't like or hoped to see in Rust during the last year, and propose any goals or directions for the upcoming year.
An anonymous reader writes: The Rust team is working hard to maintain backwards compatibility, for example with the way they're handling the ongoing addition of an async/await feature. "Even though the feature hasn't landed yet, the keywords are now reserved," notes the Rust Team. "All of the breaking changes needed for the next three years of development (like adding new keywords) are being made in one go, in Rust 1.31." The keyword "try" has now also been reserved, but "Almost all of the new features are 100% compatible with Rust as it is. They don't require any breaking changes... New versions of the compiler will continue to support "Rust 2015 mode", which is what you get by default... [Y]ou could think of Rust 2018 as the specifier in Cargo.toml that you use to enable the handful of features that require breaking changes."
The Rust language's blog adds, "Your 2018 project can use 2015 dependencies, and a 2015 project can use 2018 dependencies. This ensures that we don't split the ecosystem, and all of these new things are opt-in, preserving compatibility for existing code. Furthermore, when you do choose to migrate Rust 2015 code to Rust 2018, the changes can be made automatically, via cargo fix." Tooling improvements include faster and smarter "incremental" compilation (along with better IDE support), plus the addition of function-like and attribute-like (procedural) macros. There's also a rustfmt tool which can automatically reformat your code's style "like clang format does for C++ and Prettier does for JavaScript," plus an optional diagnostics linter named clippy, and automated code fixes via rustfix. There's even upgrades to Rust's module system and other path clarity improvements.
But this is only the beginning, SD Times reports: With the release of Rust 2018, the team is now starting to look at Rust's future. The team is asking developers to reflect on what they liked, didn't like or hoped to see in Rust during the last year, and propose any goals or directions for the upcoming year.
Seems like every language is making backwards incomparable changes. I guess after Python 3, everyone thinks backwards incompatible changes are ok, even though Perl6 was DOA. Every version of Swift is backwards incompatible, Tensorflow 2 totally incompatible with 1.x, and these days even Java is doing it with backwards incompatible changes involving JavaFX and some other libraries. I want to like Swift, but having all your code break every 12 months is getting old. You won't be replacing C/C++ if you break everyone's code every 18 months.
Rust is just another ruby. It will die out in a couple years for the next programming language fad.
I hope it is better than the cluster that is async/await in Python. I am not sure how you have a new language in 2018 though that doesn't have concurrency built in. It is understandable for Python, but not Rust.
There are a few aspects of Rust that I like, but there are more things that I dislike about it, and I'm afraid async/await is another thing I would probably dislike. I looked over some of the reasoning behind it, and I'm frankly not finding particularly solid reasons for it. OTOH, Go's several different ways of handling concurrency are much easier to grok and "get stuff done".
Sounds like a tune from Judas Priest, the heavy metal gods of folk.
Seems like every language is making backwards incomparable changes.
[snip]
You won't be replacing C/C++ if you break everyone's code every 18 months.
C and C++ are different languages. While C++ is mostly a superset of C99, and there was some cross-pollination of features between them since, there are enough idiomatic differences between them to make "C/C++" meaningless, unless you refer to "writing C style code while using some C++ features" (a.k.a "C with classes"), which, IMHO, is not a good choice of programming style in most cases.
Regardless, both C an C++ try to be backward compatible in their corresponding revisions, and most breaking changes fall into the category of "you shouldn't have been doing it anyway".
And no, this is not intended to be a discussion on the merits (or lack thereof) of those languages, though I suspect it will devolve to it.
> It's easier to hack stuff out in Go because when it comes to threading it doesn't do much to stop you shooting yourself in the foot. ...
> The reason it looks harder in Rust is because writing correct multithreaded code is in fact hard. Annoyingly so.
Well put. I'm not a Rust fan, not even know much about it other than that Rust fans have done some over-the-top hype about features most other languages have too. I'm dealing with a codebase that has a lot of concurrency problems though. The languages make it easy to do concurrency. You don't have to understand concurrency issues to write multithreaded code in these languages. You can easily spin off threads that cause all kinds of subtle bugs that pop up rarely - infrequently enough that you're unlikely to catch them in tests, but often enough to cause problems for customers or even lock up the entire occasionally.
Concurrency and multithreading IS hard to do right. Languages that make multithreading easy only make it easy to create very complex bugs.
"Could cut years off some of the development time for projects."
I understand Rust is excellent software, but why give it a name that sounds degrading. "Rust" is something you don't want to happen.
Other foolish names:
"Lisp" is a speech impediment.
"Gimp" is a person who limps or is lame.
Why restrict technology names to only 1 alphabet? LaTeX uses Greek letters, also, and requires two paragraphs in the Wikipedia article to explain the name.
Or... Go with the flow? The next time you create open-source software, call it "Garbage"? Or "Feces"? Or maybe "Vomit"? Or, invent a new word. Maybe "Flonorba-gorba"?
Not even close. The const operator is the biggest difference
between the two languages. C++ is not an improved C language.
Arrays and compound literals are handled differently; some integer
math is different; variable promotion is not intuitive nor intrinsic;
there's no simplified cast in C++, it's a tangled web of nutty cast
operators to perform a straightforward task. That's the short list, too.
Also, I have 20-year old C code that compiles and runs today. I
have 20-year old C++ code that crashes and burns under modern
compilers (when it ran fine in it's day, like molasses, but ran).
CAP === 'tapestry'
You can easily spin off threads that cause all kinds of subtle bugs that pop up rarely - infrequently enough that you're unlikely to catch them in tests, but often enough to cause problems for customers or even lock up the entire occasionally.
I think a good rule of thumv is that if you see some sort of general purpose class (i.e. not something like a message queue) with a mutex or atomic in it, you've seen a bug even if you don't know where it is yet.
SJW n. One who posts facts.
Wow! Thanks for the links. From SATAN to SAINT. They seem to have learned something.
"Well, except for my urologist - Dr Waters."
Ha!
There is a woman who is a manager in city government here whose last name is "Lust".
Remember what people said about Microsoft? It was small and soft.
I'm about 6 months in to seriously using Rust and I absolutely love it! The ecosystem is fantastic (cargo and crates.io), the zero-cost, high-level abstractions are great, and the borrow checker is amazing!
Learning curve is quite steep, yes, due to unusual concepts (mainly borrow checker and move semantics). Once you get past struggling with that everything clicks in it's place and coding becomes fun again, way more so than in C/C++.
My bullet points why I like it so much:
Swift has said that at this point they plan not to introduce source breaking changes again (I think there may be one more they were strongly considering).
As someone who has been using Swift professional since the start, I really do not care though. Partly that is because of migration tools helping, but in large part it's because I'll probably be using Swift for 10 more years at least, so I'd WAY rather have the language be better to work in for a decade or longer, then complain just because I had to spend a few days making what were mostly bulk changes to code.
Even the worst of the conversions (Swift 2 to 3) was no more than a handful of days, and that was only a painful conversion because it required a tiny bit of thought.
I fully support the idea that languages, especially now ones, should be able to alter course until after some time it's apparent what syntax gels best with the language and developers using it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Noobs never understand backwards compatibility: a product's user base will abandon it if it abandons backwards compatibility. Get a reputation for not maintaining backwards compatibility, and the product won't gain significant new users. And every non-backwards compatible change will drive away more and more users.
Nobody with a real job wants to have to redo their work just because you have the attention span and planning ability of a baby squirrel who stole a pot of espresso.
Not even close. The const operator is the biggest difference
between the two languages. C++ is not an improved C language.
Arrays and compound literals are handled differently; some integer
math is different; variable promotion is not intuitive nor intrinsic;
there's no simplified cast in C++, it's a tangled web of nutty cast
operators to perform a straightforward task. That's the short list, too.
Also, I have 20-year old C code that compiles and runs today. I
have 20-year old C++ code that crashes and burns under modern
compilers (when it ran fine in it's day, like molasses, but ran).
1. Ugh, typo! I meant C89, not C99. My bad. That said, I do not claim that C++ is a strict superset of C89, only "mostly", but I don't see it as a problem because they are different languages. C programs should be compiled with C compilers.
2. C++ has always supported C-style casts.
3. Conformant C++98 code should work the same when compiled under compilers conforming to newer versions of the standard. Other than the obvious cases of adding keywords and deprecating auto_ptr, I would be interested to see code examples to the contrary. Please note that relying on undefined behaviour or nonstandard extensions does not count.
C and C++ are different languages. While C++ is mostly a superset of C99
Sorry, I meant to type C89. Thank you AC!
Did this game ever really take off? Why are people still talking about it?
When you add a thread, you add a bug.
"First they came for the slanderers and i said nothing."
When you add a thread, you add a bug.
No arguing there.
I've definitely seen code where the author clearly believed that sprinkling "atomic" around like magic pixie dust makes the code thread safe.
SJW n. One who posts facts.