Note that if you’re using Maven, bloop should already make your developer experience better via its Maven plugin. Repo is here, website with installation instructions and motivation is here.
At the risk of venturing into an un-mute-able eventual flame war, i’ll add:
I’m surprised that no one has brought up Bazel yet.
While it’s not in wide use currently, there’s some decent work being done by Oscar and friends to make it easier, and once this progresses a bit more, i think the benefits it provides could really become quite compelling.
2 Likes
I agree with you, bazel is really exciting. I hope that bloop will support it soon. In my opinion, it just still needs time and UX polish so that normal Scala developers that are not exposed to the scaling challenges of big companies consider using it.
There is a big misunderstanding of compatibility between SBT and major IDEs.
From theoretical view it is almost impossible to achieve such compatibility. SBT has a dynamic nature, it could be programmed in any desired way and switch dependencies and sources in each run. All IDEs has their own build format which is static: number of string properties specifies dependencies, sources and destinations.
So it should be expected that SBT is incompatible with both Idea and Eclispe in practice. IDE could not import SBT project if it is too simple (and use root folder to hold .Scala files) or if it is too complicated and has lot of dynamic content.
The issue could be solved with IDE discarding own static configuration format and using dynamic proxy. But they would never dare.
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
Repl is a bit complex for me i don`t know why 
I would always go for Scala !
Regards,
Adrian Gates
Developer - Apps4Rent
Could you summarize if we’re not able to watch the video?
You can read the motivation section in the bsp specification, hosted in the bsp repo linked above 
There’s also Fury to look out for.
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
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.
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.
Does make find and resolve dependencies?
You say that as though sbt is not mature and supported.
1 Like
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?
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.
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.)
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.
Of course you can write a make target that finds and resolves dependencies.
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.