4 ms·

What's the reason we have to look at prehistoric versions of Scala? That's like criticizing Java for the lack of Generics by picking Java 1.4 as a reference.

What's the reason we have to look at prehistoric versions of Scala? That's like criticizing Java for the lack of Generics by picking Java 1.4 as a reference. It looks like the recent version upgrades for finagle and twitter-util were pretty smooth, so what's the point of picking old data over new?

kasey_junk 12y ago
Your reaction is precisely why some of us feel that Scala is not ready for projects that are targeting long term backwards compatibility and are large. A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. In that style of system you often see corners of the code base that are not touched for much longer than 5 years. The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. [edit] Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.
- frowaway001 12y ago
  > A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. Then enterprises should probably stay away from Java, too. Java 7 GA: July 2011. Java 7 EOL: April 2015. That's not even 4 years. > The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. Yes, I agree. I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore. > Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now. You could also run old Scala code on a current JVM. _But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java.
  - kasey_junk 12y ago
    "Then enterprises should probably stay away from Java, too. Java 7 GA: July 2011. Java 7 EOL: April 2015. That's not even 4 years. " You are being either extremely confused or employing a pretty smarmy rhetorical tactic by equating what the thread was about, source compatibility, and jvm support lifetimes. "I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore." Here you further degrade your argument by: 1) debasing the people who are arguing against you, people who have used and are using Scala currently and historically, just because they have issues with your pet language and 2) belittling the actual issue with using a semantic version number without using semantic version scheme. Some of the high level complaints about Scala include that they don't follow industry standards, that they show a lack of industry experience, that there is no idiomatic Scala way for newcomers to adopt. All of those are in evidence with the way they handle compatibility and versioning. It's not a reason in and of itself to give up on the language, but it is a damning problem that many people have run into many times. Scala is getting better at this but they have traditionally been abysmal so that is small comfort. "You could also run old Scala code on a current JVM. _But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java." Once again you are either intentionally changing the goal posts, or are showing extreme ignorance. We were talking about source compatibility. You can count on 1 hand the number of source compatibility issues you will run into with a 1.4 code base and a modern jdk. Even turning on deprecations will leave you with a very small amount of changes that need to be done. This is an extremely valuable property for some projects. Instead of trying to argue poorly against this benefit with bad rhetorical techniques, why don't you just admit what the rest of us know. Java made compatibility a huge priority. That it is a huge priority causes many many issues with the language. For many projects those issues make other languages more appropriate, but for others it is a huge boon. Scala simply made different trade offs, which make it more appropriate for some projects and less appropriate for others. I am a Scala developer currently and hope they don't try to emulate the compatibility model of the Java world because the kinds of projects I work on are better served without it. But I completely agree with pron when it comes to dismissing it as suitable for a large project with long time horizons. Finally, another thing I have to fight as a Scala developer in discussing it's suitability is a perception that the Scala community is overrun with zealots who dismiss real industry concerns at the altar of cutting edge features. I think that is a real but overblown concern, but you are displaying all the hallmarks of that caricature. You are making my job harder. Please stop.
- lmm 12y ago
  > The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics. b) Scala does comply with semVer if you take "compatibility" to mean "source compatibility", which is the most natural interpretation; the spec talks about API rather and not about ABI. c) Java's version numbering history is a total mess ("Java 2" is much older than "Java 1.8", for example). I really don't think industry is massively concerned about version numbering schemes.
  - kasey_junk 12y ago
    "a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics." No. The major.minor.patch version format predates either semVer or Scala and Scala's use of it may predate the codification of the semVer standard but most of that standard was very widely spread long before that. Most importantly, the expectation that only additive changes would bump minor versions and breaking changes would be indicated by a major version change has been near universal for a very long time. Scala to this day, breaks source compatibility with minor version bumps of the compiler. That is not a natural interpretation. Of course the industry doesn't care about version numbers. You could call it Scala Foo, then Scala Bar, then Scala Waz and no one would care in the least, but having expectations around and controls around source compatibility is very important to a certain segment of the development world and Scala has historically been very bad at that. I think that Scala has gotten much better in this regard over time, but for a lot of its history it was bad at this. This has made some people rightly leery of using it in projects with long time horizons.

kasey_junk 12y ago

Your reaction is precisely why some of us feel that Scala is not ready for projects that are targeting long term backwards compatibility and are large. A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. In that style of system you often see corners of the code base that are not touched for much longer than 5 years. The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. [edit] Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.

frowaway001 12y ago
> A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. Then enterprises should probably stay away from Java, too. Java 7 GA: July 2011. Java 7 EOL: April 2015. That's not even 4 years. > The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. Yes, I agree. I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore. > Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now. You could also run old Scala code on a current JVM. _But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java.
- kasey_junk 12y ago
  "Then enterprises should probably stay away from Java, too. Java 7 GA: July 2011. Java 7 EOL: April 2015. That's not even 4 years. " You are being either extremely confused or employing a pretty smarmy rhetorical tactic by equating what the thread was about, source compatibility, and jvm support lifetimes. "I have suggested changing this multiple times, so that the HN peanut gallery isn't intellectually overwhelmed with the epoch.major.minor.patch scheme anymore." Here you further degrade your argument by: 1) debasing the people who are arguing against you, people who have used and are using Scala currently and historically, just because they have issues with your pet language and 2) belittling the actual issue with using a semantic version number without using semantic version scheme. Some of the high level complaints about Scala include that they don't follow industry standards, that they show a lack of industry experience, that there is no idiomatic Scala way for newcomers to adopt. All of those are in evidence with the way they handle compatibility and versioning. It's not a reason in and of itself to give up on the language, but it is a damning problem that many people have run into many times. Scala is getting better at this but they have traditionally been abysmal so that is small comfort. "You could also run old Scala code on a current JVM. _But_ you can also deploy current Scala to a 10 year old JVM, which is not possible with Java." Once again you are either intentionally changing the goal posts, or are showing extreme ignorance. We were talking about source compatibility. You can count on 1 hand the number of source compatibility issues you will run into with a 1.4 code base and a modern jdk. Even turning on deprecations will leave you with a very small amount of changes that need to be done. This is an extremely valuable property for some projects. Instead of trying to argue poorly against this benefit with bad rhetorical techniques, why don't you just admit what the rest of us know. Java made compatibility a huge priority. That it is a huge priority causes many many issues with the language. For many projects those issues make other languages more appropriate, but for others it is a huge boon. Scala simply made different trade offs, which make it more appropriate for some projects and less appropriate for others. I am a Scala developer currently and hope they don't try to emulate the compatibility model of the Java world because the kinds of projects I work on are better served without it. But I completely agree with pron when it comes to dismissing it as suitable for a large project with long time horizons. Finally, another thing I have to fight as a Scala developer in discussing it's suitability is a perception that the Scala community is overrun with zealots who dismiss real industry concerns at the altar of cutting edge features. I think that is a real but overblown concern, but you are displaying all the hallmarks of that caricature. You are making my job harder. Please stop.
lmm 12y ago
> The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics. b) Scala does comply with semVer if you take "compatibility" to mean "source compatibility", which is the most natural interpretation; the spec talks about API rather and not about ABI. c) Java's version numbering history is a total mess ("Java 2" is much older than "Java 1.8", for example). I really don't think industry is massively concerned about version numbering schemes.
- kasey_junk 12y ago
  "a) Scala and the major.minor.patch version format predate semVer. You don't get to take the format that a lot of projects are already using and declare that it now has your particular semantics." No. The major.minor.patch version format predates either semVer or Scala and Scala's use of it may predate the codification of the semVer standard but most of that standard was very widely spread long before that. Most importantly, the expectation that only additive changes would bump minor versions and breaking changes would be indicated by a major version change has been near universal for a very long time. Scala to this day, breaks source compatibility with minor version bumps of the compiler. That is not a natural interpretation. Of course the industry doesn't care about version numbers. You could call it Scala Foo, then Scala Bar, then Scala Waz and no one would care in the least, but having expectations around and controls around source compatibility is very important to a certain segment of the development world and Scala has historically been very bad at that. I think that Scala has gotten much better in this regard over time, but for a lot of its history it was bad at this. This has made some people rightly leery of using it in projects with long time horizons.