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:
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?
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/
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.
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.
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.
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.
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.
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.
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.
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âŠ
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.
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âŠ
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).
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.
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.
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.
Interesting story about gradle. I was learning it at one point and had gotten pretty good at using it in the Java World. Then management hired a new architect because the previous architect that had created all the grable build scripts quit. The new architect only knew maven. He toiled over the gradle build scripts for a couple of months before he became totally frustrated , threw his hands up and said he would have to quit unless they allowed him to recreate everything using Maven, what he claimed to be the Industry Standard. I was totally against the move to maven since I had spent the summer learning Gradle. But it is what it is. In the world of big companies and their technical environments there are always winners and losers. It really boils down to how much leverage you bring to the table.
I use both the Intellij IDEA and Scala IDE for Eclipse. They have different advantages and disadvantages.
Since SBT is the most established project structure, it is best to construct the Scala projects with SBT (or its new rival called Mill which should work with Intellij IDEA). But note that the Intellij IDEA can create your SBT projects from scratch, and you do NOT need to understand the details of SBT at all, you just need to know a few commands if you want to execute the program later either from SBT or from direct Scala. (Sometimes executing a memory-intensive program from within the Intellij IDEA seems to take too much time, and it can crash if you have not allocated enough memory, and so you might be forced to use less data to run the code from inside the IDE, meaning that after you run the program from inside the IDE, you can then use the console or the GUI to run it with large data. )
The best property that the Scala IDE for Eclipse has is that the âWorksheetâ feature is FAR superior to Intellij IDEA. I am convinced that the best training to learn how to take advantage of the Worksheet capabilities of these two IDEs is to take Martin Oderskyâs course at Coursera, about Scala Functional Programming. In this online course, Martin Odersky teaches everything by actually writing and testing code segments with the Worksheet feature, and he uses the Scala Eclipse IDE for the Worksheet. When I took this course from the creator of Scala, I was instantly converted to the Scala religion. I have C++ programs with thousands of lines of code, and I am migrating to Scala, but this is in no small part thanks to the IDE that made it much easier to write and debug code.
But let me warn you that one thing the Eclipse IDE cannot do is to create an SBT project like Intellij IDEA does. To be exact, there is an Eclipse plugin that allows you to open an SBT project from Eclipse, but when you launch Eclipse you cannot crate a new SBT project. This is a serious disadvantage of Eclipse.
On the other hand, the Scala Worksheet feature of Intellij IDEA is not anywhere near as great as the Eclipse version of Worksheet. With the Eclipse version of Worksheet, you can actually build, debug and test every line of code with astounding clarity. I would NOT have passed Martin Oderskyâs course without the Worksheet of Eclipse!
In this course, although I was writing and testing my code with the Eclipse Worksheet, I was building the SBT project with IntelliJ IDEA, which is simply the most user-friendly and helpful invention in the world. Just copy and paste your code segments from the Eclipse Worksheet into your Scala files in the Intellij IDEA environment, and this strategy is just great. When I am too lazy to launch and use Eclipse together with Intellij IDEA, sometimes I simply use the Worksheet of IDEA directly, but it just does not give as much information when you are trying to understand why you have a syntax or type error. When you have complicated data structures, the Eclipse Worksheet is far superior for understanding what must be done.
The Coursera sequence has 5 semesters, but I have completed only the first semester, although I am planning to complete the rest later:
At the beginning of this course, there are detailed instructions to install everything to use Eclipse and Intellij IDEA.
But to summarize, Intellij IDEA has the best capabilities to organize a project, and it just âworksâ even when you donât understand anything. And for the Worksheet you can use the Eclipse while you are writing code segments and functions.
Actually, full disclosure, this week I spent time with Groovy and Gradle. I resolved to stop complaining and just get stuff done. Also, upgrade to latest versions of stuff to benefit from the hard work of many other people. We needed to unify a couple of projects, and I had a Scala build to sneak in. Also, GStrings make me want to revive my prefixless interpolator, was it called the applicator? something like that, apply"$x". Maybe appolator? Hopefully I wrote it down on the PR. Thatâs why I canât really support the initiative for s"$"" quoting, it looks like something people will make fun of. And I still love bell bottoms.
I understand not wanting to learn something different, thatâs what I get at work. But obviously maven is not inherently superior to gradle by any stretch. I spent a few weeks at a previous job upgrading several project builds to maven, getting yelled at because build work is thankless. I never loved maven, but I was amazed that it survived version one because the need for some kind of solution was so great. Even in the face of real need, no one says thanks, I really needed that.
Unless a technological choice will actually kill an initiative, now I think that itâs more useful to be maximally polyglot and be exposed to many tools and idioms, so that we turn out smarter and better informed.
To be fair, Jesus writing in the sand is more compelling than Euclid.
Iâm sorry Martin Odersky doesnât use the REPL, or an equivalent like tut or that live REPL slide show.