Rust 1.31 Released As 'Rust 2018' In Major Push For Backwards Compatibility (rust-lang.org) 81
"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.
Can we have better names? (Score:4, Insightful)
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" [wikipedia.org] is a speech impediment [wikipedia.org].
"Gimp" [gimp.org] is a person who limps or is lame [dictionary.com].
Why restrict technology names to only 1 alphabet? LaTeX [wikipedia.org] 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"?
Re:Can we have better names? (Score:4, Funny)
"Gimp" [gimp.org] is a person who limps or is lame [dictionary.com].
Limps or lame? Is that really what springs to mind? Booooriiiiing. Personally I always think "Bring out the gimp!" whenever I need to edit a picture.
Re: (Score:3)
In my opinion, SATAN [wikipedia.org] was the best name ever.
Unfortunately, it has been superseded by SAINT [wikipedia.org].
Funny! (Score:2)
Re: (Score:2)
I never saw a problem with this. Whenever a word with a previous meaning is used as a name I automatically start associating it purely with the project/person/etc. instead of the word meaning, when used in that context. It's just automatic for me. Same for family names with a original meaning - the meaning fades away and the name is associated with the person.
Well, except for my urologist - Dr Waters.
Remember what people said about Micro-soft? (Score:2)
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.
Re: (Score:2)
What is with the death of backwards compatability? (Score:1)
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 e
Re: (Score:2)
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 fal
Re: (Score:1)
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
Re: (Score:2)
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
Re: (Score:2)
C and C++ are different languages. While C++ is mostly a superset of C99
Sorry, I meant to type C89. Thank you AC!
Not every version of Swift (Score:2)
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
Noobs never understand backwards compatibility (Score:1)
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.
Anyone remember Ruby (Score:1)
Rust is just another ruby. It will die out in a couple years for the next programming language fad.
async/await? (Score:2)
Re: (Score:2)
FWIW, I rather like Ruby. Too bad it's so slow. I'm not sure 3 times as fast is going to be fast enough...and so far that's just a promise.
Re: (Score:2)
Re: (Score:2)
If you're talking about web sites, you aren't talking about my area of interest or application.
Re: (Score:2)
Re: (Score:2)
It's a desktop application with a bit of graphics. It's not really heavy in computation...well, it off-loads the heavy computation to other routines...but it still isn't exactly light-weight.
Re: (Score:2)
Re: (Score:2)
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.
That didn't call it 'cluster' without a good reason.
Curious Decisions (Score:2)
Re:Curious Decisions (Score:5, Insightful)
OTOH, Go's several different ways of handling concurrency are much easier to grok and "get stuff done".
Well yes. But that's the problem. 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. Pretty much the entire reason for the existence of Rust was to enable the moz devs to write fine grained multithreaded code without creating a nest of subtle threading bugs.
The reason it looks harder in Rust is because writing correct multithreaded code is in fact hard. Annoyingly so.
Well said (and I don't like Rust). Concurrency is (Score:2)
> 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
Re:Well said (and I don't like Rust). Concurrency (Score:4, Interesting)
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.
Re: (Score:2)
Re:Well said (and I don't like Rust). Concurrency (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
I am enamored with Jai's approach of pulling everything into the the source - the code, build stuff, test etc. I tried the new rust command line tutorial and it created a directory with multiple files before I ever got to write a line of code. importing a library needed two files with different syntaxes. It took a long time to compile Hello World.
I want to like rust - It has great security properties - but it's so ugly.
Re: (Score:2)
I tried the new rust command line tutorial and it created a directory with multiple files before I ever got to write a line of code. importing a library needed two files with different syntaxes. It took a long time to compile Hello World.
I'm questioning your results. Here are the step to create and run Hello World:
cargo new hello
cd hello
cargo run
That's it. 11 seconds start-to-finish, including fixing a typing mistake.
Re: (Score:2)
I tried the new rust command line tutorial and it created a directory with multiple files before I ever got to write a line of code. importing a library needed two files with different syntaxes. It took a long time to compile Hello World.
I'm questioning your results. Here are the step to create and run Hello World:
cargo new hello
cd hello
cargo run
That's it. 11 seconds start-to-finish, including fixing a typing mistake.
Look in the directory. .toml file to declare a library dependency and edit the rust source file to do the import of the library.
Cargo created a directory with some files in it and two sub directories with files in them.
You cd into that directory and 'cargo run' it, which both builds and runs it. The build takes a long time (compared say to gcc, which completes pretty much instantly).
To follow the command line tutorial I can had to edit a
Quite a lot for hello world.
Re: (Score:2)
I did wonder how the file structure malarky scaled with project size. Most of my programming these days is for command line tools that do data analysis or data transformation from test chip data, so I'm interested in efficiency of the programming process. I'm also old and intolerant of seeing the same old mistakes repeated. Dependency declaration files? No thanks. Python is great when performance and security isn't an issue.
The other part of my programming is for publicly released secure cryptographic softw
Re: (Score:2)
Files in rust and cargo are up to the developer. It has a notion of modules, and you can declare one or many in each file, or you can do file/directory structure reflects module structure. In practice, starting a new file when the old one gets to big seems a reasonable way to go.
In terms of dependency declaration files, this is not actually duplicated information. One is the package import (which is a namespacing thing) and also occurs within a single crate (Rust's name for a package). The other is higher l
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
11 seconds is very long for one line of active code.
Re: (Score:2)
Diamonds and Rust (Score:1)
Sounds like a tune from Judas Priest, the heavy metal gods of folk.
6 months (Score:3)
Why I love Rust (Score:4, Informative)
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:
Re: (Score:1)
No runtime and no dependencies for the target executable
This is because everything is statically linked. For example, last time I built the release build of the driver to load games onto a USB RAM cartridge for the Game Boy [github.com], it pulled in enough crates to total 6,787,656 bytes of executable code. How would this integrate with the UNIX philosophy's rule of composition [wikipedia.org], where a task consists of a half dozen or more different processes? Would all the processes have to be built into one executable that uses the executable's name to determine which sub-program to run?
Re: (Score:3)
Never played it... (Score:2)
Did this game ever really take off? Why are people still talking about it?