A huge smell to me is that java frameworks have... frameworks... which have frameworks to finally arrive at a frankenstein's monster that is semi usable until its not and then woe-be-the-engineer saddled with its architecture. JSF is by itself is unproductive to develop with, so frameworks like RichFaces rose on top of it, which were also not enough, so other frameworks like Seam rose on top of them. And one feature of Seam is to make the JSF event-based framework behave more like an action-based framework ala struts or spring MVC. Maybe this should beg the question, "WTF are we doing with this dubiously helpful technology (JSF) at the foundation of our (web) technology stack?"

Its interesting to me that many "new" languages getting implemented are built on the JVM (or are old languages ported to java). I expect the JVM will outlive Java by a long margin.

- checked exceptions (usually leads to codebases full of empty try/catch blocks)

- the way generics got implemented

- how the current designers are afraid to change the language and keep adding annotations instead of new keywords (@override, @value, @notnull, ....)

- lack of type alias (typedef in C, type in Pascal/C/Go) to shorten declarations

- it would be nice to have aot compilation available as part of the standard toolchain, instead of forcing us to buy third party compilers

But the language is still quite usable and fulfills its purpose

I think you mean dynamically typed, which is not the same as weakly. But even that is not true: there are plenty of statically typed languages which are nowhere are verbose as Java, due to cultural differences, type inference, first-class functions, pattern matching, etc.

And even if my last statement is hyperbole, you can still use Java in your scala project for the critical parts where scala doesn't do a good enough job. Sbt, the standard scala build tool typically builds you src/main/scala and src/main/java folders. Write scala in the scala folders, java in the java folders, they can easily refer to each other, it's all seamless.

In my opinion the reason why Scala will never be mainstream. There has to be a balance between features and simplicity.

I remember reading somewhere that although you might decide to limit use of Scala language facilities (as there are too many of them), you'll still have to deal with them when trying to understand how libraries work (for debugging purposes for example).

I've written a bunch of production Scala code, and I'm glad to have gotten away from it. Obviously to each their own.

As for a small community, it hasn't bothered me. I get to cheat and use all the java libs.

Regarding compiler speed, I get the impression it's much worse on a mac than on linux (I use the latter, my colleagues use the former). On linux I've had little problem. I also tend to use `~ compile` in SBT. This will re-compile any time a file is modified, and notify you when an error occurs, so typically my code has already compiled by the time I actually want to run it. That's a really nice feature I wish I had in Haskell.

It always strikes me that the IDE/tools complaints have a high degree of FUD-spread to them. I've had good luck with both Intellij+Scala plugin and with the Eclipse plugin. And yes, my code is in production and is substantially more complicated than "hello world".

I -love- SBT and I detest the XML-hell at the heart of Maven projects. As you say, to each their own.

Scala is a gateway drug to FP, which, given my newly-acquired prejudices is a good thing. But that said, you still have the vast universe of Java libraries at your disposal, and if you really want to, you can use Scala in an imperative fashion and still get a Java-with-fewer-warts experience. I've not been following the Java 8 roadmap very closely, but with each new release the language seems to get more complicated and uglier, with patch upon patch, a list of which, if stacked end-to-end, would stretch from Chicago to New York and would fill three Library of Congresses and many other Standard Metaphors. It's been a joy to work with a language without all that legacy rolled into it.

You're right about the compiler, though for me it's not a huge issue. My builds take a minute or two, not tens of minutes. You're also right about the docs being weak at this time. There are definitely trade-offs either way in the Java vs Scala decision. For my purposes and my skillset, Scala is a sweet spot with Python a close second.

Agreed on the readability though.

IntelliJ provides an excellent free scala plugin. What have you been using?

Doubt it, Go code has much less need for generics than Java code. This is in part because of Go's interfaces which cover some of the same space, because Go has builtin map and slice types, and because the general coding style in Go.

Have you really felt the need for generics when writing Go code? Because that is very, very rarely the case for me, and talking with many other Go programmers, the need for generics seems to very rarely come up when actually writing real world Go code.

One has to realize that features are not interchangeable across languages, just because they are essential to some language doesn't mean that they even make sense in another language.

It would be so much more beneficial to write one stack struct with associated methods rather than having to duplicate functionality for each type.

It's possible to use empty interfaces, but then you have to do runtime type assertions which defeats the point of static typing.

Maybe I've just been spoiled by Haskell/Java in that side of things, but I really feel that compile time static typing solves A LOT of development problems