I don't see a future for Scala. Since Java got lambdas and var, enough of the pain is gone that Scala ends up adding its own pain. And now there's Kotlin if you really want to avoid boilerplate and not deal with sbt.

Clojure is actually designed as a functional language and not as multi-paradigm as Scala.

> I don't see a future for Scala.

Yeah. It was pretty clumsy before it got less clumsy - and it makes me sad because a lot of the graph-based databased technologies glomed onto it pretty early on - and I mostly like where they say they are going. And their base compile Suxxor and they messed up their community with the new compile Python3 style.

I guess Kotlin is cool and clean - which is good. And has no ecosystem - which is bad. But stapling JVM language together for ad-hoc purposes is what we have learned how to do, neh?

For my part, I'm probably going to go back to high performance renderers and embedded systems. Like the man said bad in the day: "You can all go to hell - I am going to Texas". (Unfortunately I have been there for 30 years since I learned that I hate it.

Even with Scala 3 on the horizon (I believe end of Q1 2021)?

I recently worked on a Java 11/Spring app and there is still plenty of pain in Java to go around when compared to other, more terse languages.

Honestly I feel like if Scala would pick a less insane build tool, it would have much better adoption.

SBT is a disaster. I love scala as a language but hate sbt. Scala 3 looks promising but I seriously get PTSD thinking about scala. We have a lot of scala spark apps at the l financial company I work for and everyone gets scared touching it. Java has improved a lot since I last touched so I'm not sure people outside of academia will use it. For my PhD thesis I use scala without SBT and I love it.

Why do you think sbt is a bad build tool?

I've used the build tools of almost all the major languages (JS/TS, Rust, Haskell, Kotlin, C etc) and I don't honestly see any which are particularly easy.

A lot of it is philosophical - for the reasons that I dislike Gradle, I dislike SBT, but SBT has the honor of also having historically (and thankfully since cleaned up) esoteric syntax. I simply don't want builds to be allowed to reach the complexity that sbt allows.

I would definitely agree with your point that most build tools aren't easy! I've used maven and grumbled about it, and I'm mostly sold on scripting my build in the same language I'm using anyway, but in my long time on the JVM, it's always been the gradle and sbt projects that end up with inscrutable and hard-to-follow build scripts.

The sbt REPL also regularly breaks existing build scripts by changing how args are passed/parsed, or even how terminal color support works, and I just get sad every time I see a new, unexpected error from one of our CI runs.

Haoyi Li did a great piece on it: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html

Sure; but half the problems apply to other build tools too, not just sbt.

Take for example the point on syntax - is gradles groovy receiver syntax not just as esoteric as operator overloading?

Y does this too isn't really an interesting argument that X doing it is reasonable, I don't think (and my response to your initial question is entirely happy to lump Gradle in with SBT on its "understand-ability" demerits).

Don't get me wrong, my laundry list with SBT is huge - that single point was an example; but I have other points for make, cargo, cabal, stack etc...

My question was what makes SBT uniquely bad when the topic of build tooling comes up that people immediately comment how terrible it is.

For me, it's especially bad with the indirection, and the 3-dimensional cube of settings (I can never remember after all these years which one I want to set, the scope or the configuration or the task...). The complete mystery of how plugins affect the final build configuration.

I even went to a lot of effort to master SBT. I've read through the official docs numerous times, and Josh Suereth's Book https://www.manning.com/books/sbt-in-action, and I still feel like I don't grasp it very well. I'm just not smart enough for SBT.

I think a lot of it is probably just that sbt feels as deep as learning entire programming languages sometimes and that is not something I want in a build tool.

sbt is not perfect but new build tools are coming up lately for Scala (check out lihaoyi/mill and propensive/fury to name) plus people are working with bazel (but i guess that's more for monorepos/very big codebases. my experience (7 years and counting) with sbt is that it's very very good until you need to roll out your own tasks/plugins.

Several big mainstream products are implemented in Scala, including Apache Spark and Akka. Clojure has nothing of comparable size.

Apache Storm was written in Clojure, and was only recently rewritten in Java:)

Datomic is written in Clojure.

Metabase is written in Clojure.

I use a variety of languages and always feel that Scala gets a bad-rap because it's a compromise language (though I feel the same about Rust and most people seem to like it).

Scala 3 pros:

+ Higher-Kinds + Type-classes + Decent-ish hygienic macros + Decent OO model with mixins + for-comphrension + Compile-time evaluation + Laziness + Currying

It's pretty good at all of them - but not quite.

If you're used to Haskell you'll get annoyed at the fact that the inference is only within a single statement and that polymorphic functions resolve the typeclasses in a particular way.

If you're used to Scheme, you'll get frustrated that the identifiers can't be created easily in its new macro system or you can't manipulate the scope-sets of the identifiers.

If you're used to Erlang you'll wonder why Akka can't reload functions easily.

If you're from Java you'll wonder why everyone is going on about profunctors, effects and finally tag-less.

Scala seems to get the most love from spark users. But even then the python bindings are pretty good. Scala 3 is going to be released soon, so there might be a surge of interest.