19 ms·

Scala isn't perfect, but it's a great language to have on the JVM. However, the lack of API and ABI compatibility is a really big failure. I can't believe that

by ant5 16y ago

Scala isn't perfect, but it's a great language to have on the JVM. However, the lack of API and ABI compatibility is a really big failure. I can't believe that they're shipping what is supposed to be stable software and we can't rely on our code to continue running, much less building. We had to do a fair bit of work to fix our projects' 2.8 compatibility issues, and it's causing us all sorts of grief in terms of having to do lock-step upgrades of all libraries from 2.7 to 2.8.

eeperson 16y ago
My understanding is that this release is partly intended to fix some of the earlier design mistakes before it gains too much popularity. They wanted to do this now rather than later to prevent a python3 scenario.
- deleted 16y ago
  [deleted]
  - sgt 16y ago
    A new release that is not entirely backwards compatible with older code. Python 3 was created to fix some of the flaws in Python 2.x.
joshhart 16y ago
Would you rather Java? Where everything is shit because of backwards compatibility? They've put a hell of a lot of work into making everything as compatible as possible with 2.7. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.
- strlen 16y ago
  > Would you rather Java? Where everything is shit because of backwards compatibility? ... or Perl5 for that matter. Python has continuously broken backwards compatibility in their APIs between releases and that has allowed it to shed much technical debt. It's annoying for developers, but it's better for the language and the ecosystem to keep evolving. Scala is taking the correct route here.
  - ant5 16y ago
    It's annoying for developers s/annoying/_expensive_/ but it's better for the language and the ecosystem to keep evolving. Of course it's good for things to evolve. But you're painting a false dichotomy here. Scala is taking the correct route here. In the short-term? Just once? That may be true due to just how broken some things were. In the long term? It's a very expensive thing to be breaking everyone's code and binaries.
- ant5 16y ago
  Would you rather Java? Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric? Where everything is shit because of backwards compatibility? Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly. Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it. They've put a hell of a lot of work into making everything as compatible as possible with 2.7 But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits. If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely. Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).
  - andrew1 16y ago
    That's an excellent response, and I'd mostly agree with you. I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose. Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.
- kingcub 16y ago
  The compatibility issue have to do with how Scala's traits have to be implemented on the jvm. If it was possible for an interface to have method bodies or abstract classes be multiply inherited in java bytecode the problem would be much less. Instead the bodies have to be compiled into the implementing concrete classes which leads to most of the problems.

by ant5 16y ago

eeperson 16y ago

My understanding is that this release is partly intended to fix some of the earlier design mistakes before it gains too much popularity. They wanted to do this now rather than later to prevent a python3 scenario.

deleted 16y ago
[deleted]
- sgt 16y ago
  A new release that is not entirely backwards compatible with older code. Python 3 was created to fix some of the flaws in Python 2.x.

joshhart 16y ago

Would you rather Java? Where everything is shit because of backwards compatibility? They've put a hell of a lot of work into making everything as compatible as possible with 2.7. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely.

strlen 16y ago
> Would you rather Java? Where everything is shit because of backwards compatibility? ... or Perl5 for that matter. Python has continuously broken backwards compatibility in their APIs between releases and that has allowed it to shed much technical debt. It's annoying for developers, but it's better for the language and the ecosystem to keep evolving. Scala is taking the correct route here.
- ant5 16y ago
  It's annoying for developers s/annoying/_expensive_/ but it's better for the language and the ecosystem to keep evolving. Of course it's good for things to evolve. But you're painting a false dichotomy here. Scala is taking the correct route here. In the short-term? Just once? That may be true due to just how broken some things were. In the long term? It's a very expensive thing to be breaking everyone's code and binaries.
ant5 16y ago
Would you rather Java? Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric? Where everything is shit because of backwards compatibility? Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly. Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it. They've put a hell of a lot of work into making everything as compatible as possible with 2.7 But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits. If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely. Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).
- andrew1 16y ago
  That's an excellent response, and I'd mostly agree with you. I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose. Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.
kingcub 16y ago
The compatibility issue have to do with how Scala's traits have to be implemented on the jvm. If it was possible for an interface to have method bodies or abstract classes be multiply inherited in java bytecode the problem would be much less. Instead the bodies have to be compiled into the implementing concrete classes which leads to most of the problems.