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.
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.)
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.
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.
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.
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).
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?
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.
About all I find myself using refactoring tools with for Java is renaming, honestly, so I guess I'm more likely to have my itches scratched by the current state of tooling.
Thanks for the explanation, though!
Every day I find myself asking if the language is worth the terrible tooling story, and so far the language keeps winning out. But I completely understand people who don't come down on the same side as I do on this issue.
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.
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.
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).