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.

> 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/

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.

> 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.

Here you go, https://mvnrepository.com/artifact/com.sun.corba

They are no longer included by default but you can still add them back as maven/gradle dependencies.

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.

> 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, ...).

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.

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.

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.

IMHO, it would have been to repurpose the existing format for Unicode (specifically UTF-8) text and have a special notation for binary/ascii text.

It’s interpreted code, ffs. It’s not like you have pre-compiled binaries you need to stay ABI compatible with (like Microsoft did when they introduced TCHAR and co).

Among other problems, there was never a time when you could combine python 2 and 3 in the same program. That wasn't a deprecation; it was simply a break.

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.

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.

Those three languages also happen to have memory safety.

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.

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.

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.

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.

Except SwiftUI is built on AppKit and UIKit as far as I know.

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.

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 uses can opt-in to to a `std-2.x`.

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

As discussed below, we cannot make breaking changes to the standard library via the edition system.

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.

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.

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).

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

It is a lesson on how not to do breaking changes, when one wants the community to actually adopt new versions.

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.

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.

Like I said, I have trouble buying that as the reason, because a very similar Ruby release right around the same time did not cause the same problem. The major change in both cases was that strings now force you to consider encoding rather than just treating everything as a blob of probably-ascii-but-whatever-who-cares bytes. Writing code that was both Ruby 1.8 and 1.9-compatible wasn't easy, and there wasn't something like six to help you do it. The Ruby community generally responded by just supporting Ruby 1.9 going forward, and there was no major schism.

Ruby did have a decent transition path for strings too https://news.ycombinator.com/item?id=22038660

I think Ruby was helped by its great tooling (gem, lockfile, bundler), plus it was just advertised/communicated/presented as the next logical step forward, not a major release, no talk about supporting the old release for years, etc. (I don't know about Ruby's LTS policy, but the point is that 1.9 was not special, so it did not instantly made 1.8 "sacred" too.)

> 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...

> I disagree... you could always leverage six and/or do conditional imports based on sys.version

Sure it was possible, but what benefit would doing all that work get you? More memory use! It wasn't until Python 3.5 that Python 3 was clearly better for most use cases. Even today the regression import performance is problematic for CLI tools.

six hit 1.0 in 2011, py3.0 was released in 2008.

The point is that the whole py2-3 change was not incremental enough. (We started an ecommerce project right around 3.4, and many, many libs were in shambles, no official py3 support, just random forks on GitHub. The whole Python ecosystem was in a rather sad state. No mypy, no pipenv/poetry/dephell.)

All the gashing of teeth spent on the useless flamewars about py2/py3 could have been spent on other things.

> Usually after searching for answers for quite a while on Stack Overflow...

I was explicitly thinking of Armin Ronacher a prolific library author. ( https://news.ycombinator.com/item?id=13145172 )

You didn't need to switch over to Python 3.0 in 2008, though.

Yes, 3.4 was still not smooth but also not a disaster. I still don't use pipenv, mypy, poetry or dephell and life is fine...

That's the problem. Py3 was basically a hard fork with no real benefits for years, but by then it became a sort of ideological rift, and people started back-porting stuff instead of upgrading.

Like a handful, tops.