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.
I liked the talks hated the pain would like more lectures in Chinese. Could cut years off some of the development time for projects.
First post, using a browser compiled by Rust
Coincidence? I think not.
Well it was nice knowing that you once existed.
Think I'll stick with Go.
Not true. will not be uploading any java anytime soon
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.
I am quite sure we had to translate more sophisticated code into rust. So sorry!
That's called "oxidation".
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.
Glad to see this release is stable and wonâ(TM)t change until the release
Swift is just like Java just with more flourish
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".
Mmm, I'd say Swift is exactly like Kotlin but different.
The most important principles to grow your body and mind
“Principles are fundamental truths that serve as the foundations for behavior that gets you what you want out of life,” writes investor Ray Dalio in his bestselling book, Principles. Dalio focuses on skills like decision-making, investing, and managing organizations. While reading through it, I became inspired to put together my own list of principles that I’ve devised after more than five years of interviewing and coaching elite performers in sports, business, and beyond. Like Dalio’s, these principles are a foundation for a better you.
1. Stress + Rest = Growth
Whether you want to grow your body or mind or get better at a specific skill, you need to push to the outer limits of your current ability, and then follow that hard work with appropriate recovery and reflection. Decades of research in exercise science show that this is how you get stronger and faster, and the latest cognitive science shows that this is also how you get smarter and more creative.
2. Focus on the Process, Not Results
The best athletes and entrepreneurs aren’t focused on being the best; they’re focused on constant self-improvement. When you stop stressing about external outcomes—like whether you win or lose, attain a certain promotion, or achieve some other form of validation—a huge burden is lifted off your shoulders and you can focus your energy on the things you can control. As a result, you almost always end up performing better. Research shows that concentrating on the process is best for both performance and mental health.
3. Stay Humble
Humility is the key to growth. If you don’t maintain an open mind, you’ll severely limit your opportunities to learn and make progress. The best athletes trust their training programs but are also constantly looking for new ways to improve. Same goes for the best thinkers and creatives; they tend to be confident but not arrogant, and they check their egos at the door. Knowledge is always evolving and advancing—if you want to evolve and advance with it, you need to keep an open mind.
4. Build Your Tribe
There’s an old saying that you’re the average of the five people you spend the most time with. Turns out that’s true. A large and growing body of behavioral science research shows that motivation (or lack thereof) is contagious. One study, “Is Poor Fitness Contagious?Evidence from Randomly Assigned Friends,” found that up to 70 percent of your fitness level may be explained by the people you train with. Other research shows that if you work on mental tasks with people who are internally driven and love what they do, you’re more likely to end up the same way. If, on the other hand, you surround yourself with people who have a negative attitude and are focused solely on winning the rat race, you set yourself up for a less fulfilling experience.
5. Take Small, Consistent Steps to Achieve Big Gains
Habits build upon themselves. If you want to make any kind of significant change, you’d be wise to do so gradually and over time. In Stanford researcher BJ Fogg’s behavior model, whether someone takes action depends on both their motivation and their ability to complete a given task. If you regularly overshoot on the ability side of the equation, you’re liable to become discouraged and quickly flame out. But if you incrementally increase the challenge, what was hard last week will seem easier today. Put differently: Small and consistent victories compound over time, leading to massive gains.
6. Be a Minimalist to Be a Maximalist
You can’t be great at everything. Regularly reflect on what matters most to you and focus your efforts there. In the words of Mayo Clinic researcher and human performance expert Michael Joyner: “You’ve got to be a minimalist to be a maximalist; if you want to be really good at, master, and thoroughly enjoy one thing, you’ve got to say no t
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.
Yes, we are all aware of the differences between C/C++/Obj-C...
> 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.
THERE WILL BE CONSEQUENCES FOR YOUR LIES NAZI FAGGOT KEN DOLL JUST ASK TRUMP WHEN YOU SEE HIM FAGGOT
Filter error: Don't use so many caps. It's like YELLING. Filter error: Filter error: Don't use so many caps. It's like YELLING.
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!
Not even close.
Idiot. They are close. GP said "mostly a superset of" — not an exact superset of.
C++ is indeed very close to a superset of C. You are stupid and ignorant for claiming otherwise.
there's no simplified cast in C++, it's a tangled web of nutty cast
operators to perform a straightforward task.
You do know why that is, right? They want you to be explicit when shooting yourself to the foot.
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.