4 ms·

Did you explicitly pick 2.7, because compatibility guarantees became much stronger with 2.8 and later? Sometimes I wonder how many accounts that pron guy actua

Did you explicitly pick 2.7, because compatibility guarantees became much stronger with 2.8 and later? Sometimes I wonder how many accounts that pron guy actually has.

heavenlyhash 12y ago
... You really don't have to follow many links to find out that Sam Pullara is quite a real person, and that he has in fact worked at Twitter. Twitter does, as a matter of public record, have some investments in scala, and I daresay some employees at twitter might have valid practical comments on the outcomes. Accusing one person of FUD, and then accusing him of sockpuppeting in the same thread, while failing miserably at turing-test level human detection... really, I think this comment does more credibility damage to itself than to anyone it's trying to cast shade upon.
- frowaway001 12y ago
  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.

Did you explicitly pick 2.7, because compatibility guarantees became much stronger with 2.8 and later? Sometimes I wonder how many accounts that pron guy actually has.

heavenlyhash 12y ago

... You really don't have to follow many links to find out that Sam Pullara is quite a real person, and that he has in fact worked at Twitter. Twitter does, as a matter of public record, have some investments in scala, and I daresay some employees at twitter might have valid practical comments on the outcomes. Accusing one person of FUD, and then accusing him of sockpuppeting in the same thread, while failing miserably at turing-test level human detection... really, I think this comment does more credibility damage to itself than to anyone it's trying to cast shade upon.

frowaway001 12y ago
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.