While I understand and sympathize with this viewpoint, I don’t really agree, for a couple of reasons.
First, the separate Scala tools didn’t come out of nowhere – they evolved because the existing Java tools didn’t work as well as one might wish in the Scala context. For example, you say:
I don’t think that’s true. ScalaTest is easier to use for idiomatic Scala code than JUnit is – there’s less boilerplate, and it leverages Scala’s power to do a lot of cool things easily. And ScalaCheck is hella powerful, and remarkably easy to use.
Mockito, IMO, is terrible for Scala code (we do use it a moderate amount, and I spend too much time helping fix problems caused by it), because it is fairly weakly-typed and null-centric, both of which are a poor match for Scala, so the resulting tests tend to be brittle. (Granted, ScalaMock isn’t perfect either, but it’s at least better-typed.)
sbt, for all folks complain about it, became popular because folks found the common Java alternatives painful to maintain big Scala projects. I know several people who have tried the Java alternatives because they were so annoyed at sbt, and wound up coming back to sbt afterwords because they found it the least-bad option.
Not to mention that Scala now runs on platforms that Java doesn’t. You must use Scala’s own test tools if you’re going to test cross-platform, which many projects do nowadays. Scala’s environment is now a superset of Java’s, so the Java ecosystem doesn’t cover all of its needs.
I think you’re coming at this from a somewhat Java-centric viewpoint, and that was once absolutely central for Scala – but the world has moved on. When I’m training up new folks, they’re as likely to come from a background of JavaScript, or Python, or Ruby as they are from Java. (Personally, I came from C#.) When you are coming at Scala from Java, it seems weird to see “redundant” tooling like this; but when you aren’t, the Scala tooling (IMO) looks more appropriate and focused on the task at hand than its Java counterparts.
The different toolsets does make it more of a challenge for Java-centric companies to adopt Scala – the same way it would be a challenge for them to adopt Ruby or C# or whatever. But I’m skeptical that it is much of a challenge for individual engineers to pick up Scala. I’ve been training up a bunch of Java folks recently, and all of them have picked up the Scala tooling quickly, easily and enthusiastically. So one shouldn’t over-estimate this issue.
I’ll totally grant that Scala’s homebrewed tooling hasn’t been historically as mature and robust as we’d like. But the community has woken to that in the past couple of years, and tooling development has gone from being an afterthought to being pretty front-and-center. I’ve been really happy to see the rapid and dramatic improvements of everything from sbt to editor support over the past couple of years. There’s still a long ways to go, but it now feels like we’re getting to the point of having an ecosystem we can be proud of, which suits Scala well.
I think that’s an overstatement, although an understandable one. Folks talk about Mill a lot, because it’s New and Cool, and in some ways is easier to understand and more easily-powerful than sbt. But I’ve seen relatively little Mill usage in the wild yet. We’re only using it for one of our hundreds of Scala projects – and that only because it’s a fork of uPickle, which was already using Mill.
I think Mill might eventually become one of the dominant tools, but I believe adoption is still pretty modest at this point, and growing slowly. It is early-stage and somewhat immature, everyone knows that, and it’s going to take a while (if ever) before any sort of critical mass of projects moves to it…
