I kinda agree with this. Scala has good bits. Very good bits. Gorgeously beautiful bits, even. But the ugly bits are so terrifyingly ugly that I dare not touch it.
Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.
The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? But maybe I'm too used to different brackets meaning different things. I'm used to Java and Groovy where brackets are used very consistently.
The type safety goes way overboard with extremely arcane, incomprehensible expressions. The excessive power of the type system makes compiling far too slow. And the pattern matchers mean you can easily get your type back when you need it. I really strongly prefer the more dynamic approach of Groovy. Total type safety is a trap.
> The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist?
Yes, but which one would you remove?
If you disallowed the curly ones, developers would suddenly require an additional language feature to define methods which could be used like this:
using(someResource) {
// do something with ressource
}
Apart from that {} has semicolon inference, while () doesn't. That's extremely helpful, if you have some expression and really want to make sure that it can't be split into something like { doThing1, doThing2 } by an unaware developer.
> Total type safety is a trap.
Sure, there are limits on what can be done with a type system, but these options have been growing larger and larger in the last decades.
I wouldn't throw away the last 40 years of progress in that area and start doing stuff manually which any decent compiler can figure out for me.
> Groovy
I haven't heard from Groovy since a long time ago. Is it still actively developed? The last things I saw was that they were struggling to catch up, and work on the new MOP still wasn't finished.
On the Gartner PLI, Groovy is way down on position 20. That doesn't look too promising either ...
> I haven't heard from Groovy since a long time ago.
It's still the sole language used in Grails, which is losing adoption share to newer web frameworks. Gradle is on the rise, but Gradle will probably soon open its configuration as an API so any language can use it, so Scala and Clojure could become more popular for scripting Gradle in the future.
> Is it still actively developed?
There's a technical developer employed by Pivotal who's presently working on making Groovy work on Android. I don't know if he's working on it full-time or merely squeezing in development between fee-paying consultancy work.
> The last things I saw was that they were struggling to catch up, and work on the new MOP still wasn't finished.
I don't think work on a new MOP has started. It's pitched for Groovy 3 and the next version of Groovy is still version 2.x.
> On the Gartner PLI, Groovy is way down on position 20.
On Tiobe, it's still hovering around position 49, where it's been fluctuating since 2007, sometimes higher, often out of the top 50.
Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.