+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 ..
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 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.
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...
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).
When sbt came out, Gradle wasn't as popular, the choices were either Maven or Ant at the time. If you are now starting with Scala, you have more choices.
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.
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.
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.
I'm not a Java guy, but Maven is much easier to learn but I have found some people in Java world religiously love Gradle. I don't know what is it with jvm language build tools ... Ehem sbt.
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.
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).
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.
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 have never fully understood why people are often upset with SBT.
Sure it is not perfect, but the alternatives are much worse and most of the issues people have with SBT projects are other people abusing the build file.
The REPL, fast incremental builds, continuous unit testing, shared SBT sessions, etc makes my day so much better.
I live all day long with: `~testOnly *WalabySpec -- -z killRoo`.
Whenever I have to jump into an app using Maven or only slightly better Gradle it is so frustrating.
reply