And we would have to track the development anyway because in 3 years when the big change came, we would want to be ready.
2 Likes
Emm, if you are a developer of any main stream language, no matter you are using C#, Java, Typescript, Javascript or whatever, you will have to do so as well. This industry is like the red queen's race, you have to keep running to stay.
3 Likes
This is what migration lints are for.
WG14 is very conservative (for good reason), and it is true that a lot of the work goes around polishing.
However, there is also a lot of active work in the committee around new features: lambdas/closures/nested functions, improvements to generics and type inference (typeof/auto/...), work on the memory model, #embed, N-bit integers, and even safety features.
Most of those (if not all) are inspired from extensions, C++ and other languages (including Rust!), of course, but they are major features nevertheless.
2 Likes
I see a lot of defensiveness in this thread. I actually read that article before I ever saw this thread, and my take is that there is some valid criticism even if some things aren't totally on point. And the valid criticism boils down to complexity, and the rate that complexity increases.
I don't think that at is current stage Rust is overly complex. But I do think that now is a good time to be shifting gears from features to polish.
However, I also think that the defensiveness is a symptom of another fairly common trait, and that is that many believe that Rust should be the only tool that developers reach for. There are things that Rust can learn from other languages (and definitely vice versa). I'm actually quite taken with Zig lately myself, and have been following with interest as Fortran tries to modernize and are even working on a package manage inspired in large part by cargo.
I'm not saying that I agree with the article on the development window. I think that Rust still needs to release often right now. But at some point a slowdown might be a good thing.
6 Likes
Well.., it's already at a slowdown at the moment with the next edition releasing, I doubt new proposals will be considered until the new year.
Things aren't really slowing down because of the edition. Maybe a tiny bit, but nothing noticeable. The 2021 edition will be far smaller than 2018's.
In terms of LOCs merged or in terms of new lang-feature proposals accepted?
What I want to see is that Rust programs/libraries written today can be compiled by whatever Rust looks like in 5, 10, 20... years time. Without change. Additionally that those programs/libraries can be extended by or used in the modern Rust at that time.
That would put Rust language stability on a par with C and C++.
I know we have ideas of versioning and editions in Rust. I'm just not sure if that ensures what I have outlined above will be possible far into the future.
This is a primary concern among those who are building systems that are intended to be operational and maintainable for a long time. I'm sure that is why C is so entrenched in embedded circles for example.
With that assurance in place I would not worry too much about Rust sprouting new features over time. Although I would hate to see it reach the insane levels of complexity of C++.
3 Likes
Just off the top of my head, I picked one of my more older crates that hasn't changed much in several years. Then I checked out the first release I published after Rust 1.0. I can still run the test suite:
$ git clone https://github.com/BurntSushi/suffix
$ cd suffix
$ git checkout 0.3.0
$ rustc --version
rustc 1.52.0-nightly (3a5d45f68 2021-03-09)
$ cargo t
[... snip ...]
test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.33s
[... snip ...]
There's a fair number of warnings, but everything works. 
The 0.3.0 release was tagged on 2015-06-19, so almost 6 years ago.
Regretably, this isn't true for everything I've done. The first releases of ripgrep, for example, no longer compile on current versions of Rust:
$ git clone https://github.com/BurntSushi/ripgrep
$ cd ripgrep
$ git checkout 0.1.2
$ cargo b
[... snip ...]
error[E0642]: patterns aren't allowed in functions without bodies
--> /home/andrew/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.19/src/serialize.rs:147:45
|
147 | ... &f_name: &str,
| ^^^^^^^ pattern not allowed in function without body
[... snip ...]
However, if I run cargo update -p rustc-serialize --precise 0.3.24, then cargo build works.
I tried another crate, csv, and its 0.14.3 release (2015-08-30, about 5.5 years ago) works, including its test suite. (Releases prior to this don't work because I was using foo = "*" dependency specifications.)
So I think there is some success here already.
18 Likes
The situation with C is not as cut and dried as one might think. In GNU land, Glibc deprecates macros and functions with releases quite often, which often means that while old binaries will be able to continue to link against thos symbols, you will no longer be able to compile against them. In a similar vein, when gcc10 came out -fno-common became a default flag, causing old code that brought in the same header in multiple files to stop compiling if 'extern' was not properly used throughout. Granted the latter can be worked around with a compiler flag, but in a nutshell not all old C code compiles with the newest compilers/libc combinations without some changes, either to the code or compiler invocation.
However I agree with the sentiment, and see it as a worthwhile goal for Rust.
2 Likes
Admittedly there can be problems.
I inclined to disregard problems caused by compiler specific language/library extensions . After all they are not the fault of the C language itself. Similarly for operating system quirks.
Then problems show up where things are "implementation defined" in C, or down right undefined.
However I have managed to compile some seriously old, pre ANSI, C with recent GCC. Which came as a surprise to me actually.
Cool. So far so good then.
Seems you are crossing the line between pre and post Rust 1.0 with your example. Particularly with the crate dependencies. I was not really considering compatibility with pre 1.0 Rust. Writing that off as "experimental". But you pulled through OK.
It doesn't. The only thing that can really ensure this kind of long-term stability is vigilance by the language designers (for any language). After lurking for a while on IRLO, I'm extremely optimistic that Rust will achieve this: Backwards compatibility is consistently the first concern brought up when someone proposes a new feature. Compatibility with potential future features is similarly discussed with some regularity, to avoid designs that will cause problems later.
1 Like
I guess you are right. Not breaking things has to be a primary value of the developers else all is lost.
I had not really thought about breaking things to come in the future. That sounds like a tough challenge, even if one has some notion of what features one would like in the future.
Like trying not to paint oneself into a corner when one does not know where the doors to the room are.
2 Likes
Just a small clarification: I chose releases that came out right around Rust 1.0. They may have technically come out before Rust 1.0 itself, but there was a beta period at the time and that's what those releases targeted.
The real pre-Rust 1.0 code went through serious churn. The commit logs from late 2014 (I think) to early 2015 would be fun to scrutinize.
2 Likes
The teams do occasionally decide that "the breakage is small enough" and accept SemVer breaking changes, and I think these should be highlighted more. In addition to release notes, in fact, I would like to see some well maintained official documentation on breaking changes specifically, a central resource people can go to when they do hit a backwards compatibility speed bump.
6 Likes
The latter. I've never checked LOC merged, because that's a largely useless metric.
1 Like
I'm not sure that I agree with these statements.
As a beginner I can say that the cycles do not impact the study materials, the only notable impact is between the language versions, such as Rust 2015 and 2018.
What was valid in Rust 2015 as information about module organizations using mod.rs for everything, and some syntaxes like using dyn without box were well outdated and may leave you lost in Rust 2018 but this is normal.