Bit of a quibble but I'm not sure I'd call that a "huge breaking change" given that that feature wasn't really implemented in the first place, let alone actually used.
It was a bad feature, as the two main C++ commercial products that make use of GC, namely C++/CLI and Unreal C++, were never taken into account while designing it, a good example how WG21 often does PDF driven design.
> C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard.
Not so sure I'd call these huge breaking changes. They're breaking, sure, but I'd expect them to be trivial to fix in any existing codebase.
Maybe VLAs are a huge breaking change? Most code never used it due to no way at all to use them safely, so while it is a pain to replace all occurrences of them, the number of usages should be really low.
Breaking changes are breaking changes, even if it is only fixing a comma, someone has to spend part of their time making it compile again, which many times maps to actual money for people working at a company, their salary mapped into hours.
No disagreement there, but the context ITT was specifically about huge breaking changes. I consider those breaking changes, but not necessarily huge ones.
I recall a lot of grumbling about VB.Net. I think most of us are happy never to hear people bitch about VB again. .Net was feared to be a bait and switch to get people off of it and that definitely seems to have been the case.
Swift! Multiple times introduced fundamental changes that were not only breaking but required semantic rewrites of code. The most recent breakage being Swift’s latest version adding concurrency features.
That happens to all guest languages unless that have unique selling points that make that differention happen and take off on their own, as genesis for their own platform.
See all platforms that have their identity tied with a specific language, the platform's language always has a guaranteed future as long as the platform continues to be industry relevant.
I was part of a book club of tech books and there was a ton of grumbling when we went through the Scala book. The consensus was this language was designed by nerds instead of language designers. Which either sounds like not a big deal or an insult worth dueling over depending on how much you pay attention to language designers and DX.
Full of Least Surprise violations, and just far too goddamned big. Did 3 try to pare that back into something reasonable?
It’s certainly a case that languages need to be championed by competent IDE writers otherwise they fail to scale. Because you can’t have 50 devs all using neovim - and only neovim - without making a huge gigantic mess. Large projects can sustain a few brilliant people working with one hand tied behind their back but not everyone.
I haven't used it much. I know a few people who have.
But as I said above, I realized long ago that languages without IDEs by and large falter in the long term (that's why I'm currently concerned about Jetbrains needing a buggy plugin to do Elixir), so Jetbrains being behind it added a lot of gravitas.
And after fighting with Larry Ellison for a bit, Android phones moved to Kotlin to get around the lawyers.
It's not dead dead, but no new projects are choosing it. Those that chose Scala as the better Java can now just use the better Java from the latest JDK.
Lots, but it's Pareto principle all over again. Those who wanted a sweeter Java were the majority of users. They have no real reason to switch to Scala 3 when Java 25 has 20% of Scala features that provide 80% of the benefits.
the OO/FP fusion hypothesis resulted in a complicated language on the OO side (too complicated for enterprise application layer) and on the FP side an autistic culture war at the seam between FP frameworks. Functional Scala remains world class at high reliability services such as video streaming at Disney+ and Comcast, and Amazon search but not so much the Java everyman use case that I recall it being marketed for 15 years ago. And now the Scala leadership and the industry frameworks are pulling in different directions, Scala is academically funded.
What started as a "this should be just a few namespace changes" might have cost thousands of person days in my current job. So many tests red, the whole CI/CD broken, and when all "fixed" and done, there were still some uncaught production bugs haunting us for many months... Simply horrible.
On paper, it really was just a few changes. In practice, it forced a massive transitive dependency and technical debt cleanup for many companies.
Java 4 to 5 was very rough. Sun kept trying to defer major changes, sort of how Elixir claims it is mostly done. But something changed in 5 and the floodgates opened. They made too many changes at once, and so out in the field you would bump into projects stuck on Java 4 even as 6 was in beta. And then 7, and a few past that.
Honest question. Is java whatever version today worth learning again?
Java is something I shoved of my life together with the MS stuff and never looked back, but there is still plenty of market for it anyway
I don't remember anything significantly bumpy for about 30 large-ish applications we migrated from 8 to 11, guess the mileage varied. JDK is serious stable stuff.
Deprecations, which also affects libraries, i.e. the dusty one you were chugging along on top of might need to be replaced or adopted because the original maintainer gave up years ago.
On top of that, there was the removal of built-in J2EE; you needed to add external copies of the J2EE pieces, and some of them (like CORBA) weren't available as separate packages. And later versions of these external J2EE packages changed the namespace of all their classes, which is especially painful in Java due to its common use of dynamic loading of classes by name and lazy linking (and lazy linking errors do not inherit from Exception, which allows them to escape from catch-all "catch (Exception e)" clauses). The rest of the ecosystem is starting to depend on these new versions, so staying with old versions of these J2EE packages is not an option.
The fact that Sun never removed any deprecated methods even after they were proven dangerous was a sticking point that generated friction between coworkers over new code using deprecated functionality.
I’m trying to port a reasonable popular node module to ESM and it’s not going well. I’m finding bugs in createRequire() and meanwhile functional differences between require and import might make some idiomatic code patterns not function at all.
> Ruby 1.8 to 1.9 has been fairly hard, despite being a minor version change.
Ruby 1.8 to 1.9 was a major version change in the semver sense; Ruby wasn't using Semver before, IIRC, 2.1.0, it was using a scheme that was basically loosely like Semver with an extra prefix number. Ruby minor versions were equivalent semver major (and also had a less-stable implication for odd numbers, more stable for even, Ruby “tiny” versions were equivalent to semver minor, and Ruby still had patch versions.
I can only think of 2: python 3 and perl 6.
Those two were very traumatic so it's not surprising it feels like more.