Hi,
I plan to invest a large amount of time and energy in Rust in 2019, but I first need to be reassured about one thing:
Will Rust stabilize in 2019 ?
I mean there is already a large amount of features in the language and the mentality seems to add even more every 6 weeks.
At a first glance it seems appealing, but it also seems a very good way to fragment the projects using it and limit open source contributions and collaboration.
Here is an example:
Coming in Rust in 2019 I need to understand the edition thing (which IMHO is a very good way to fragment the projects and thus collaboration),
I need to understand that the code I'm reading which was written 4 months ago may not embeds the latest Rust features so there is a better/cleaner way to achieve the thing today,
I need to understand that in 6 or 12 weeks a new feature will be released in stable and thus the pattern I'm struggling to implement will be deprecated,
I need to understand that some talented peoples works on projects targeting nightly only and thus we are not able to collaborate / take advantage of their work in a stable project.
I'm may miss other things that result in a fragmented community / pool of projects, but is there any plan to stop this ?
I'm a little bit afraid to invest my time in a language which will become a monstrosity of stacked features in 2 years.
Rust is stable. Code you wrote (almost) 4 years ago still compiles today without changes. This won't change. Even for functionality that has since been deprecated, there are no plans to actually remove that.
As for new functionality, all technology changes. It's pretty much a basic requirement of using technology that you keep your self up to date with the latest developments.
As already said, rust is stable and will always be (afaik ).
Of course there will be new things, but that doesn't mean that the "old way" will be bad. You don't have to use editions, you can still use Rust 2015 and program for that edition.
I'm very sorry, but I really don't get your point. Do you want the development to stall and only reale updates every 3 years? That would certainly hurt Rust, because this is one of the things I like atm.
Take for example the issue of editions. You can use code from another edition. That means that if you don't want to switch to Rust 2018, you don't have to and can still use 2018 libraries.
I'm sorry if I wasn't clear enough but I'm mostly afraid to have in 2 years an over complex language with too much features.
As I plan to use Rust professionally (for full time open source projects) I need some stability to focus on the business logic and not to worry much about language changes (and thus spend most of my time re engineering libraries instead of shipping new features to users).
I think one of the reason which explains the Go success is the stability, thus community can build on stable foundations and libraries progress to a 1.0 version faster. Go hadn't a major change in ~10 years.
For example, as an enterprise I choose rust to power my new backend or IoT project.
Is there guarantees that in 5 years my collaborators will be able to understand the code released today ?
I wrote the initial version of xsv before Rust hit 1.0 almost 4 years ago. After Rust hit 1.0, xsv hasn't seen any major re-architectures or changes and has continued to "just work" on every release of Rust since.
If you're really worried about over-bloating the language, keep in mind that the language is already nicely split between "other libraries" and the "standard library" and so over-bloating it is rather difficult because stdlib is meant to contain the very standard things, and other crates contain code for other things. Take regex for example as this was one I saw recently, it isn't implemented in stdlib, but is instead its own separate library.
IMHO THAT is the problem with the rust ecosystem (not the language).
To have something working you have to rely on a lot of small 0.x crates (maybe not regex, but the majority are not close to 1.0).
As an enterprise user I need aome guarantees about security / reliability of packages I rely on which is often not provided by small external packages.
I think I have my responses about libraries stability, thank you, but now what about features stacking up ?
How can I be sure that in 5 years Rust will not be a too complex / ambiguous language which is hard to reason about like c++, and thus friendly to business logic errors, because of the complexity of the grammar / syntax ?
Is there a tracker about what is actually removed from the language to make it less ambiguous / complex ?
The last point being ecosystem fragmentation, is there any initiative to move some external crate in the stdlib like HTTP stack to avoid having each framework using it's own types ?
No. But there is an initiative to centralize types common to HTTP related crates here: http - Rust
If you're going to use Rust productively, you'll have to find a way to get on board with how its ecosystem is structured, or otherwise write what you need in house. The standard library is not going to suddenly flip its script and start bundling a bunch of stuff. Maybe the future might include something like a Rust distribution with a set of blessed crates, but there are no plans for that currently, and the last time it was seriously proposed, the community rejected it pretty strenuously.
Rust is one of the most friendly languages there is. Unfortunately the term is too vague to mean the same to everyone. Rust is great at producing errors at compile time, down to use of static analysis. Unfortunately many see this as slow progress but in reality it leads to bug free code in shorter time.
Release notes (and blogs best overall place for what is being added.) You have to specify what "ambiguous / complex" your referring to otherwise will never get anything constructive back.
The standard library is staying minimal. For small items there generally is the single purpose crate. It is not necessary a bad thing to have alternatives for larger libraries (eg gui.)
You want two things fundamentally incompatible: code should work indefinitely and unnecessary functionality should be removed over time. Rust chooses the former.
I have code more recent than that that doesn't compile on recent compilers. Rust is stable to a point, but it has broken backward compatibility on multiple occasions in the past. Specifically, if something is unsound, or impairs the language's ability to evolve further, it will probably get broken. I am personally familiar with this.
For (at a guess) 99% of code, Rust is stable, but I really wish people would stop insisting Rust doesn't break back compat. All it does is set unreasonable expectations that will infuriate people writing that 1%.
I realise you're mostly asking about language additions, but I wanted to address the backward compatibility aspect of this.
In practice, and in my experience, the stability problems mostly come from the ecosystem. Some authors take a... debatably liberal interpretation of semantic versioning. As a result, the more you "ride the wave" of compiler and library updates, the less problems you're likely to see. If you want to minimise churn, then be prepared for problems.
As an example, I have a project where I can't update my dependencies because someone in the tangled mess has broken semver, and when I update to "compatible" versions, the project no longer builds. Wheeee.
Compared to other environments, Rust is pretty good about this. Between rustup and lock files, you can fairly effectively isolate a project from outside changes, which at least lets you control when disruption happens.
Just take the claims that everything is rainbows and puppies with a decent amount of salt.
Oh, man, the introduction of ? was less than enjoyable. Overnight, I had multiple dependencies stop building on the version of the compiler I supported.
I don't think this is unique to Rust, but I have noticed a tendency toward magpie-ing new features.
Just to reiterate what's been said before: crates written for one edition can use and be used by code written for different editions. Newer editions can remove/simplify features. As a result, Rust has an (in my experience) unique way of culling itself over time without putting itself in a "Python 3" situation.
Now, if we could just add the language version to the manifest, it'd be even better... but on the whole, I'm fairly positive about this aspect.
Given the changes between the 2015 and 2018 editions... I would say that about 95-98%% of the code should mean the same thing over that time span. Idioms will likely change more significantly... maybe 10-20% of the 5 year-old code would be written differently if written again from scratch. e.g. pattern ergonomics, the dyn keyword, the '_ lifetime, ?.
But we can't be certain of that until, say, some time in 2020.
Overall, I think things could definitely be better, but I don't believe the situation is anywhere near as dire as you seem to fear.
Everyone here is very aware of what C++ has become, so this fate is considered and actively avoided.
The current state of fragmentation is:
try!() macro has been adopted as ? syntax. Some projects still use try!(), but both syntaxes work. There's no need to change, but if you want, it can be converted automatically.
Box<Trait> has got clearer syntax as Box<dyn Trait>. Some code still uses the less obvious syntax. Both work. There's no need to change, but you can with cargo fix --edition-idioms.
The experimental futures crate 0.1 will become obsolete when Future type is added to stdlib. There's a plan to make adapter for backwards compatibility. There will be some annoying churn as projects switch, but the big upside is that it will work with the async/await syntax that is soooo much easier to work with than the raw futures crate.
trim_left_matches was renamed to trim_start_matches. The old method still works, but shows a warning. You can silence the warning or use cargo fix to rename.
modules changed, with addition of crate:: to paths. Modules were super confusing to new users and paths seemed to be inconsistent. Old code still works, but can be auto-converted with cargo fix --edition.
There were other changes, like making ref de-facto optional and dropping of useless Error::description(), but these changes essentially removed things from the language.
The additions on the horizon are:
async/await that are relatively big, but also very desirable for networking code. Currently when you use async code you have to fight with the borrow checker a lot, since use of references and local variables is limited. This change will allow networking code to look more like in Go or JS.
const generics. Currently any generic types depending on numbers (like array length or dimensions of a matrix) are either impossible, overcomplicated or buggy. So that's more a language-level bug fix than a new feature.
And that's all I can think of for 2015-2019. We'll see how the switch to new futures will work out, but for other features it comes down to running a tool once a year, and even that is optional. You can do nothing if you don't care about newer features.
Our semver policy is explicitly defined in RFC 1122. Call it what you will, but we have explicitly said that soundness fixes, inference breakage, and some other bugs are things we are allowed to do.
On Rust 2018 you'll need to write r#try!(..). The try! macro is totally deprecated.
If you can call introducing const A: B a bug fix then I can claim that any new language change is a bugfix. I don't think it's tenable to call const generics a bug fix.
I don't think Daniel was trying to imply otherwise - it's still worth stating that API-breaking soundness issues are still breaking code today, regardless what the reason is.
).