7 ms·

> Due to our stability policy, description will never be removed, and so this is as far as we can go. What Rust _should_ do is gradually increase the noisiness

> Due to our stability policy, description will never be removed, and so this is as far as we can go. What Rust _should_ do is gradually increase the noisiness of warnings about using this. Eventually it'll disappear from the crate and end-user ecosystem (possibly with a small effort to tidy up abandoned crates). Java's "never remove a deprecated API" was definitely one of their big mistakes. Even a 10-year deprecation cycle is better than none.

baby 7y ago
look at the monster that C++ is now because of this as well. I think this is why people are turning to Golang, Rust, and Swift. But these languages could follow the same path.
- saagarjha 7y ago
  Those three languages also happen to have memory safety.
  - jhasse 7y ago
    And other features that differentiate them from C++. But I think that was the OP's point: People are switching to other languages mainly because C++ has become a monster, not because of missing memory safety.
    - jolux 7y ago
      I don't think that's the whole story. Golang is mostly picking up programmers from dynamic languages, according to Rob Pike, and Swift is gaining steam mostly because Objective-C while not monstrously complex like C++ is incredibly verbose.
      - pjmlp 7y ago
        Swift is gaining steam, because Apple dictates it, unless one enjoys using a frozen language. Likewese using C++ on Android requires perseverance given the how the NDK is handled and what it exposes, while on Windows it feels nice because it has parity with .NET tooling, specially on UWP.
        chiefsucker 7y ago
        Using a frozen language isn’t the real problem here, though. The Apple ecosystem slowly gains new frameworks like SwiftUI that simply don’t work with Objective C anymore. The platform is abandoning one language similar to Microsoft and their VB story. It will take a long time, but AppKit & UIKit will end similarly to how Carbon ended on macOS.
        jolux 7y ago
        Except SwiftUI is built on AppKit and UIKit as far as I know.
- favorited 7y ago
  Swift can't remove things from the standard library anymore either. Otherwise if the OS updated, and a symbol was missing, apps needing that symbol wouldn't launch.
- dodobirdlord 7y ago
  Rust has Editions, so deprecated features can slowly age out of the ecosystem. People using, say, the 2015 edition will probably eventually want features introduced in the 2018 edition, and they will have to remove their usage of features that were dropped in the 2015->2018 edition bump. And if they never want any new features, maybe because their library is totally complete? Well, crates using 2018... can still depend on them, they just can't use those features.
  - deleted 7y ago
    [deleted]
pjmlp 7y ago
Yeah, we all appreciate Python's success story. By the way, Java has removed deprecated stuff.
- airstrike 7y ago
  Nice straw man... I do want to point out how Django (which is obviously a Python framework, not the language), has a very solid deprecation policy
  - pjmlp 7y ago
    It is a lesson on how not to do breaking changes, when one wants the community to actually adopt new versions.
    - chc 7y ago
      I'm not so sure. Ruby did a very similar set of breaking changes around the same time and it went fine. It seems to me like the main difference wasn't in the changes — it was that the Rails developers enthusiastically embraced the changes, which pushed everyone else to do the same, while Python had more of a diffuse situation where some library authors went for it and others didn't and it led to everybody getting cold feet.
      - pas 7y ago
        Py3 was too big of a change. It took until about 3.3 to get some ability to really write cross-compatible code. And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode.
        airstrike 7y ago
        > It took until about 3.3 to get some ability to really write cross-compatible code. I disagree... you could always leverage six and/or do conditional imports based on sys.version > And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode. Usually after searching for answers for quite a while on Stack Overflow...
dpbriggs 7y ago
I wouldn't be surprised if they remove it in the next rust edition
- steveklabnik 7y ago
  As discussed below, we cannot make breaking changes to the standard library via the edition system.
  - kibwen 7y ago
    The function itself cannot be removed from the standard library (and likewise the symbol can never be reclaimed for a different use), but there's no reason that future editions couldn't report a compiler error when attempting to use the function. The function would only be inaccessible at the source level, not at the linking level, thereby completely preserving cross-edition compatibility while also mandating that crates remove references to it when migrating to a newer edition. Think of it like an edition-specific deprecation lint being turned from warn to deny.
    - steveklabnik 7y ago
      I think it's important to draw a distinction between what is true today, and what could be in the future. Today, the RFC text says: > More generally, breaking changes to the standard library are not possible. Could we amend this RFC to introduce a system like this? Sure. Have we? No.
Ericson2314 7y ago
What they should do is put as much of `std` on crates.io as possible (only a tiny bit is rustc-specific). Then in conjunction with https://github.com/rust-lang/wg-cargo-std-aware https://github.com/rust-lang/wg-cargo-std-aware uses can opt-in to to a `std-2.x`.
deleted 7y ago
[deleted]
j88439h84 7y ago
> Java's "never remove a deprecated API" was definitely one of their big mistakes. Even a 10-year deprecation cycle is better than none. Can you explain this position? Python just did a 10-year deprecation cycle on Python 2, but it was really costly for a lot of people. If they'd just not done that it would have been better; the benefits of removing stuff are relatively minor (cleaner language implementation codebase) and the costs are huge (all users need to change, test, handle compatibility, ...).
- pas 7y ago
  No, no, no. It was not a deprecation cycle. It was a complete stop using this because it's full of unclear semantics, here's the new thing cycle. Py3 should have simply started to warn when you used "bla" without u"..." or b"...", and so on. To clear up the bad code. Then later ... maybe 10 years later, make "..." equivalent to u"...". Maybe.
  - amluto 7y ago
    I don’t know what the right solution to the string problem should have been. Python 2’a string handling was bad, and programs used it inconsistently and nonsensically. IMO the real problem is the near complete lack of static checking that you fixed it with. Sure, modern Python + mypy can do a credible job finding wrong-string-type bugs, but legacy Python 2 codebases don’t have the right annotations. I do wish I could tell Python 3 to error out if I accidentally put a str and a bytes in the same dictionary as keys.
    - ttwwmm 7y ago
      The core problem with strings in Python 2 was implicit coercion: you could mix `b''` and `u''` strings pretty freely as long as they only contained ASCII and they would be silently converted as required. Once you leave the ASCII range you start to see data-dependent bugs. To gracefully deprecate this behavior, you could start by generating a warning each time an implicit coercion is done. Next, make implicit coercion raise an exception, but provide a way to suppress it. Finally, remove the ability to suppress the exception. As the GP suggests, you'd do well to similarly deprecate unprefixed strings. This would all be pretty confusing to explain if you were renaming the string types at the same time, as Python 3 did. I think that's an indication that you shouldn't rename the types. You could deprecate `str` and just use the names `bytes` and `unicode`, which go nicely with the `b''` and `u''` mnemonics anyway. Python 3 also changed the type of string used for Python identifiers. You'd need a strategy there as well. It might be convenient to have some type-checking `dict` variants in the stdlib, but I think it's a separate issue from addressing the coercion issue.
GlitchMr 7y ago
Java actually removes deprecated APIs now, and it's doing it really really quickly (IMHO way too fast). For example javax.activation, javax.activity, javax.rmi, javax.transaction, javax.xml.bind, javax.xml.ws, javax.jws, and javax.xml were deprecated in Java 9 (released September 2017) and removed in Java 11 (released September 2018). JavaFX was deprecated in Java 10 and removed 6 months later in Java 11. Dealing with Java 11 was really painful to the point where it really feels like Python 3 of Java. The company I work for had less issues with migrating to Python 3 than with migrating to Java 11, but your mileage may vary.
- shock 7y ago
  > JavaFX was deprecated in Java 10 and removed 6 months later in Java 11 JavaFX is not deprecated. JavaFX was extracted from the JDK as a standalone project: https://openjfx.io/ https://openjfx.io/
  - snuxoll 7y ago
    Ditto with the the other Java EE API’s GP mentioned, their interfaces are available on Maven Central instead of being bundled in the JDK - which makes sense as Java EE is not actually a thing anymore and the Eclipse Foundation took over as Shepard.
    - cesarb 7y ago
      > Ditto with the the other Java EE API’s GP mentioned, their interfaces are available on Maven Central Not all of them; AFAIK, there's no Maven Central artifact for what used to be in the CORBA packages.
      - pjmlp 7y ago
        Here you go, https://mvnrepository.com/artifact/com.sun.corba https://mvnrepository.com/artifact/com.sun.corba
- imtringued 7y ago
  They are no longer included by default but you can still add them back as maven/gradle dependencies.
correct_horse 7y ago
Idk how well-known this is, but Java 4 was actually Java 1.4. At Java 5, they dropped the "one point" marketing, but still called it 1.5 to devs. I'm not sure how this was resolved, or if there will ever be a Java 2.x (I doubt there will).
hinkley 7y ago
In an effort to shave a couple minutes off of a build process, back when everyone was still drunk on XML, I got into a conversation with one of the webmasters at W3C. A lot of people forget to cache public schemas and DTDs because the libraries don't by default and the setting is a bit buried. We were trying to convince him to sandbag responses a bit. I never followed up but it sounded like we almost had him convinced. My thinking was, I didn't notice the problem until we hit almost 2 minutes. If their website hadn't been so fast I probably would have identified the problem months earlier. Essentially his team were being punished for being so damned good at their jobs. I wonder how palatable it would be to slowly ramp up a pause in the compiler for "No, really, you need to stop doing this, and soon" types of misfeatures. Not a huge one, just enough so people really notice.

baby 7y ago

look at the monster that C++ is now because of this as well. I think this is why people are turning to Golang, Rust, and Swift. But these languages could follow the same path.

saagarjha 7y ago
Those three languages also happen to have memory safety.
- jhasse 7y ago
  And other features that differentiate them from C++. But I think that was the OP's point: People are switching to other languages mainly because C++ has become a monster, not because of missing memory safety.
  - jolux 7y ago
    I don't think that's the whole story. Golang is mostly picking up programmers from dynamic languages, according to Rob Pike, and Swift is gaining steam mostly because Objective-C while not monstrously complex like C++ is incredibly verbose.
    - pjmlp 7y ago
      Swift is gaining steam, because Apple dictates it, unless one enjoys using a frozen language. Likewese using C++ on Android requires perseverance given the how the NDK is handled and what it exposes, while on Windows it feels nice because it has parity with .NET tooling, specially on UWP.
      - chiefsucker 7y ago
        Using a frozen language isn’t the real problem here, though. The Apple ecosystem slowly gains new frameworks like SwiftUI that simply don’t work with Objective C anymore. The platform is abandoning one language similar to Microsoft and their VB story. It will take a long time, but AppKit & UIKit will end similarly to how Carbon ended on macOS.
        jolux 7y ago
        Except SwiftUI is built on AppKit and UIKit as far as I know.
favorited 7y ago
Swift can't remove things from the standard library anymore either. Otherwise if the OS updated, and a symbol was missing, apps needing that symbol wouldn't launch.
dodobirdlord 7y ago
Rust has Editions, so deprecated features can slowly age out of the ecosystem. People using, say, the 2015 edition will probably eventually want features introduced in the 2018 edition, and they will have to remove their usage of features that were dropped in the 2015->2018 edition bump. And if they never want any new features, maybe because their library is totally complete? Well, crates using 2018... can still depend on them, they just can't use those features.
- deleted 7y ago
  [deleted]

pjmlp 7y ago

Yeah, we all appreciate Python's success story. By the way, Java has removed deprecated stuff.

airstrike 7y ago
Nice straw man... I do want to point out how Django (which is obviously a Python framework, not the language), has a very solid deprecation policy
- pjmlp 7y ago
  It is a lesson on how not to do breaking changes, when one wants the community to actually adopt new versions.
  - chc 7y ago
    I'm not so sure. Ruby did a very similar set of breaking changes around the same time and it went fine. It seems to me like the main difference wasn't in the changes — it was that the Rails developers enthusiastically embraced the changes, which pushed everyone else to do the same, while Python had more of a diffuse situation where some library authors went for it and others didn't and it led to everybody getting cold feet.
    - pas 7y ago
      Py3 was too big of a change. It took until about 3.3 to get some ability to really write cross-compatible code. And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode.
      - airstrike 7y ago
        > It took until about 3.3 to get some ability to really write cross-compatible code. I disagree... you could always leverage six and/or do conditional imports based on sys.version > And some people were just okay with the unclear semantics of py2 with regards to bytes-unicode. Usually after searching for answers for quite a while on Stack Overflow...

dpbriggs 7y ago

I wouldn't be surprised if they remove it in the next rust edition

steveklabnik 7y ago
As discussed below, we cannot make breaking changes to the standard library via the edition system.
- kibwen 7y ago
  The function itself cannot be removed from the standard library (and likewise the symbol can never be reclaimed for a different use), but there's no reason that future editions couldn't report a compiler error when attempting to use the function. The function would only be inaccessible at the source level, not at the linking level, thereby completely preserving cross-edition compatibility while also mandating that crates remove references to it when migrating to a newer edition. Think of it like an edition-specific deprecation lint being turned from warn to deny.
  - steveklabnik 7y ago
    I think it's important to draw a distinction between what is true today, and what could be in the future. Today, the RFC text says: > More generally, breaking changes to the standard library are not possible. Could we amend this RFC to introduce a system like this? Sure. Have we? No.

Ericson2314 7y ago

What they should do is put as much of `std` on crates.io as possible (only a tiny bit is rustc-specific). Then in conjunction with https://github.com/rust-lang/wg-cargo-std-aware https://github.com/rust-lang/wg-cargo-std-aware uses can opt-in to to a `std-2.x`.

deleted 7y ago

[deleted]

j88439h84 7y ago

> Java's "never remove a deprecated API" was definitely one of their big mistakes. Even a 10-year deprecation cycle is better than none. Can you explain this position? Python just did a 10-year deprecation cycle on Python 2, but it was really costly for a lot of people. If they'd just not done that it would have been better; the benefits of removing stuff are relatively minor (cleaner language implementation codebase) and the costs are huge (all users need to change, test, handle compatibility, ...).

pas 7y ago
No, no, no. It was not a deprecation cycle. It was a complete stop using this because it's full of unclear semantics, here's the new thing cycle. Py3 should have simply started to warn when you used "bla" without u"..." or b"...", and so on. To clear up the bad code. Then later ... maybe 10 years later, make "..." equivalent to u"...". Maybe.
- amluto 7y ago
  I don’t know what the right solution to the string problem should have been. Python 2’a string handling was bad, and programs used it inconsistently and nonsensically. IMO the real problem is the near complete lack of static checking that you fixed it with. Sure, modern Python + mypy can do a credible job finding wrong-string-type bugs, but legacy Python 2 codebases don’t have the right annotations. I do wish I could tell Python 3 to error out if I accidentally put a str and a bytes in the same dictionary as keys.
  - ttwwmm 7y ago
    The core problem with strings in Python 2 was implicit coercion: you could mix `b''` and `u''` strings pretty freely as long as they only contained ASCII and they would be silently converted as required. Once you leave the ASCII range you start to see data-dependent bugs. To gracefully deprecate this behavior, you could start by generating a warning each time an implicit coercion is done. Next, make implicit coercion raise an exception, but provide a way to suppress it. Finally, remove the ability to suppress the exception. As the GP suggests, you'd do well to similarly deprecate unprefixed strings. This would all be pretty confusing to explain if you were renaming the string types at the same time, as Python 3 did. I think that's an indication that you shouldn't rename the types. You could deprecate `str` and just use the names `bytes` and `unicode`, which go nicely with the `b''` and `u''` mnemonics anyway. Python 3 also changed the type of string used for Python identifiers. You'd need a strategy there as well. It might be convenient to have some type-checking `dict` variants in the stdlib, but I think it's a separate issue from addressing the coercion issue.

GlitchMr 7y ago

Java actually removes deprecated APIs now, and it's doing it really really quickly (IMHO way too fast). For example javax.activation, javax.activity, javax.rmi, javax.transaction, javax.xml.bind, javax.xml.ws, javax.jws, and javax.xml were deprecated in Java 9 (released September 2017) and removed in Java 11 (released September 2018). JavaFX was deprecated in Java 10 and removed 6 months later in Java 11. Dealing with Java 11 was really painful to the point where it really feels like Python 3 of Java. The company I work for had less issues with migrating to Python 3 than with migrating to Java 11, but your mileage may vary.

shock 7y ago
> JavaFX was deprecated in Java 10 and removed 6 months later in Java 11 JavaFX is not deprecated. JavaFX was extracted from the JDK as a standalone project: https://openjfx.io/ https://openjfx.io/
- snuxoll 7y ago
  Ditto with the the other Java EE API’s GP mentioned, their interfaces are available on Maven Central instead of being bundled in the JDK - which makes sense as Java EE is not actually a thing anymore and the Eclipse Foundation took over as Shepard.
  - cesarb 7y ago
    > Ditto with the the other Java EE API’s GP mentioned, their interfaces are available on Maven Central Not all of them; AFAIK, there's no Maven Central artifact for what used to be in the CORBA packages.
    - pjmlp 7y ago
      Here you go, https://mvnrepository.com/artifact/com.sun.corba https://mvnrepository.com/artifact/com.sun.corba
imtringued 7y ago
They are no longer included by default but you can still add them back as maven/gradle dependencies.

correct_horse 7y ago

Idk how well-known this is, but Java 4 was actually Java 1.4. At Java 5, they dropped the "one point" marketing, but still called it 1.5 to devs. I'm not sure how this was resolved, or if there will ever be a Java 2.x (I doubt there will).

hinkley 7y ago

In an effort to shave a couple minutes off of a build process, back when everyone was still drunk on XML, I got into a conversation with one of the webmasters at W3C. A lot of people forget to cache public schemas and DTDs because the libraries don't by default and the setting is a bit buried. We were trying to convince him to sandbag responses a bit. I never followed up but it sounded like we almost had him convinced. My thinking was, I didn't notice the problem until we hit almost 2 minutes. If their website hadn't been so fast I probably would have identified the problem months earlier. Essentially his team were being punished for being so damned good at their jobs. I wonder how palatable it would be to slowly ramp up a pause in the compiler for "No, really, you need to stop doing this, and soon" types of misfeatures. Not a huge one, just enough so people really notice.