112

I am diving into Scala and noticed sbt. I have been quite happy with Gradle in java/groovy projects, and I know there's a scala plugin for Gradle.

What could be good reasons to favour sbt over Gradle in a Scala project?

Hans Westerbeek
  • 5,369
  • 3
  • 32
  • 33
  • SBT in some sense is like a Vim: if you grok it, you'll be pleased. And by the way, there is also maven and lein (was created for clojure, but works with scala too). – om-nom-nom Jun 16 '12 at 11:52
  • 19
    Don't feel pressured to move to SBT. Some well known members of Scala community use Gradle. Instead, use SBT as an experiment, knowing you can just use Gradle instead. – Daniel C. Sobral Jun 17 '12 at 01:37
  • 6
    thanks all... Having read your insights, I'll stick with Gradle. It seems to me that that is where most build-tool efforts for the JVM space is going to be as we leave Maven behind. – Hans Westerbeek Jun 17 '12 at 10:48
  • to write new sbt task : [enter link description here][1] [1]: http://stackoverflow.com/questions/9702863/create-a-new-task-that-runs-a-program/20282127#20282127 – vishal Jan 31 '14 at 07:55
  • 11
    It is annoying that this question is being marked as 'opinion-based' here, probably by people who don't work in the JVM-space all the time (and therefore lacking the oversight). The answers below are factual and devoid of holy-war-ism's. – Hans Westerbeek Dec 15 '15 at 11:00
  • Sorry, but e.g. [this answer](http://stackoverflow.com/a/11062038/3440745) and [that one](http://stackoverflow.com/a/11064434/3440745) look like exactly as opinion-based ones. And [this user](http://stackoverflow.com/users/73046/james-moore), according to its profile, is experienced with `scala` and `sbt`. – Tsyvarev Dec 15 '15 at 11:43
  • 5
    No, those answers are primarily statements of testable facts, not opinions. While this question *could* attract unhelpful answers, it has not, in fact, done so. It should remain open as a useful description of actual differences between the tools. – erickson Apr 21 '16 at 15:52

5 Answers5

61

Note that one key difference between SBT and Gradle is its dependency management:

  • SBT: Ivy, with a a revision which can be given as a fixed one (1.5.2, for instance) or as latest (or dynamic) one.
    See "Ivy Dependency"
    That means the "-SNAPSHOT" mechanism support can be problematic, even though Mark Harrah details in this thread:

It is true the cache can get confused, but it is not true that Ivy doesn't understand resolving snapshots. Eugene explained this point in another thread, perhaps on the admin list. There is an issue with sbt's auto-update that was addressed in 0.12.

What Ivy does not support, as far as I know, is publishing snapshots in the manner Maven does. I believe I have stated this elsewhere, but if anyone wants to improve the situation, my opinion is that effort is best spent working with the Gradle team to reuse their dependency management code.

Just to let you know, problems with Ivy and Maven snapshot dependencies were one of the reasons why Gradle eventually replaced Ivy with its own dependency management code. It was a big task, but brought us a lot of goodness.

This tweet mentions that the all situation could evolve in the future:

Mark said in the past that he was interested in using Gradle instead of Ivy for SBT.

(both tools can learn from each other)

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 1
    The most inconvenience I've ever met is sbt is that you could not specify for rule not to recompile each time it is mentioned. Built-in rules for java and scala have this functionality but it is not exposed for writing custom rules. So every time you generate a program file or documentation and even if you generate jar file your task would be performed on each call regardless of any changes to sources was actually done. Even make is smart enough, but not sbt – ayvango Jul 13 '15 at 23:37
  • 1
    @ayvango It's not the case for nowadays sbt. There are many plugins which utilize this functionality, like [android-sdk-plugin](https://github.com/pfn/android-sdk-plugin) – dant3 Nov 07 '15 at 13:21
  • Do you know what API is used for that functionality? – ayvango Nov 07 '15 at 15:01
  • so this is something ivy is lacking when comparing to both maven & gradle? That's strange – tribbloid Dec 23 '18 at 23:45
53

For me the key features of SBT are:

  • Fast compilation (faster than fsc).
  • Continuous compilation/testing: the command ~test will recompile and test you project everytime you save a modification.
  • Cross-compilation and cross-publishing, across several scala versions.
  • Automatically retrieving dependencies with the correct scala version compatibility.

The downsides are:

  • A hieroglyphic syntax that tends to discourage new users (especially if they come from Java)
  • No easy way to define a "task": if you need a special build procedure, you will need to either find a plugin, or write a plugin yourself.
paradigmatic
  • 39,013
  • 17
  • 85
  • 143
  • Am i correct that there is/was need for the cross-compilation/publishing feature due to the problems Scala has had with backwards binary incompatibility? – Hans Westerbeek Jun 16 '12 at 17:26
  • 1
    Yes. And these problems may happen again when moving to Scala 2.10. – paradigmatic Jun 16 '12 at 17:39
  • 1
    There are two more differences I'd add: * In SBT, it's easier to self-manage dependencies, IMO. * The SBT test runner seems faster; I suspect there's some cunning concurrency involved here but I'm guessing. SBT seems like a more capable but rather less mature product. – Rick-777 Jun 17 '12 at 11:28
  • Yes, the test runner is parallel by default (although you can make it run sequential if needed). I also agree that gradle seems more mature and polished than SBT. – paradigmatic Jun 17 '12 at 13:38
  • 25
    +1 for the 'hieroglyphic syntax' downside. That's my biggest gripe with SBT. Operator overloading always leads to abuse :-/ – Ron Dahlgren Apr 17 '13 at 23:03
  • 7
    The cryptic SBT syntax brings out the worst in scala. Gradle is based on a well thought out domain model and straight forward syntax. – nemoo May 24 '13 at 13:57
  • In the meantime SBTs fast, incremental compiler has been extracted into a separate library (zinc) and can actually be used by gradle's scala plugin. – Machisuji Jul 28 '14 at 08:58
  • You mention here 'Fast compilation', but sbt compiling is limited to single thread. Wouldn't switching to Gradle give you multicore performance as a bonus (which on a modern 8 core processor would blow sbt away)? – Michał Kreft Nov 28 '19 at 10:07
42

sbt is a Scala DSL and for it Scala is a first class citizen, so in principal it seems to be a good fit.

But sbt suffers from major incompatible changes between versions, which makes it hard to find the correct working plugin for a task and get it to work.

I personally gave up on sbt, since it was causing more problems than it solved. I actually switched to gradle.

Go figure.

Jens Schauder
  • 65,795
  • 24
  • 148
  • 294
  • 2
    As far, as I know, there was only one very major change: when sbt switched from 0.7.x to 0.1.x – om-nom-nom Jun 16 '12 at 11:53
  • 1
    If you use a plugin for sbt 0.11.2, and then go to sbt 0.12, you need to wait for the plugin author to compile a new version or do it yourself. idea-sbt is one example. – fmpwizard Jun 16 '12 at 13:15
  • 4
    @fmpwizard The sbt 0.12 line is not realeased yet... Stop spreading FUD. – paradigmatic Jun 16 '12 at 14:04
  • OK, here is another example. https://github.com/dvc94ch/sbt-scct . At work we used that plugin, and as the readme says, it only works with sbt 0.10.1 . to be able to use sbt 0.11.2 we had to go and use a different fork some other person is publishing that is build for sbt 0.11.2. It is not FUD. – fmpwizard Jun 17 '12 at 03:23
  • 1
    @fmpwizard I'm not sure enough, but looks like your problem has a really simple solution, analogous to that: https://github.com/ivmaykov/sbt-scct/commit/d73d42fac5a49debe814c04734bfc5b1186d99bf Correct me, if I wrong – om-nom-nom Jun 17 '12 at 12:03
  • 3
    It's not the sbt is impossible to use, our team uses it. But my comment was to suport this answer, which said "...But sbt suffers from major incompatible changes between versions, which makes it hard to find the correct working plugin for a task and get it to work..." Like you notice, I cannot just use the scct plugin, I had to modify it (yes small change, but then I had to publish it somewhere so my whole team could access it) A pain for no good reason. – fmpwizard Jun 18 '12 at 22:53
  • I myself suffered from this as well. I don't really know why in 0.13 they changed the sbt home structure to make me suffer, is that really necessary? – zinking Apr 10 '14 at 02:30
  • 3
    Are you able to do cross compilation for different Scala versions using gradle? – Machisuji Jul 28 '14 at 08:59
  • using sbt for 2 years; 0.13 was fine. Overall I'm happy with it. The DSL is very nice, and for all the complaints about operator-overloading... it's quite consistent in it's use. There are some brilliant aspects that I'm sure many people don't come to appreciate, such as the fact that the DSL generates declarative, immutable data structures which inform the build process. – Tim Harper Aug 02 '15 at 18:44
5

I'm fairly new to gradle, and very new to sbt - what I really like about sbt so far is the interactive console. It allows me to use commands like 'inspect' to get a better idea of what's going on. AFAIK gradle does not provide something like this atm.

eugenevd
  • 723
  • 6
  • 19
-11

Sbt and gradle, both are based on statically typed languages....but sbt has few advantages:

  • better plugin support, specially autoplugins
  • task creation and dependency management between tasks
  • sbt specially suits scala projects in the sense that it supports incremental builds and most of the sbt itself is written in scala and sbt build definitions is written in scala
  • sbt has interative shell support with many useful built-in tasks
  • sbt default lifecycle is pretty useful and can get novice started with pretty less effort
Saby
  • 73
  • 1
  • 7
  • 1
    Gradle is based on groovy which is not statically typed language. – Vistritium Mar 15 '16 at 14:39
  • Gradle does dependency management between tasks, it's as easy as possible to create a task, I have no idea how it can be easier to write a plugin than for gradle which can take groovy, Java, gradle plugins and possibly more. – Johnride Mar 21 '16 at 18:28