[rewmie]

That's perhaps the most pressing problem of Rust: not providing a concrete specification that can be targeted by projects and implementations.

[CoastalCoder]

I get the impression that Rust revisions are (at least intended to be?) backwards compatible: [0]

Are there are good workarounds when breaking changes to occur? No idea if/how well breaking language changes can be isolated to stay within individual crates.

[0] https://subscription.packtpub.com/book/programming/978178934...

[rewmie]

> I get the impression that Rust revisions are (at least intended to be?) backwards compatible

I don't think that matters at all. If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.

[CoastalCoder]

> If I try to build a new project with an older version of Rust, the compiler will still throw errors when stumbling upon newer features.

Usually when people worry about language evolution, the concern is that a newer compiler can't handle older code.

[estebank]

Is there any language toolchain that isn't absolutely static capable of having not only backwards compatibility but also forwards compatibility? If I try to open an MS Office XP file in MS Office 97, it will fail. If I try to run a new linux application that uses a new syscall in an older kernel, it will fail. If I try to use structural pattern matching in Python 3.9, it will fail. How is Rust any different?

If the concern is that projects are using "too new a rustc version", then your beef is with those projects, but be advised that demanding open source projects not use newer versions of their toolchains can be a big ask that increases their workloads and they might not be amenable to cater to your usecase.

Finally, because every Rust version is backwards compatibility, there's no reason for builders and developers to not use the latest stable release as quickly as feasible, all existing projects will continue compiling.

[umanwizard]

That's indeed a problem, but I don't think it's the most pressing one, since it's common to the majority of widely-used languages.

[rewmie]

> since it's common to the majority of widely-used languages.

I don't think so.

Both C and C++ are specified in international standards. That's the gold standard.

Java has very concrete versioning and specification process.

Python is also exemplary in its release and versioning process.

C# even breaks down versioning in terms of both CLR and fundamental frameworks.

Exactly which widely used language do you think is missing from that list?

[dureuill]

The person you're responding to was specifically responding to your criticism that Rust does not provide a specification that implementations can target.

You're now listing languages, such as Python, that don't have a specification, so it is unclear what your criticism actually is.

By python's standards, Rust is very good: a lot fewer breaking changes (changes are tested against the entire, huge, open source ecosystem to check if they are breaking, I think this level of testing is unparalleled), the release and versioning process is extremely clear (one minor release every six weeks, patch releases to address unexpected regressions + security issues), and it also have a really well specified evolution process through the RFC process.