5 ms·

I believe 100% of Rust code written since 1.0 should still work today.

steveklabnik 6y ago
We have fixed some soundness holes that means some broken code accepted by older compilers will not compile today. There also have been some type inference changes that technically could break some code. While we are allowed to break things in this way, we want it to feel as if it were literally 100%, so we often will do things like “warn instead of fail to compile for a very long time” before making changes, or “discover that an inference change breaks the ecosystem too much so back it out until it won’t anymore.”
- glandium 6y ago
  There's also a category of breakages that happen when libstd adds methods to types or traits. You get a unstable-name-collision warning for a while and then your code breaks. I'm not looking forward for code using Itertools::intersperse to break.
Waterluvian 6y ago
I think this is true for Javascript and as a result old code still runs. I think that's great. But there's also an absolute minefield of bad features that don't get deprecated. Not that that's not addressable with tooling or feature limiting version flags.
- smt88 6y ago
  You are mistaken. Dozens[1] of JavaScript features and APIs are deprecated (they will be removed) or obsolete (they have already been removed). 1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - Waterluvian 6y ago
    Interesting thanks. I knew there were deprecated features you're discouraged from using but I wasn't aware of the ones that were removed. So if ECMA (or whoever now?) is okay with theoretically breaking some websites maybe thru should clean up more things like "with" and double equals.
    - aidenn0 6y ago
      See my sibling comment, but I'd really like a replacement for "with" before it goes away completely.
- gameswithgo 6y ago
  Rust will deprecate bad features with their edition system, but the compiler will still support the old editions.
- aidenn0 6y ago
  Having worked on something that emits JS, I appreciate this. We finally got around to making things work with strict a few years ago, and still run into bugs because losing "with" was so painful -- we used it to introduce a new scope without changing the scope that "return" will return from; javascript could really use a named return construct. We can fake it with exceptions but it makes the generated code very hard to read.
- reificator 6y ago
  I'd bet that 90% of Javascript code probably still runs today, but that's only because I think that so much JS has been written in recent years compared to the early years. If you take the average codebase from, let's say 2006, I would honestly put down money that under 25% would still run to this day. While most churn that people complain about on the frontend now is "optional" churn, the first two decades were full of breakage. Not only are there wide swaths of APIs that have been rightly removed, there are even keywords that have been deprecated and aren't available in strict mode.

We have fixed some soundness holes that means some broken code accepted by older compilers will not compile today. There also have been some type inference changes that technically could break some code. While we are allowed to break things in this way, we want it to feel as if it were literally 100%, so we often will do things like “warn instead of fail to compile for a very long time” before making changes, or “discover that an inference change breaks the ecosystem too much so back it out until it won’t anymore.”

glandium 6y ago
There's also a category of breakages that happen when libstd adds methods to types or traits. You get a unstable-name-collision warning for a while and then your code breaks. I'm not looking forward for code using Itertools::intersperse to break.

Waterluvian 6y ago

I think this is true for Javascript and as a result old code still runs. I think that's great. But there's also an absolute minefield of bad features that don't get deprecated. Not that that's not addressable with tooling or feature limiting version flags.

smt88 6y ago
You are mistaken. Dozens[1] of JavaScript features and APIs are deprecated (they will be removed) or obsolete (they have already been removed). 1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Waterluvian 6y ago
  Interesting thanks. I knew there were deprecated features you're discouraged from using but I wasn't aware of the ones that were removed. So if ECMA (or whoever now?) is okay with theoretically breaking some websites maybe thru should clean up more things like "with" and double equals.
  - aidenn0 6y ago
    See my sibling comment, but I'd really like a replacement for "with" before it goes away completely.
gameswithgo 6y ago
Rust will deprecate bad features with their edition system, but the compiler will still support the old editions.
aidenn0 6y ago
Having worked on something that emits JS, I appreciate this. We finally got around to making things work with strict a few years ago, and still run into bugs because losing "with" was so painful -- we used it to introduce a new scope without changing the scope that "return" will return from; javascript could really use a named return construct. We can fake it with exceptions but it makes the generated code very hard to read.
reificator 6y ago
I'd bet that 90% of Javascript code probably still runs today, but that's only because I think that so much JS has been written in recent years compared to the early years. If you take the average codebase from, let's say 2006, I would honestly put down money that under 25% would still run to this day. While most churn that people complain about on the frontend now is "optional" churn, the first two decades were full of breakage. Not only are there wide swaths of APIs that have been rightly removed, there are even keywords that have been deprecated and aren't available in strict mode.