6 ms·

This assumes that past releases are not maintained, updated and stop existing as soon as a new version is released. None of this is true. Java people do the sa

This assumes that past releases are not maintained, updated and stop existing as soon as a new version is released. None of this is true. Java people do the same thing: They pick a version and stay with it, and migrate if/when it makes sense for their project.

ryanobjc 12y ago
Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. Java is backwards compatible in the syntax, and future compilers have, so far, been able to compile old code as well. Will that be the thing for Scala?
- adriaanm 12y ago
  There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.
  - kasey_junk 12y ago
    Scala 2.9 is 3 years old. That is a trivially short amount of time.
    - frowaway001 12y ago
      Seems to be on par with the practice of other vendors: Java SE releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public- updates (EoPU). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
      - kasey_junk 12y ago
        You can't possibly be comparing the binary and source compatibility of Java with Scala can you? I'm not an expert, but I haven't experienced a binary Java incompatibility in the wild and I've been using Java since before 1.0. As far as source compatibility you can count on 1 hand the incompatibilities between Java 1.4 released in 2002 with the current release and Java is not a paradigm for long term support! Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. Namely, Scala is free from the problems brought on by Java's strict backwards compatibility requirements and can continue to dramatically improve from version to version.
        frowaway001 12y ago
        > Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet, but not discussing interesting things like how union types will change the way people will write code, how collections could be improved, or how the arity-limitation of tuples could be dropped–because that would actually involve thinking and doing some research–it's a hard thing to do. Especially when it's likely that I'm going to be accused of "moving the goal posts" when doing that. It's kind of sad that there is pretty much no insightful technical discussion happening on HN, but at least I can have some fun with "somebody is wrong on the internet" when people make wrong claims.
        kasey_junk 12y ago
        "I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet..." "It's kind of sad that there is pretty much no insightful technical discussion happening on HN" Just as an FYI, in this 1 thread you've dismissively commented on some of the people responsible for the largest user bases of Scala and some of the oldest users of it. Maybe there would be more insightful technical discussions about Scala on HN if some of us who have actually written Scala in the wild didn't have to put up with derision every time we mention fairly obvious problems that we've encountered and instead could say things like "man useful automated refactorings would be really useful and who cares about tuple arity above 23 f'n parameters" Another hard thing to do is to deliver relevant business functionality. If your language/community doesn't make that easier, the faster it can be discarded the better.

ryanobjc 12y ago

Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. Java is backwards compatible in the syntax, and future compilers have, so far, been able to compile old code as well. Will that be the thing for Scala?

adriaanm 12y ago
There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.
- kasey_junk 12y ago
  Scala 2.9 is 3 years old. That is a trivially short amount of time.
  - frowaway001 12y ago
    Seems to be on par with the practice of other vendors: Java SE releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public- updates (EoPU). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
    - kasey_junk 12y ago
      You can't possibly be comparing the binary and source compatibility of Java with Scala can you? I'm not an expert, but I haven't experienced a binary Java incompatibility in the wild and I've been using Java since before 1.0. As far as source compatibility you can count on 1 hand the incompatibilities between Java 1.4 released in 2002 with the current release and Java is not a paradigm for long term support! Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. Namely, Scala is free from the problems brought on by Java's strict backwards compatibility requirements and can continue to dramatically improve from version to version.
      - frowaway001 12y ago
        > Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet, but not discussing interesting things like how union types will change the way people will write code, how collections could be improved, or how the arity-limitation of tuples could be dropped–because that would actually involve thinking and doing some research–it's a hard thing to do. Especially when it's likely that I'm going to be accused of "moving the goal posts" when doing that. It's kind of sad that there is pretty much no insightful technical discussion happening on HN, but at least I can have some fun with "somebody is wrong on the internet" when people make wrong claims.
        kasey_junk 12y ago
        "I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet..." "It's kind of sad that there is pretty much no insightful technical discussion happening on HN" Just as an FYI, in this 1 thread you've dismissively commented on some of the people responsible for the largest user bases of Scala and some of the oldest users of it. Maybe there would be more insightful technical discussions about Scala on HN if some of us who have actually written Scala in the wild didn't have to put up with derision every time we mention fairly obvious problems that we've encountered and instead could say things like "man useful automated refactorings would be really useful and who cares about tuple arity above 23 f'n parameters" Another hard thing to do is to deliver relevant business functionality. If your language/community doesn't make that easier, the faster it can be discarded the better.