I don't think it was a conscious decision to not support Gradle, etc, it's just that sbt had a few highly motivated maintainers. This meant that sbt became the easiest tool to use when starting a Scala project.
sbt's incremental compilation was also very important for a language with long compile times and still-developing IDE support.
It would be great if Scala had great Gradle support. Nowadays some large Scala users maintain Gradle support for Scala to a good level.
In my own experience gradle is far simpler than SBT, especially when you factor in the binary incompatibility between scala versions and the technical debt this adds to your build plugins.
Plus compilation with SBT is ridiculously, laughably slow. Modifiying your build.sbt essentially causes a rebuild of your whole project. The complexity and expressiveness of SBT is a BAD THING in terms of compilation and troubleshooting.
Maven suffers from a different issue. Build processes are fundamentally procedural, not declarative so sooner or later you have to shoehorn your shell commands into a maven plugin section in your xml instead of just executing them as a line from within your build script.
I've been happy Scala and Gradle user for years now and it keeps getting better.
Also tooling works like a charm with IntelliJ first class support for Gradle.
IMHO Gradle is in a sweet spot of making simple things really simple and not making complex things (integrating native, custom plugins, multi project, Java interop) unnecessarily complex. Also Gradle has been getting faster and more user friendly every release.
I have been trying to gather motivation to tip my toe in SBT but without success.
We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT.
For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...
I enjoyed Frank Nothaft's talk about ADAM at Spark Summit East, cool to see y'all in the wild :)
FWIW I'm at a Scala shop where we use SBT exclusively. There's things about it that suck, it's definitely symbol-happy, but for our purposes it sucks less than Maven. Haven't looked into Gradle, all the other comments here have made me curious to try it out.
Used to use sbt at work, then someone came in with the idea that we should migrate to gradle. To be fair to them, they did most of the migration work by themselves, which was impressive.
I haven't really noticed any improvement, just that some workflows I was used to with sbt stopped being available.
currently I use sbt and as said they are okai to work with, but they are not great, else there would've been only one. ;)
Actually I like many things on sbt, but It has some clear downsides and it's not hard to figure them out.
Actually I would favor gradle from all of them however I started with sbt and I think I actually will stick with it a while, even if there are some downsides.
I like Gradle a lot. The build scripts are easy to read, and it's really easy to write nice plugins.
That said, my Scala-using colleagues are unanimously agreed that SBT is the way to build Scala projects. I suspect that some of that is purely about being fashionable, but there are certainly a few things you need to do with Scala (like handling the Scala version as part of artifact coordinates) that SBT does naturally that Gradle doesn't.
I would take SBT any day over Maven. The amount of tedious XML, over-complex poms, etc. etc. Every project I've worked with in Maven must have been setup incorrectly because they were all terribly painful to build.
That being said, I've tried Gradle (knew a guy who worked for them too) and it's really nice. I could see using it over SBT. The trouble is sbt has a lot of nice plugins (sbt-native-package, sbt-docker) which, last time I checked, didn't have equivalences in the Gradle world (they might now).
+1. SBT is a lot like Gradle but worse. Funny anecdote: SBT originally stood for 'simple build tool'. At some point this was changed to 'Scala build tool' and I can fully understand why ..
post author here, thanks, I think a couple things you said are spot on.
In a perfect world I would have discussed Gradle here as well, but I've never actually used it and so that fell out of scope (same with a more thorough treatment of Pantsbuild that I hoped to do).
Your articulation of Maven's issues also resonates :)
I do experience slow project reloads in IntelliJ (not as much on the SBT CLI), so that's fair. Not a dealbreaker given how much easier (read: more possible?) it is to express the logic I want to express in SBT, but reasonable people can disagree about those tradeoffs :)
Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT.
But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.
i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
Using SBT with Scala is certainly encouraged, but you can use other build tools. At work we're successfully using gradle without too many problems. The only things that are slightly weird are the not-so-perfect plugins for gradle, but that is understandable considering they are mostly community driven (sometimes only a one person even).
A lot of it is philosophical - for the reasons that I dislike Gradle, I dislike SBT, but SBT has the honor of also having historically (and thankfully since cleaned up) esoteric syntax. I simply don't want builds to be allowed to reach the complexity that sbt allows.
I would definitely agree with your point that most build tools aren't easy! I've used maven and grumbled about it, and I'm mostly sold on scripting my build in the same language I'm using anyway, but in my long time on the JVM, it's always been the gradle and sbt projects that end up with inscrutable and hard-to-follow build scripts.
The sbt REPL also regularly breaks existing build scripts by changing how args are passed/parsed, or even how terminal color support works, and I just get sad every time I see a new, unexpected error from one of our CI runs.
reply