Agreed. Maybe the situation has changed now, but it also didn't help that sbt's DSL is so inconsistent.

Back 2 years ago, when I still used Scala, sbt had two ways to write build files, the "old" and "new" ways, both non-trivial except for the simplest cases, and when you were troubleshooting/debugging problems with your build, all the answers you found googling were for the other style (facepalm).

What kills me is IJ underlines all my sbt files in red.

Ouch.

I remember back when Scala was still on version 1, the official/recommended IDE was Scala IDE, based on Eclipse. Eclipse was already a mess at that time, and people were abandoning it in droves even for Java work, but (bizarrely) Scala IDE was endorsed by Odersky.

Get this: refactoring -- critical for a language like Scala -- was totally broken on Scala IDE. Completely, unusably broken. Like, you changed the name of a function and the IDE inserted nonsensical garbage that didn't compile or even follow syntax rules everywhere. This situation went for long enough that most sane people migrated to IntelliJ. This was back then, no idea what the situation is now or whether Scala IDE still exists.

Sometimes when creating software that solves a hard problem, the author is so thrilled by all the little conceptual breakthroughs they experience along the way that they think the users of their software will enjoy it just as much as they did, so they write the software in such a way that the users have to make all the same conceptual breakthroughs in order to use it. SBT feels like that's what happened to it. It's completely inappropriate for a build tool. 99% of the people using a build tool shouldn't have to appreciate how hard it is to write a build tool.

I recommend to have a look at Mill. It's versatile, built on simple foundations, and implements many concepts from general-purpose build tools such as Bazel (but of course it was designed for Scala). It's easy to call it from various scripts too, and doesn't require you to design your project around your build tool.

At work we've used mill to first replace sbt and then also gradle in another project, and haven't looked back. It worked out-of-the-box for our JVM projects, and we trivially wrote custom "rules" for integrating cmake-based C++ projects into the build.