Who is winning the build war with Scala So Far?


#1

I have been studying Scala in my free time for going on 2 years now; whenever I can squeeze in the time to do so. So far, I have only used:

  1. Repl
  2. Maven
  3. ScalaEclipse
  4. That WorkSheet Thing for maybe my first couple of weeks.

Yet, whenever I visit most Scala forums or hear about using Scala with Intellij , I keep hearing about SBT. Am I the only person learning Scala that uses Maven and Eclipse?


#2

JetBrains has posted fresh survey results, but it’s not clear to me if the answers apply to only Scala projects or also to Java ones: https://www.jetbrains.com/research/devecosystem-2018/scala/


#3

interesting. SBT wins out by 50 percent over Maven. I wonder which one is growing or declining faster. I would suspect that maven is growing faster in Scala Usage than SBT as more and more java developers start learning the language since they are already familiar with maven. Even in the world of java, when it comes to Maven versus Gradle, maven always wins out because of the larger population of developers that are using it. Part of the problem that SBT will run into but to a lesser degree is the same problem that Gradle ran into: Using a programming language as the build tool. That is just my guess, though.


#4

I don’t see how using Scala in build definitions is problematic for Scala developers. If you’re using Gradle to build Java projects then you essentialy have to learn new language - Groovy. That’s not the case with SBT - Scala is used both for production code and for build definition. Problem with SBT is different than using Scala as a foundation - it’s rather cryptic syntax, unintuitive execution flow and general slowness. Li Hayoi attempts to fix that problems by building his own build tool for Scala: https://github.com/lihaoyi/mill Mill is rapidly gaining popularity in Scala world so it’s even harder to guess which tool will prevail in future.


#5

Right now, my mindset wishes to separate languages from the actual build tool. The build too, in my opinion, should be language agnostic. I could be wrong of course. But I feel that the future of build tools does not hold well for SBT. Also, I think it is doing more harm to Scala than good. Now, within the hardcore Scala world made up of developers that actually started with Scala in Academia, SBT will continue to be the build framework of choice. But within the Enterprise world , that will not be the case. There is a lot of pushback against SBT in Java Environments. They are interested in Scala being used in their environments but do not have much patience in having to learn a new build tool to build and deploy.


#6

Maven is a complex tool too, so if someone doesn’t know Maven nor SBT then there’s not much difference when learning them. Maven also requires writing Java code if there’s no existing plugin that you can configure in your pom.xml. I had to write Maven plugin in Java during my job as a Java programmer and it turned out to be a pretty hard job in that case. I don’t think Maven is easy tool for plugin writers. SBT also isn’t.

I agree that SBT is complex and simpler (or more intuitive for Scala programmer at least) tool is needed, but I don’t see how XML is superior to Scala for Scala programmers. You’re conflating two characteristics of SBT build definitions: they are complex (rather hard to write) and they are written in Scala. Then you’re blaming the wrong one for being a source of problems.


#7

Some answer to questions you did and didn’t ask

Am I the only person learning Scala that uses Maven and Eclipse?

No, probably not, but you’re most likely in the minority. That’s OK, you’re allowed to use any build tool you prefer, obviously.

I wonder which one is growing or declining faster. I would suspect that maven is growing faster in Scala Usage than SBT as more and more java developers start learning the language since they are already familiar with maven.

I think this is projection from your side. From your posts, you seem to be under the impression that Maven is obviously the better tool for real world users, and that any data that shows Maven isn’t a very popular tool for building scala probably is wrong or misleading or soon to be outdated.

Using a programming language as the build tool.

I don’t think this is a problem at all. In Maven they use XML schema as a (declarative) programming language to program Maven to build your project. Scala is not domain-specific, but a general-purpose programming language. Maven quickly shows that if you want to build things you didn’t expect, you need to write plugins in a general-purpose programming language in order to support the domain-specific language to be able to do what you want.

The hardcore Scala world made up of developers that actually started with Scala in Academia, SBT will continue to be the build framework of choice.

This is anti-intellectual bullshit. I’m sorry, but I have to call a spade a spade here. You’re putting away programmers who have a different preference in build tools away as if they are some sort of dusty ivory tower irrelevant idiots who have no idea how the real world works, and you’re doing so based on absolutely nothing other than your gut feeling that Maven is so obviously better, people choosing to use SBT over it must have some external reason, but Real Programmers who program real things in the real enterprise world will surely see the superiority of Maven.

SBT sure is complicated, it feels way more complicated than it should be

It sure is. Boy is SBT a pain in the ass at times. And it’s ridiculously complex and convoluted. I’m eagerly looking towards cbt and mill to see if they do better - or maybe a more principled approach will grow out of typelevel some day. I’d love to see that too. I’m convinced we can do a lot better than SBT. But I’m also pretty sure that Maven is not a lot better than SBT.


#8

sbt is a bit easier to get going with 0.13 and then with 1.0.x

Maybe way easier. But the real reason to use sbt is that it is possible, not easy and not hard , to build little programs that run in sbt to give great extra functionality. And there are a lot of great ones on Github! I use Scala-Forklift to manage database migrations that get totally crazy when handling legacy WTF stuff written 15 years ago for MySQL. It’s flexible and helps my data integrity.


#9

Mill and CBT may be what you are looking for. I use Mill for some simple projects. Just to test the waters. Seems much simpler that SBT.


#10

No – I still use the Scala-IDE (Eclipse) for my company, and now that’s I’m actually using IntelliJ on a daily basis for a client, I still like Eclipse better. That’s strictly personal preference, though: IntelliJ is missing one or two features that I routinely rely upon from Eclipse. But IntelliJ a powerful IDE, and the vast majority of Scala engineers prefer it.

As for Maven, though – as far as I can tell, it is preferred only in places that already use Maven heavily. I’ve talked to a number of folks who have used both Maven and sbt enough to understand both decently, and most come out preferring sbt for Scala projects. I think everybody agrees that it is complicated, and there are several efforts to come out with something that’s easier to use, but building is not a simple one-size-fits-all exercise, and sbt is pretty customized to the needs of Scala.

I really think you’re letting experience bias your opinions: you’re arguing against tools that you don’t know well yet. That’s natural, but it’s not exactly objective…


#11

Well Mill already has about double the stars of Cbt, even though its a much newer project. Li Haoyi seems to have the drive to really push Mill as well as the ability to produce code. So although sbt is the current default, my uneducated bet is that Mill will dethrone it, in the not two distant future.


#12

I think there’s a long road for us to all go before we know about that. sbt has a huge amount of inertia behind it, and that’s not a small consideration; also, they’ve recently put a lot of effort into improving sbt’s worst flaws.

That said, I don’t bet money against Haoyi – he’s got quite a track record for setting the standards. There’s a lot of excitement behind Mill, and it’s got a good architecture, so I think it has a solid chance…


#13

Just a personal opinion, but I prefer SBT’s complexity over the usage of xml files in Maven. XML just adds soooo much bloat and I just can’t stand looking at it all the time. Also a a new user to maven, I didn’t find it so much simpler than SBT. It had its own problems and difficulties. I mean just trying to figure out that a ‘plugin’ is actually built in into maven was really confusing. For simple project, I think SBT is great. At the same time, it can go over my head quite easily. I am looking forward to giving Mill a shot on a small personal project (single module, very few classes, but many dependencies).


#14

The reason I expect mill to become a much more prevalent build tool is not track record (though yes, Haoyi’s is great), but rather the extensive reasoning behind what makes a good build tool and a good API for users; and the fact that these points are pretty much all addressed in mill.

I expect inertia to keep sbt around for a good while, though, even if it doesn’t evolve in less-complex-seeming directions.


#15

The short answer is that in the build war with Scala, we are all losers.

However, I think the history of sbt is yet to be written. sbt 0.7 was the first Scala code I looked at. Someone recently quoted Martin that Scala didn’t want to fight the battle of := for assignment, so sbt undertook that skirmish and more on the symbolic front. sbt was never the build tool of choice, but the build tool by default. sbt stands for the single build tool we had at the time. It’s been the proving ground for various experiments or researches over its evolution, and there is no question that it has grown to support an amazing ecosystem. We heard the mustard seed parable on Sunday, where the birds of the air come and perch in its branches. Birds are capable of travelling great distances to their favored foraging spots. It says a lot that projects have stuck with sbt, and the investment in the run-up to version 1 has yielded fruit.

Of course, in our area, the beautiful yellow wild mustard plants across the hillside are an invasive species that is the target of eradication.

Personally, “Mill” makes me think of Blake’s “dark Satanic mills” or possibly “The Mill on the Floss,” nothing to do with dental floss. IIRC, the Floss floods.

In any case, the long answer is that in the build war, we are all winning.

Probably we should think not only in terms of polygot programming, but polytool building.

My Java friend made the unfortunate choice to switch to Gradle – I say unfortunate, but really I think he rather enjoyed complaining about the vagaries of dynamic programming in a build tool. It would have been nice if my sbt project could talk to his gradle project.


#16

Creating a build tool is a task that appears deceptively simple, but is incredibly hard. No single person’s imagination suffices to anticipate all the things people want to do with their build tool. To be successful, you have to keep adding features, including such that violate the original design vision.

While it is quite possible that some newer build tool is superior to SBT, I will not be impressed with any claims that one is easier to use until it has implemented at least half of the features of SBT.