Years ago, I wrote a piece on the sbt build tool: sbt: why?!. Although I dislike how sbt works (and since I looked at the sbt internals I dislike it even more), my main complaint was not about how, but about the fact that sbt exists at all.

It seemed - and still seems - clear to me that enhancing Scala support in the mainstream build tools (Maven in 2011, Gradle now, at least for me) is more beneficial than creating Scala-specific build tools for the following reasons:

  • familiarity: developers are likely already familiar with a mainstream build tool, so it makes Scala adoption easier if it does not require learning a new build tool;
  • flexibility: developers are likely already using a mainstream build tool for the existing code, so it makes Scala adoption easier if it does not require switching all non-Scala-specific aspects of the build to a new build tool - especially since mainstream build tools have all kinds of non-Scala-specific plugins and integrations developed by an extended community, which a boutique Scala-specific build tool, with chances of it being adopted by non-Scala developers and enterprises being slim, is unlikely to be able to match;
  • reliability: mature mainstream build tools are by necessity complex and are developed and supported by large teams; a boutique Scala-specific build tool could not possibly provide equivalent level of support: even if designed, developed and maintained by “10x” engineers, it won’t be able to match hundreds of man-years that it took to mature the mainstream build tools.

Recently, I attended a very engaging and entertaining talk “Designing Simpler Scala Build Tools with Object-Oriented Programming” by by Li Haoyi. Here is the blurb:

Scala’s build tool SBT has always been a pain point for newcomers to the language, but build tools for other languages like Maven or Gradle often aren’t any better. This talk will explore why build tooling is fundamentally such a difficult domain to work in, and how common concepts from object-oriented programming have the potential to simplify the build tool experience. We will end with a demonstration of the Mill build tool that makes use of these ideas, proving out the idea that Scala build tooling has the potential to be much faster, safer, and easier than it is today.

The author demonstrated some easy-to-make but hard-to-find mistakes when using sbt, Maven and Gradle, and suggested that a build tool designed around object-oriented concepts avoids similar issues - with the help of IDE tooling that understands Scala, the language used for configuring Mill. Developers not willing to use Scala to configure the build are provided with an alternative configuration language: YAML (!); what are the benefits of the object-oriented design of the build tool in this scenario is not clear ;)

As a software developer, I understand every developer’s aspiration to design a programming language, write a compiler, create an operating system (or at least a shell), make a source control system and build a build tool. As an anarcho-capitalist, I wouldn’t, of course, force any developer to put the “good of the community” above his or her own aspirations even if I could.

The point remains, though: it seems that enhancing mainstream build tools with proper Scala support is more beneficial to the Scala community than creating more boutique build tools - even if Mill is great ;)

Of course, if Scala had special needs that mainstream build tools could not satisfy, we will be justified in an eternal search for the “better sbt”.

Indeed, there are some features required for Scala development which official Gradle currently lacks:

  • include some sources only when building for a specific Scala version;
  • produce artifacts specific to a Scala version used for the particular build;
  • compile, run, and test Scala code using non-JVM Scala back-ends: Scala.js and Scala Native;
  • allow some sources to be shared (“cross-compiled”) between some back-ends.

The thing is, all of the above can indeed be done in Gradle; I know this because I wrote a Gradle plugin that does all of it ;)

Of course, it would be better if the official Gradle plugin did all this, and if Gradle engineers cooperated with adding this basic functionality, but neither of those seems likely: official Gradle Scala plugin suffers from chronic neglect by both the “Gradle people” and the “Scala people” :(

Gradle the company seems to have given up on attracting Scala developers with its Scala support, and now caters to the sbt users:

Develocity by Gradle gives sbt users powerful ways to speed up builds, shorten feedback cycles, and gain deep insights into build performance.

Ironically, the same conference which Gradle co-sponsored and presented its sbt-based advantages at also included the same Mill talk by Li Haoyi: while Gradle switches to sbt, community is shifting to Mill :)

Judging by the number of bug reports and GitHub stars, my Gradle plugin is around two orders of magnitude less popular than Mill… Obviously, the community itself does not agree with my assessment of what is in its best interest ;)

Nonetheless, I personally remain convinced that enhancing Scala support in Gradle is worthwhile: I think that only “Path 1” from the three paths described by John DeGoes in his excellent New Scala Build Tool leads anywhere meaningful.

At least I can avoid switching to sbt (or Mill) :)