Who is winning the build war with Scala So Far?

Question
26

To fix this problem in a generic way, we created bsp together with JetBrains https://github.com/scalacenter/bsp. I recommend you watch my talk with Justin at Scalasphere 2018 https://youtu.be/Ppj0EFns59M

1 Like
27

Repl is a bit complex for me i don`t know why :confused: I would always go for Scala !

Regards,
Adrian Gates
Developer - Apps4Rent

28

Could you summarize if we’re not able to watch the video?

30

You can read the motivation section in the bsp specification, hosted in the bsp repo linked above :slight_smile:

31

There’s also Fury to look out for.

32

I honestly don’t fully understand why Scala needs its own build tool when there are plenty of mature Java build tools out there with plenty of community and IDE support.

I learned and started using Scala 3 years ago in a mixed Java-Scala Maven project. The project was originally a Java-only project and over time introduced more and more Scala. Thing is, its build scripts were awful so at one point I decided to clean it up and move to Gradle. I thought about moving to SBT at the time, but given all the bad reviews and experiences I read about I decided not to go with it. I considered moving to CBT as well, but also decided not to mainly for the lack of maturity and IDE (IntelliJ) support.

The major advantage of Gradle and Maven is their interoperability with Java projects and their familiarity among Java developers. I believe that Scala is shooting itself in the leg by trying to reinvent development tools on its own (that goes for testing tools as well). I personally prefer Gradle over Maven mainly for the flexibility given to me with a real programming language and not just a fixed DSL (doesn’t really matter that it’s XML based). Even though I haven’t tried it (yet), I also understand that Gradle does allow for type-safe build scripts via its Kotlin DSL.

The problem with Gradle and Scala is that the integration is not so clear, but it is definitely possible to integrate them together (I’m working on a guide with a sample project for that). There are a few caveats still – like the lack of integration between Gradle and the current major version of the incremental compiler (sbt zinc) – but these could probably be resolved if the attention given to developing SBT would be directed at weaving Scala support into the Java build tools.

1 Like
33

I honestly don’t fully understand why Scala needs its own build tool

You hit the nail on the head. It doesn’t. You can use any build tool that’s not directly tied to a specific compiler.

That’s also not limited to Java build tools. make will work just fine as well, as will MS-Build.

Some people choose to use sbt over these alternatives.

34

That’s a straw-man argument. The choice was never between make, MSBuild, or sbt. The choice is between mature, supported build tools in the JVM ecosystem, or sbt.

35

Does make find and resolve dependencies?

36

You say that as though sbt is not mature and supported.

1 Like
37

Sbt recently reached 1.0 (within the past year or so I think?) and is supported and developed mostly by Lightbend (I think?). And Lightbend is more a JVM shop than a pure Scala shop. Not knocking them for that, it’s just a fact. It seems they intend to support all three of Maven, Gradle and sbt: https://twitter.com/ktosopl/status/1029006035124539393 rather than going all-in on sbt (which I applaud as a good strategy for them, but it means they have fewer resources to devote to it).

Gradle is at version 5+ and is supported and developed by Gradle Inc. You can actually pay them to exclusively develop new tooling for you, as LinkedIn did to build their Play applications: https://engineering.linkedin.com/blog/2018/07/how-we-improved-build-time-by-400-percent

Which one strikes you as relatively more mature and supported?

38

You really can’t make any claim whatsoever based on the evolution of version numbers of 2 unrelated projects. As far as I can tell Gradle is 1 year older than sbt. You can pay Lightbend for professional support for sbt.

39

Yes – and then 1.1, and 1.2 soon after that, with point releases better than monthly at the moment. I don’t really see how you can describe that as not being well-supported.

As for maturity, you’re over-interpreting the numbers. sbt was on 0.13 for a vastly long time – not because it was dead or anything, but just because they were too shy about declaring 1.0. In practice, it’s more mature than many projects on their 3.0 releases.

(Mind, there are valid complaints to be made about sbt. But I really don’t think this is one of them.)

40

Fair enough. I do like to think of their maturity and support in relative terms though, not absolute terms. It’s basic economic theory–specialize in the thing that you have a relative advantage in, to maximize the outcomes for the ecosystem as a whole.

41

Of course you can write a make target that finds and resolves dependencies.

42

Paying for professional support for a “build” tool? That in itself is a BIG red flag. I only use maven for building Scala Projects so far ( in my beginner days of learning Scala. ) I have glanced at an SBT config file occasionally out of curiosity. As I progress in Scala, the SBT build file is starting to look easy to understand. However, I still wonder why anyone would use it since Maven does the job for the most part … er … so far anyway. I guess I will eventually take a closer look at SBT. If you come from a strickly java background in an Enterprise environment where Maven is practically everywhere , it is very problematic to embrace a new build tool; it adds hours of time to your effort. And usually you will come up against great resistance to adopting a new build tool.

43

You don’t need to pay for professional support for sbt any more than you do for maven or gradle. If you work at a company where having that kind of help and assurance is comforting / worth the cost, it’s available. If you want your own engineers to handle it, that works too.

As @jducoeur said, there are valid criticisms of sbt, but these aren’t the right ones. “sbt isn’t maven” is true, and maven is more widespread, but also “Scala isn’t Java”, and similar arguments apply. There are often considerable benefits to using sbt over maven. If you don’t want those benefits you can use maven anyway, but don’t begrudge people who do want those benefits the possibility of having them! (Why use maven instead of ant, anyway? Why ant instead of make? At some point, the former tool was less well established than the latter.)

44

If SBT started to build things other than Scala, it might have a fighting chance to be widely accepted and even replace Maven. But I do not thing SBT is being targeted to other programming languages. That being the case, more than likely it will be difficult for SBT to ever be widely accepted.

45

If you build with Maven, are happy about building with Maven, and don’t want to stop building with Maven, I don’t see the problem: keep doing that.

If you build with sbt, but are unhappy about building with sbt, and would rather build with Maven, the solution seems simple: build with Maven instead.

46

@Jasper-M @jducoeur @Ichoran

Comparing SBT’s maturity and community to its alternatives includes the following:

Adopting SBT as the main build tool in the Scala community – that means both community focus and the efforts of the core contributors – shifts the attention from the already existing and quite viable tools out there - and for what reason?

I do not see any major advantage of SBT in comparison to its alternatives. All it does in my opinion is splitting the community and making it much harder for others adopt Scala, especially those who come from the Java world.

SBT’s incremental compiler – Zinc – is a different manner and really has no alternative. It’s not suprising that the SBT team decided to extract it from the main SBT repository into its own repository.

2 Likes