6 ms·

Yeah, but then it has also around 10K other features, most of which you don't need. Most Java developers won't be able to become Scala masters by 2018 anyway, i

Yeah, but then it has also around 10K other features, most of which you don't need. Most Java developers won't be able to become Scala masters by 2018 anyway, if at all. On the other hand C# has even better generics than this proposal, along with await, dynamic, yield. And it's now supported by MS and Xamarin on all big platforms.

jordanpg 12y ago
MS has announced that .NET will be supported by "all big platforms". We all anxiously await the download page that contains an MS-branded OS X CLR.
eropple 12y ago
I like C#, I write a lot of it, but the claims of complexity regarding Scala are just so vastly overblown. Anyone who's a competent Java programmer and has an open mind (which is the nicest way I can think of to say "doesn't pee themselves when they see a lambda") can be a competent Scala programmer within a month of daily use. It's not that hard, the tooling today in IDEA is roughly Java-level in terms of quality, and the language itself steers you towards constructs that make doing the Right Thing fairly easy.
- lukedegruchy 12y ago
  I disagree. I think Scala suffers from Perlisms like being too succinct and more than one way of doing things (ex omitting dots and parens to invoke a method). There are newer alternative JVM languages that are more consistent and preferable to Java, so I disagree with your argument that those of us that prefer not to use Scala are Luddites.
  - eropple 12y ago
    Meh? B&D languages bother me, for the most part--your criticisms would apply to C++, which I'm also happy to use. I mean, omitting dots and parens is primarily of value in flexible DSLs. Otherwise? Talk like adults and figure out the idioms you wish you adopt. Does one of your developers do something that you don't like. Then y'all talk it out. Not hard. Consistency is important, but effectiveness is, by my lights, moreso. Java's biggest problem isn't the language, which is sad, but its type system, and I've yet to see a newer alternative JVM language with a type system remotely worth discussing. (Which isn't to say it doesn't exist, but it sure isn't Ceylon or Kotlin.)
    - lukedegruchy 12y ago
      What's wrong with Ceylon's type system? I find it incredibly well designed. For instance, the Ceylon compiler won't allow you to assign null to a non-optional variable. Also, there is a bottom type, which makes controvariance far more manageable. I could go on.
    - jbooth 12y ago
      "Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively. That's a huge part of the 'which effective subset' argument against C++ and Scala. The argument is that, in the long term, 'simplicity and consistency', even if clunky at times, are way more effective than 'expressiveness'.
      - lmm 12y ago
        > "Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively. Omitting dots and parens is so superficial that you could change the code purely mechanically to your preferred style. Just like running an autoformatter on someone's code before reading it because you don't like their indentation style.
  - lmm 12y ago
    Omitting dots and parens is superficial; it's no more a Perlism than allowing whitespace or extra parens (which almost all languages do). Could you give an example of what you consider a more consistent JVM language? I find Scala is often more consistent, because it uses a small number of powerful features. E.g. Kotlin doesn't have Scala's implicits - so it instead has a bunch of different special-case features (e.g. extension methods) to replicate their use cases.
    - lukedegruchy 12y ago
      I disagree about the dots and parents. It impacts readability because the person reading the code, which most developers do 90% to 95%. If different developers on the team use different styles, it makes reasoning about the cod that much more difficult. I can't say I've followed Kotlin all that closely, but it struck me as a less dense language. Ceylon is a language I've followed closely, and I find it very consistent.
      - lmm 12y ago
        Ceylon is very nice, and probably is more consistent; first-class union types are a really good idea. Its Java interop story isn't quite as good as Scala's (without existential types, you can't express many Java generic methods - and try calling a Java generic method with a Ceylon tuple), and I don't think I could live without higher-kinded types and some equivalent to for/yield (do notation). But it does feel pretty elegant so far; we'll see if it can keep it up through years of language evolution.
        lukedegruchy 12y ago
        Java interop is way better with Ceylon 1.1. For example, use-site variance for generics was introduced and overloading bugs have been resolved. Ceylon 1.2 will have constructors (to support DI frameworks) and I believe Java EE integration. The Ceylon guys have been very careful about adding new features, considering the pros and cons. Strict Java interoperability would have resulted in a much less elegant language (ex public/protected/private instead of shared and allowing an escape hatch for null, as Swift and Kotlin have done).
- the_af 12y ago
  I like Scala (and I'm starting to use it in my day job!) but I don't really think IDEA tooling is "roughly Java-level" quality. In fact, all the Scala IDEs I've tried are astonishingly bad, IntelliJ included. The consensus among the more knowledgeable Scala programmers at my office is that IntelliJ is too quirky as an IDE (probably due to its built-in Scala compiler which gives way too many faux compile errors. This is maddening in a statically checked language!), and Eclipse-based Scala IDE is only slightly better. They recommend entirely disabling incremental compilation in the IDE, and instead using SBT for this. Coincidentally, this is what someone here on HN told me is the "unofficial recommendation" from the Typesafe guys -- I wouldn't know. As another example of broken tools, with Scala IDE refactoring is so fundamentally broken I cannot use it; it often results in wrong code (with Kepler-based Scala IDE, I've tried refactoring the name of a method and it resulted in syntax errors in other files!). Debugging is also hit-and-miss, at least with Scala IDE. This is miles away from most Java IDEs, which are perfect in this regard. Not having compile errors correctly reported as you type is truly disappointing. Not being able to reliable refactor or debug code is very frustrating. (I realize this is a tooling problem, and I love Scala. I'm just puzzled that almost nobody seems to consider these issues as disappointing as I do).
  - eropple 12y ago
    Maybe you're using different Java knobs than I am, but IDEA 13 (haven't bought 14 yet) is effectively the same for me between Java and Scala. The Scala environment is perceptibly slower if I pay attention to it, but not that much and is generally unnoticeable. I can't remember the last time I had a bogus compiler error. The only thing I can think of is that I only use imported SBT or Maven projects. Maybe that has something to do with it?
    - timv 12y ago
      My experience is much more like the one described by the_af . IntelliJ is OK for most Scala code, but it regularly makes a mess of anything complicated. So much so that, in our office, the first answer to "why doesn't this code compile" is "Does it really not compile, or is IntelliJ being dumb again?" It's usually the latter. I think it depends on what style of Scala you use. Anything involving slick or spray tends to confuse IntelliJ. Its better in 14, but it's still not good. The refactoring is bad enough that I hardly ever bother using it. It gets simple things mostly right, but doing that by hand is just as easy. It can't do the more useful things like method signature changes. The tooling support for Scala is improving, but its at about 10 years behind Java tooling.
- kasey_junk 12y ago
  Let me preface this by saying I've been a full time Scala dev for a few years now, and routinely make the choice to use Scala in new projects. That said, the complaints about Scala's complexity are not overblown in the least. If you ever had the opportunity to move from one Scala team to another, or to integrate 2 Scala teams that had grown independently previously, you see that even saying you are a Scala team does not narrow down significantly what to expect when opening up the code base. There is so much variance in what is and is not idiomatic Scala, that even the Scala standard libraries are a mix of styles and best practices. As for Scala steering you towards the "Right Thing", I'd argue that the Scala community has not settled on what that is (to the point of schism) and my experience indicates that quite the opposite is true. As far as IDEA achieving parity with Java, the very concept is laughable. Simple things like safe refactorings aren't, and syntax highlighting mistakes and phantom compile errors are common. While the IDE story in Scala has improved dramatically over the years, to say it is Java level is over selling it.
  - papauschek 12y ago
    Would love to hear in more detail about your experiences integrating Scala teams and the challenges that come with it. I only worked in a small team so far (3 devs) and had a good experience introducing Scala, but I can imagine that with people who have previous Scala experience and "their own style" can be problematic.
    - kasey_junk 12y ago
      The single biggest problem facing Scala right now is a lack of a true idiomatic style. When opening a Scala code base you can encounter everything from "Java without semicolons" to "scalaz style operator soup" and everything in between. Added to this is that "best practices" have migrated pretty significantly over time, and things that many people thought of as very beneficial are now often seen as problematic (xml support, mixins, large for comprehensions, implicit conversions, etc) but not everyone agrees on these. Compounding all of this is that the Scala "defaults" can lead to some pretty heinous problems and experienced Scala developers often have opinions that seem to directly contradict what Typesafe is selling (for instance, Akka, Play, the collections library, sbt etc. are all subject of ire for lots of people who have used them extensively).

jordanpg 12y ago

MS has announced that .NET will be supported by "all big platforms". We all anxiously await the download page that contains an MS-branded OS X CLR.

eropple 12y ago

I like C#, I write a lot of it, but the claims of complexity regarding Scala are just so vastly overblown. Anyone who's a competent Java programmer and has an open mind (which is the nicest way I can think of to say "doesn't pee themselves when they see a lambda") can be a competent Scala programmer within a month of daily use. It's not that hard, the tooling today in IDEA is roughly Java-level in terms of quality, and the language itself steers you towards constructs that make doing the Right Thing fairly easy.

lukedegruchy 12y ago
I disagree. I think Scala suffers from Perlisms like being too succinct and more than one way of doing things (ex omitting dots and parens to invoke a method). There are newer alternative JVM languages that are more consistent and preferable to Java, so I disagree with your argument that those of us that prefer not to use Scala are Luddites.
- eropple 12y ago
  Meh? B&D languages bother me, for the most part--your criticisms would apply to C++, which I'm also happy to use. I mean, omitting dots and parens is primarily of value in flexible DSLs. Otherwise? Talk like adults and figure out the idioms you wish you adopt. Does one of your developers do something that you don't like. Then y'all talk it out. Not hard. Consistency is important, but effectiveness is, by my lights, moreso. Java's biggest problem isn't the language, which is sad, but its type system, and I've yet to see a newer alternative JVM language with a type system remotely worth discussing. (Which isn't to say it doesn't exist, but it sure isn't Ceylon or Kotlin.)
  - lukedegruchy 12y ago
    What's wrong with Ceylon's type system? I find it incredibly well designed. For instance, the Ceylon compiler won't allow you to assign null to a non-optional variable. Also, there is a bottom type, which makes controvariance far more manageable. I could go on.
  - jbooth 12y ago
    "Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively. That's a huge part of the 'which effective subset' argument against C++ and Scala. The argument is that, in the long term, 'simplicity and consistency', even if clunky at times, are way more effective than 'expressiveness'.
    - lmm 12y ago
      > "Talking it out" isn't an option when you're dealing with code that's older than last week, let alone code written by developers that you've never met - you can't talk it out retroactively. Omitting dots and parens is so superficial that you could change the code purely mechanically to your preferred style. Just like running an autoformatter on someone's code before reading it because you don't like their indentation style.
- lmm 12y ago
  Omitting dots and parens is superficial; it's no more a Perlism than allowing whitespace or extra parens (which almost all languages do). Could you give an example of what you consider a more consistent JVM language? I find Scala is often more consistent, because it uses a small number of powerful features. E.g. Kotlin doesn't have Scala's implicits - so it instead has a bunch of different special-case features (e.g. extension methods) to replicate their use cases.
  - lukedegruchy 12y ago
    I disagree about the dots and parents. It impacts readability because the person reading the code, which most developers do 90% to 95%. If different developers on the team use different styles, it makes reasoning about the cod that much more difficult. I can't say I've followed Kotlin all that closely, but it struck me as a less dense language. Ceylon is a language I've followed closely, and I find it very consistent.
    - lmm 12y ago
      Ceylon is very nice, and probably is more consistent; first-class union types are a really good idea. Its Java interop story isn't quite as good as Scala's (without existential types, you can't express many Java generic methods - and try calling a Java generic method with a Ceylon tuple), and I don't think I could live without higher-kinded types and some equivalent to for/yield (do notation). But it does feel pretty elegant so far; we'll see if it can keep it up through years of language evolution.
      - lukedegruchy 12y ago
        Java interop is way better with Ceylon 1.1. For example, use-site variance for generics was introduced and overloading bugs have been resolved. Ceylon 1.2 will have constructors (to support DI frameworks) and I believe Java EE integration. The Ceylon guys have been very careful about adding new features, considering the pros and cons. Strict Java interoperability would have resulted in a much less elegant language (ex public/protected/private instead of shared and allowing an escape hatch for null, as Swift and Kotlin have done).
the_af 12y ago
I like Scala (and I'm starting to use it in my day job!) but I don't really think IDEA tooling is "roughly Java-level" quality. In fact, all the Scala IDEs I've tried are astonishingly bad, IntelliJ included. The consensus among the more knowledgeable Scala programmers at my office is that IntelliJ is too quirky as an IDE (probably due to its built-in Scala compiler which gives way too many faux compile errors. This is maddening in a statically checked language!), and Eclipse-based Scala IDE is only slightly better. They recommend entirely disabling incremental compilation in the IDE, and instead using SBT for this. Coincidentally, this is what someone here on HN told me is the "unofficial recommendation" from the Typesafe guys -- I wouldn't know. As another example of broken tools, with Scala IDE refactoring is so fundamentally broken I cannot use it; it often results in wrong code (with Kepler-based Scala IDE, I've tried refactoring the name of a method and it resulted in syntax errors in other files!). Debugging is also hit-and-miss, at least with Scala IDE. This is miles away from most Java IDEs, which are perfect in this regard. Not having compile errors correctly reported as you type is truly disappointing. Not being able to reliable refactor or debug code is very frustrating. (I realize this is a tooling problem, and I love Scala. I'm just puzzled that almost nobody seems to consider these issues as disappointing as I do).
- eropple 12y ago
  Maybe you're using different Java knobs than I am, but IDEA 13 (haven't bought 14 yet) is effectively the same for me between Java and Scala. The Scala environment is perceptibly slower if I pay attention to it, but not that much and is generally unnoticeable. I can't remember the last time I had a bogus compiler error. The only thing I can think of is that I only use imported SBT or Maven projects. Maybe that has something to do with it?
  - timv 12y ago
    My experience is much more like the one described by the_af . IntelliJ is OK for most Scala code, but it regularly makes a mess of anything complicated. So much so that, in our office, the first answer to "why doesn't this code compile" is "Does it really not compile, or is IntelliJ being dumb again?" It's usually the latter. I think it depends on what style of Scala you use. Anything involving slick or spray tends to confuse IntelliJ. Its better in 14, but it's still not good. The refactoring is bad enough that I hardly ever bother using it. It gets simple things mostly right, but doing that by hand is just as easy. It can't do the more useful things like method signature changes. The tooling support for Scala is improving, but its at about 10 years behind Java tooling.
kasey_junk 12y ago
Let me preface this by saying I've been a full time Scala dev for a few years now, and routinely make the choice to use Scala in new projects. That said, the complaints about Scala's complexity are not overblown in the least. If you ever had the opportunity to move from one Scala team to another, or to integrate 2 Scala teams that had grown independently previously, you see that even saying you are a Scala team does not narrow down significantly what to expect when opening up the code base. There is so much variance in what is and is not idiomatic Scala, that even the Scala standard libraries are a mix of styles and best practices. As for Scala steering you towards the "Right Thing", I'd argue that the Scala community has not settled on what that is (to the point of schism) and my experience indicates that quite the opposite is true. As far as IDEA achieving parity with Java, the very concept is laughable. Simple things like safe refactorings aren't, and syntax highlighting mistakes and phantom compile errors are common. While the IDE story in Scala has improved dramatically over the years, to say it is Java level is over selling it.
- papauschek 12y ago
  Would love to hear in more detail about your experiences integrating Scala teams and the challenges that come with it. I only worked in a small team so far (3 devs) and had a good experience introducing Scala, but I can imagine that with people who have previous Scala experience and "their own style" can be problematic.
  - kasey_junk 12y ago
    The single biggest problem facing Scala right now is a lack of a true idiomatic style. When opening a Scala code base you can encounter everything from "Java without semicolons" to "scalaz style operator soup" and everything in between. Added to this is that "best practices" have migrated pretty significantly over time, and things that many people thought of as very beneficial are now often seen as problematic (xml support, mixins, large for comprehensions, implicit conversions, etc) but not everyone agrees on these. Compounding all of this is that the Scala "defaults" can lead to some pretty heinous problems and experienced Scala developers often have opinions that seem to directly contradict what Typesafe is selling (for instance, Akka, Play, the collections library, sbt etc. are all subject of ire for lots of people who have used them extensively).