Scala, Part II | Hacker News Reader

Scala, Part II

evrl.com

21 pointsmichael_fine11 comments

Hot Reload in the year 2019 is still a hard problem,although DCEVM seems to be solving it for now.

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.

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.

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.

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.

I was a TypeScript skeptic -- sum types >>> union types -- but I was wrong.

TypeScript is simultaneously (1) incredibly practical, (2) allows for type-level capabilities matching or exceeding Scala, (3) has excellent IDE support, (4) is explicit, and (5) related to #3 can compile sans type checking.

I don't love Node.js for server-side, but from language perspective, TypeScript really checks the boxes.

> Sbt is probably the best example of what happens when you match academic thinking with actual code ...

> ... 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.

> I really think that stuff like Scalaz has no place outside academia

It's hard to think of a type of criticism that is lazier than using "academic" as a pejorative.

> 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

... 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

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 really have 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.

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.

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.

There's a lot of stuff which is fine about Scala, but I still like this presentation: https://nurkiewicz.github.io/talks/2014/scalar/#/

In particular, this slide is my favourite: https://nurkiewicz.github.io/talks/2014/scalar/#/22

  // One of these doesn't compile
  seq foreach println
  seq.foreach{println}
  seq.foreach(println)
  seq.foreach{println(_)}
  seq.foreach(println(_))
  seq.foreach(x => println(x))
  seq.foreach(x: Int => println(x))
  seq foreach{x: Int => println(x)}
  seq.foreach{x: Int => println(x)}
  seq foreach{case x => println(x)}
  seq.foreach{case x => println(x)}
  seq foreach{case x: Int => println(x)}
  seq.foreach{case x: Int => println(x)}

Only one? If there's any justice in the world, it's the only one without any brackets. I fear it's one of the many without a dot, though.

This all depends which syntactic conventions you're used to.

"a + b" is more readable than "a.+(b)", and so that's what scala allows. I think it's a neat way of allowing operator overloading.

"iterable.foreach { ... }" is also readable for a callback.

FWIW, the one which doesn't compile is (apparently) "seq.foreach(x: Int => println(x))". https://scastie.scala-lang.org/krtG0VwgTmCNwIxATYFAbg

> I think the future of the JVM looks more like Kotlin than like Scale or Groovy.

Seems like an odd thing to say because Kotlin looks so much like Groovy. I'm curious what you are thinking of that distinguishes it in terms of direction?

Reply on news.ycombinator.com