Hacker News Reader

Comment by adenozine | Hacker News Reader

If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.

View on HN

Perhaps the better way to phrase this is "the day Lightbend deprecates SBT and tells the community to use Mill", but I agree with the sentiment.

Scala needs a new "official stack", hopefully Mill + utest/Munit + scalafmt (with opinionated settings).

Scala 3 + SBT + Scalatest + whatever formatting isn't going to grab folk's attention.

Exactly! You are far more eloquent than I am, from phone on porcelain throne.

> Scala needs a new "official stack"

Maybe so... but so do Python or Javascript. It seems to me some other languages have only one stack (rust: cargo, rustfmt...; the .net world as well). Does it make them better? (honest question). Then again, what's Java official stack?

I use Scala with Mill and Bazel for my OSS and professional work respectively. I haven't used SBT in 3 years. The post-SBT world is wonderful!

SBT in the last few years is nothing like SBT of five years ago. I agree it was a convoluted mess at one point, and now I much prefer it to Gradle.

curious. what exactly is wrong with sbt? I used it once of twice when I was learning scala and I liked it a LOT more than gradle/maven. To the point where I actually opted to use it with my Kotlin projects later.

From the same author as OP: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html

Being better than maven is not a high bar, you should try cargo/rust, to have a meaningful comparison of a good build system.

The only problem is, once you've tried out Rust, it will be difficult for you to come back to Scala.

To me, sbt is confusing as hell.

I no longer program in Scala, but I used to for my previous job and I regularly came across build files I couldn't understand -- and when I asked the person who wrote them, they couldn't explain their build properly either.

And this happened in enough cases that I wouldn't consider it an exception or a problem with a particular developer. SBT used to have two entirely separate syntaxes, and it was a mess translating from one to the other. I don't know if this is still the case (I know one of the two syntaxes got deprecated, can't remember which one now).

You need a phd in sbt to do things like "copy the jars", or "have a second set of dependencies".

The proponents of the approach that sbt takes have failed to realise that build tools have zero value whatsoever, every second spent on them is a second wasted.

What you want is a good mix simplicity (yes copy paste is fine) and some basic examples to follow, and the ability to break out into script if you are doing something unusual.

I don't know. I have no real love for SBT but I have yet to find a build tool that I actually like and that covers all the use cases and has the ecosystem that I want. Maybe it is just a really hard problem and extremely resistant to creating a simple interface. Unless of course you consciously decide to punt on the hard cases (which if fine sometimes).

I'd pick sbt over mvn no doubt. Haven't played with either fury or mill, so can't comment on those (even gradle... I never really used it). But coming from years of Java/Maven I think sbt is way better. Things start complicating a bit if you have lots of plugins or macros probably.

For new Scala devs, how much of a challenge is it to avoid sbt?

Especially for those coming from languages like Python and Go, where the former has no build system (ignoring setup.py), or an almost universal one (go build, sometimes make).

All of the projects I have touched are documented using sbt, and transitioning the build process for existing code projects while a new language learner is a double cognitive load.

It's easy; there's mill, maven and fury. Mill is quite good - but I've had to dive into the source code a few times to do things.

If you're dealing with dependencies only, then it's a straightforward change. OTOH I've never had an issue with SBT since it's cleanup a couple of years back so YMMV.

If you're already used to the JVM, it's easy: just use whatever you were using before (e.g. Maven) and everything works the way you expect it to.

If you're not, the documentation is missing as you say. Maven does just work, but the documentation assumes you're using Java.

Scala compiles well enough under Gradle--got it in a roughly dozen-module multi-language project right now, and it's no trouble. I suppose Gradle might (or might not?) come up short if you want automatic deprecation/replacement updates applied to source.

It looks like its a build tool? Are you obligated to use that with scala or something?

You're not obligated, but much like Maven is the build tool for Java, sbt is the build tool for Scala.

You use alternatives at your own peril. This means you won't be able to understand other people's builds, for example.

I know some Scala projects use Maven instead. Whether that's a good idea is debatable!

> You use alternatives at your own peril. This means you won't be able to understand other people's builds, for example.

The tradeoff is with SBT, you won't be able to understand your own builds!

(This is kind of a joke, but not really...)

Sadly, you're completely right. It's not a joke: it's happened to me. I still have nightmares about sbt.

we use it with Maven. no issues

Reply on news.ycombinator.com