Hacker News Reader

Hacker News

Comment by bryanlarsen | Hacker News Reader

Parent Full thread

bryanlarsen

> So many examples of programming languages have huge breaking changes between 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.

View on HN

.NET Framework => .NET

While C#, F#, VB and C++/CLI were kept compatible, it doesn't help when the library stuff you want to call isnt' there any longer.

C++ removal of exception specifiers, GC API,

C VLAs got dropped in C11, function prototypes changed meaning in C23, and K&R declarations were dropped from the standard.

Java, already someone else mentioned.

D, the whole D1 => D2 transition, and Tango vs Phobos drama.

> GC API,

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 could have been implemented privately by someone, but yeah I kind of agree.

https://cppreference.com/w/cpp/compiler_support/11.html

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.

It was breaking enough for the Linux kernel, and the money Google sponsored to the effort remove them,

https://www.phoronix.com/news/Linux-Kills-The-VLA

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.

> Breaking changes are breaking changes,

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.

Scala 3 has failed to be widely adopted, and now the language as a whole is more or less dead. Not that that’s due to the 2-to-3 transition entirely.

I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?

Don't know about Scala alternative, but the language I've found most enjoyable on the JVM is definitely Kotlin.

I wonder sometimes how much Kotlin contributed.

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'm curious about Kotlin. What makes it great for you?

I tried few times checking on it, but I failed to find something that motivated me to continue

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.

Scala still offers lots over modern Java.

The issue for me is that Scala design lacks focus. They say yes to too many features.

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.

Kotlin?

Ruby, Clojure, Kotlin n dare to say Groovy

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.

The others on top, come and go.

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?

Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.

Uh, wasn't the only breaking change a rename/changed path in some standard lib path?

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.

Introduction of modules, closing down of APIs that no one should be using, since Java 9 deprecated methods actually get removed a few versions later.

Also breaking changes do happen, see list of removed methods

https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...

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.

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.

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.

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

Ruby 1.8 to 2.0 with a layover in 1.9 was also not fun. Compared to python it is chicken shit of course

NodeJS with its commonjs vs modules, it's a huge mess IMO. Add typescript and build systems for bonus clusterf*cks.

the whole commonjs vs modules is there precisely because they chose not to introduce a breaking change.

Typescript has introduced breaking changes but they're not that bad

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.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.

triggered.

There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.

Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.

Although it was somewhat optional, adding async to Rust had a similar feel. Also various Swift versions had source breaking changes back in the day.

I gave up on Swift when the next release suddenly required actor annotations all over the place. They've been making weird decisions lately.

C++11 fucking with strings also comes to mind.

That was more a GCC problem, but yeah.

C++20 too but luckily basically every compiler has added a switch to turn that insanity off, saving the language.

ruby 1.8 -> 2 was miserable, especially as the linux distros kept 1.8 and gems started requiring 2.

Ruby 1.8 to 1.9 has been fairly hard, despite being a minor version change. Strings became Unicode, this broke tons of stuff. Also hash ordering.

This caused quite a lot of work on the apps I worked on.

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

php

Reply on news.ycombinator.com