Hot Reload in the year 2019 is still a hard problem,although DCEVM seems to be solving it for now.<p>All the problems the author talks about were there in 2007 and are still there today. I bailed after the countless breaking updates to Scala and SBT. the level of productivity with a Lisp and REPL driven development is unmatched.<p>I just popped open an old Scala/Java source for doing a little maintenance after using Clojure for the last few years. There are entire files that could be replaced with a single function. Dozens of classes are complete unnecessary complexity only due to the type system forcing type wizardry. The SBT file I took one look and closed it immediately.<p>Clojure + Spec / Plumatic Schema and REPL driven development backed by tests is so good I have trouble imagining how it could get better.
I have six years programming in Scala and I unfortunately agree with everything in this article. Our work experience is very similar; competing approaches/styles, poor tooling, and slow feedback cycles. The language itself is nice is many ways, but it turns out that these things are more important.<p>We've started using Typescript a lot for http-templating style use cases (instead of Play) and I'd lean towards Go for the pure networky stuff. Combined these give a much better experience than Scala for our types of use cases.
> Sbt is probably the best example of what happens when you match academic thinking with actual code ...<p>> ... try to understand the library code that pulled in Scalaz and probably is written in the purely functional idiom of Scala that academics admire but mostly reminds me of Perl and other line-noise oriented programming languages.<p>> I really think that stuff like Scalaz has no place outside academia<p>It's hard to think of a type of criticism that is lazier than using "academic" as a pejorative.<p>> I have found the run-time type error in [static languages] a fairly rare occurrence and not worth the trade-off of having to live with a retarded assistant in the form of a mandatory type-checking compiler<p>... and there it is
> You want, at the very least, wrapper libraries to hide some of the nastier Java design patterns, so every time you add a Java dependency you will either have to find out its API and wrap the parts you need in some Scala code<p>Kind of describes why I have never succeeded in going beyond Groovy (despite trying). Despite all the claims, all the JVM language's claims of interop never pan out nicely in reality. Scala in particular is terrible because it replaces all the collections with its own and then you need layers of conversions between them which introduce overheads and idiosyncracies. On the other hand Groovy explicitly tries to have as little impedance mismatch with Java. It "automatically" enhances Java APIs with useful / functional methods so every Java API magically gets better without you doing anythign. With groovy you can <i>really have</i> what most people wanted, which is a "nicer Java", rather than a completely different language.
Even though I still enjoy Scala, the author’s perspective is valid. However, some of his pain could be eased by using Gradle instead of sbt and IntelliJ as an IDE.<p>The core frustrations that my team has are with the flexibility it provides and the complexity it seems to encourage. But, those can be tempered by having a team agree on a clearly-defined code style guide.<p>I feel like the original early adopters have moved on to other languages now. So maybe now the language can be appropriated by people who are focused more on productivity than novelty.
Yeah, parts of Scala have always struck me as the most beautiful language ever, but if you dig a bit deeper, it turns into one of the most horrifying languages ever. I think the future of the JVM looks more like Kotlin than like Scale or Groovy.