The last time I checked, sbt was much faster than mill for incremental builds. Mill has a faster cold startup time, but sbt uses classloader tricks to reuse jitted classes so that it doesn't have to reload the scala standard library. When running tests continuously and rerunning on save, sbt was much faster than mill for equivalent projects. I haven't tested in three years or so though. But I would encourage people to make a simple project in sbt and mill and run `sbt ~test` and compare it to `mill -w test`. In the past, I found that after a few iterations, sbt could respond to changes in a few hundred milliseconds while mill would take multiple seconds to retest the same code. That difference really adds up when you are iterating on a problem.
That said, I have come to believe that the jvm is a bad platform for a build tool. Everything that touches the jvm becomes bloated and slow, particularly for startup. I no longer write scala because of my frustration with the bloat (and scala adds its own bloat on top of the jvm).
The test thing is just a matter of defaults, in Mill subprocess testing is the default and in-process testing opt-in via .testLocal.
I also believed that a lot of existing JVM tooling is bloated and slow, so we are in agreement! Mill tries to be different, so do give it a chance if you can. There is life beyond Maven, Gradle, and SBT
sbt is one of the worst engineering mistakes I've ever witnessed. It was a constant source of esoteric ergonomics and frustration for no clear reason other than being the pet project of someone who really loved implicits.
That said, I have come to believe that the jvm is a bad platform for a build tool. Everything that touches the jvm becomes bloated and slow, particularly for startup. I no longer write scala because of my frustration with the bloat (and scala adds its own bloat on top of the jvm).