[thrown_22]

>What is the benefit of having multiple compilers for programming languages?

Rust will need a standard.

The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares.

People working on systems in the wild don't have the brain power to learn a new tool chain every decade, let alone every year. They are solving real problems and not writing blog posts.

[steveklabnik]

> code written 5 years ago will often not compile today.

citation needed. Yes, there's a few programs that relied on unsound things for which this is true, but that's a relatively small part of the overall amount of code.

[umanwizard]

Doesn’t every implementation of a new function on a standard type possibly break existing code?

For example if I have a trait Foo with a function bar, and I impl Foo for HashMap, and then a new version of std comes out that has named something HashMap::bar, now every call to my_map.bar() is ambiguous

[steveklabnik]

In that specific case, the inherent impl is preferred, so there’s no ambiguity. however this can still cause a breaking change if the inherent impl has a different type signature than the trait.

And yes, there are tons of things that can subtly break code. That’s why the rust project runs the entire open source ecosystems’ tests as part of the testing process for the compiler. It’s not all of the code in existence, but it’s pretty good at flushing out if something is going to cause disruption or not.

In practice, the experience that the vast majority of users report to us is that they do not experience breakage when upgrading the compiler.

[umanwizard]

> In that specific case, the inherent impl is preferred, so there’s no ambiguity.

That is even worse. It means your code can silently start doing the wrong thing rather than erroring, if the inherent impl does something different from the trait.

> And yes, there are tons of things that can subtly break code.

This isn't some obscure bug in some deep edge case though, it's a completely normal and common way of using the language (implementing your own traits on foreign types) predictably leading to breakage in an obvious way. I am not sure why it should be called "subtle".

Anyway, given this issue, I think the meme that Rust is backwards-compatible is really oversold. It'd be more honest to frame it as "we hope releases are backwards-compatible, but we like adding new functions to the stdlib, so no promises" rather than marketing BC as a major selling point as is done now.

> In practice, the experience that the vast majority of users report to us is that they do not experience breakage when upgrading the compiler.

It's anecdotal for sure, but I'm personally aware of times when the exact situation I'm describing has happened and caused headaches for people.

[thrown_22]

>but that's a relatively small part of the overall amount of code.

Yes and?

Systems programming isn't front end JS work where breaking things doesn't matter. It's no surprise that Rust came out of the browser space. Only people who don't take their work seriously could ever think the above is a justification and not a red flag for never using it.

I welcome Rust becoming ossified in GCC so I can build 30 year old code without modification like I can in C. Until then, it's a toy for people with more time than responsibility.

[rightbyte]

We are still arguing whether to bump the C standard from 89 to 99 where I work. I kinda like the pacing with C.

Or as Wikipedia puts it: "C17 addresses defects in C11 without introducing new language features."

[pjmlp]

Hopefully you won't have K&R C by the time you adopt C23 then.