5 ms·

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

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

dgfitz 1y ago
C++11 fucking with strings also comes to mind.
- pjmlp 1y ago
  That was more a GCC problem, but yeah.
- Blackthorn 1y ago
  C++20 too but luckily basically every compiler has added a switch to turn that insanity off, saving the language.
laszlokorte 1y ago
php
chillfox 1y ago
Ruby 1.8.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.
- tyre 1y ago
  triggered. There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.
  - andruby 1y ago
    Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.
jen20 1y ago
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.
- codr7 1y ago
  I gave up on Swift when the next release suddenly required actor annotations all over the place. They've been making weird decisions lately.
jameslars 1y ago
Java 8 -> anything 11+ wasn't great at scale. It's been smooth sailing for a long time again though.
- ffsm8 1y ago
  Uh, wasn't the only breaking change a rename/changed path in some standard lib path?
  - cess11 1y ago
    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.
  - pjmlp 1y 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-apis.html#GUID-44E8E37A-3000-47C6-B851-CDEB3FB50495 https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...
    - cesarb 1y 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.
    - hinkley 1y ago
      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.
isodev 1y ago
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.
agrounds 1y ago
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.
- patates 1y ago
  I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?
  - codr7 1y ago
    Don't know about Scala alternative, but the language I've found most enjoyable on the JVM is definitely Kotlin.
    - hinkley 1y ago
      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.
      - motbus3 1y ago
        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
        hinkley 1y ago
        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.
throwawaymaths 1y ago
ruby 1.8 -> 2 was miserable, especially as the linux distros kept 1.8 and gems started requiring 2.
thibaut_barrere 1y ago
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.
- dragonwriter 1y ago
  > 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.
pjmlp 1y ago
.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.
- aw1621107 1y ago
  > 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.
  - pjmlp 1y ago
    It could have been implemented privately by someone, but yeah I kind of agree. https://cppreference.com/w/cpp/compiler_support/11.html 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.
- lelanthran 1y ago
  > 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.
  - pjmlp 1y ago
    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 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.
tobyhinloopen 1y ago
NodeJS with its commonjs vs modules, it's a huge mess IMO. Add typescript and build systems for bonus clusterf*cks.
- agos 1y ago
  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
- hinkley 1y ago
  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.
nasmorn 1y ago
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

dgfitz 1y ago

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

pjmlp 1y ago
That was more a GCC problem, but yeah.
Blackthorn 1y ago
C++20 too but luckily basically every compiler has added a switch to turn that insanity off, saving the language.

laszlokorte 1y ago

php

chillfox 1y ago

Ruby 1.8.7 -> 1.9.0 caused a lot of problems in the sysadmin space that took years to get resolved.

tyre 1y ago
triggered. There was a rails upgrade around that time that was similarly painful, at least in the humongous rails app I was working in.
- andruby 1y ago
  Rails 1 to 2 was a big one indeed. Rails 2 introduced restful routes iirc, which meant refactoring a lot of fat controllers.

jen20 1y ago

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.

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

jameslars 1y ago

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

ffsm8 1y ago
Uh, wasn't the only breaking change a rename/changed path in some standard lib path?
- cess11 1y ago
  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.
- pjmlp 1y 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-apis.html#GUID-44E8E37A-3000-47C6-B851-CDEB3FB50495 https://docs.oracle.com/en/java/javase/17/migrate/removed-ap...
  - cesarb 1y 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.
  - hinkley 1y ago
    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.

isodev 1y ago

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.

agrounds 1y ago

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.

patates 1y ago
I haven't been following, now I'm sad to hear... Scala is really dead? What'd be the JVM alternative?
- codr7 1y ago
  Don't know about Scala alternative, but the language I've found most enjoyable on the JVM is definitely Kotlin.
  - hinkley 1y ago
    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.
    - motbus3 1y ago
      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
      - hinkley 1y ago
        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.

throwawaymaths 1y ago

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

thibaut_barrere 1y ago

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.

dragonwriter 1y ago
> 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.

pjmlp 1y ago

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

aw1621107 1y ago
> 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.
- pjmlp 1y ago
  It could have been implemented privately by someone, but yeah I kind of agree. https://cppreference.com/w/cpp/compiler_support/11.html 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.
lelanthran 1y ago
> 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.
- pjmlp 1y ago
  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 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.

tobyhinloopen 1y ago

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

agos 1y ago
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
hinkley 1y ago
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.

nasmorn 1y ago

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