> Most of the core assumptions here, on which you base your opinion, are not correct.

Which ones are not correct? What is the core philosophy of Scala?

>For instance, Scala removes tons of crazy stuff which plagues Java.

If they are removed, how can you claim efficient interop between the two? They are not removed, they are hidden/masked.

> I'm also not sure how one can add Scala's first-class OOP-FP integration as a minus. Have a look at all the other languages which only managed to do that in a lot more terrible way (F#, Java).

Anything the brings C++ inside JAVA is a minus.

>Generics as well. Why is the fact that scalac doesn't try and throw obstacles at you when programming with Generics bad? (Have a look at Java or C#, where tons of reasonable code is rejected by the compiler, because those compiler devs were too lazy to implement things properly.)

Java does not throw "obstacles" its just that the thing was not designed to handle Generics efficiently in the first place. The compiler rejects it because it is not in the spec.

>Same with macros. Have a look at the state of art in Java. It's a terrible mess with various black magic tools and invocations combined with poor IDE and tooling support.

See above, the core language spec does not have any macro facility. So what state of the art are you talking about? If you try to shoehorn it in, of course the result is black magic and poor support. And I am not too sure that macros are a 100% necessity -- Paul Graham advises sparing use of macros in your code. And he is talking about LISP code -- something that has the facility built right in.

>If you can handle Java, I don't see an issue with Scala. Most of the stuff in Java is done in a better, more consistent and better designed way.

For me, consistency means the ability to hold a reasonable model in my head. Java + Generics + OO-FP + Macros + god knows what else is not a reasonable model. Do not mistake complexity for power.

>I'm not seeing that at all. Care to explain?
Sure. Take Java syntax: If something is not designed to have a feature why do you want to try to shoehorn complex features in it? Clojure went the other way and completely changed the syntax, not mangling existing Java syntax.

Apply that to anything: the syntax, the compiler, the model, whatever.

>So Java is not mature, too? They are painfully adding mediocre lambda support right now. I'd call a language which was designed with lambdas in mind from the beginning and shipped with them since in 2005 more mature. The language in question is Scala.

I never said Java is not mature. In fact, it bends over backwards to accommodate code written in previous versions. If you want a language with lamdas built in (as an example of one feature) why not choose something that has been in existence for over 30 years, has tons of problems solved in it, was a result of original research first and commercialization later, has had more man hours thrown at its problems and implementation than Scala, etc? Why re-invent the wheel? Why not find a way of greasing the wheel better and applying a nice shine on it to make it attractive to modern programmers?

>I have never seen that in practice. I often wished code written in other languages would adhere to the standards of code written in Scala. That would make things a lot more readable, maintainable and understandable.

So all the people complaining about Scala library code readability are whiners? All code written in Scala is a lot more readable, maintainable and understandable?

Can you please point me to where the Scala specification is? It would have to be stand alone to implement in C, not built on something else. Genuine question. If there is a spec to the language (implying design and thought), why does the language keep on changing and breaking previous versions?

>Too bad, they are currently trying to add a half-baked static type-system to core. Again, I think a language which shipped with such basic things in mind since 2003 is a lot more mature.

How can an extension to something derived from decades of research lead to it being termed as not mature? Maybe they are adding it in now because the core design has proven itself -- for example after the almost effortless (conceptually speaking) porting of Go's goroutines/channels to Clojure core in the core.async extension. They had to introduce no mangled syntax and Generics for this -- to me this is elegant.

I would submit to you that nothing new comes without input from the old, and if you accept this I say Java is the wrong place to start. The JVM as a platform is awesome, the Java language is not.