10 ms·
What's wrong with the default build tool for Scala
- allengeorge 9y agoWell... * It's slow * There's little sense of its overall abstraction (or how the abstractions you find fit together) * Its configuration language is undecipherable (if you want to use operators liberally consider the hoops people who need to search up `<++=` have to go through) * It's hard to work through the documentation. I can't put my finger on it, but I think because the abstraction(s) are hazy it's hard to work out how the documentation fits together * Writing plugins is non-trivial * Speeding up compilation is a non-trivial exercise in futility * It's too clever by half... Did I mention it invokes the compiler on its own project definition? :)
- dtech 9y agoAll fairly reasonable critiques, but a few are actively being addressed or have been addressed > if you want to use operators liberally consider the hoops people who need to search up `<++=` have to go through To be fair, the SBT maintainers have realized this for a while and deprecated them all in 2013, and removed them in the 1.0 release from 2017. > Speeding up compilation is a non-trivial exercise in futility Do you mean for the developer? It's more of a critique of scala then of SBT, but incremental compilation has gotten a huge speed up in the new Zinc compiler of SBT 1.0, and Lightbend has started actively benchmarking and improving compiler speeds.
- aphexairlines 9y agoThe intro docs still mention some custom operators: := in http://www.scala-sbt.org/1.x/docs/Basic-Def.html http://www.scala-sbt.org/1.x/docs/Basic-Def.html / in http://www.scala-sbt.org/1.x/docs/Task-Graph.html http://www.scala-sbt.org/1.x/docs/Task-Graph.html % in http://www.scala-sbt.org/1.x/docs/Library-Dependencies.html http://www.scala-sbt.org/1.x/docs/Library-Dependencies.html %% in http://www.scala-sbt.org/1.x/docs/Library-Dependencies.html http://www.scala-sbt.org/1.x/docs/Library-Dependencies.html I don't know if they're useful or not, but they're there.
- vvillena 9y agoSome quick explanation: := is the standard SBT assignment operator. You see it everywhere, so its use is clear. / is used for directory traversal. This is not SBT-specific, it comes from the File class in the Scala standard library. This is not as common, but it is sometimes used to setup custom source directories. % and %% are used all the time for declaring dependencies. % is the standard separator, and %% is used to automatically choose the library version compatible with the Scala version used in the project. There is also %%%, used in ScalaJS. You can use only % if you want to, the only thing the other two do is add a suffix to the dependency name. So yeah, useful. Still, they could probably have done without these custom symbols.
- gcb0 9y agonever understood why people didn't just used maven/ant. sbt should never have been more than a config-file-compiler to some subset of the above.
- moxious 9y agoPlenty of people do use maven, but there's a lot of power in being the assumed popular option, which sbt is.
- rtb 9y agoMaven is no longer maintained, and has many long-standing bugs that may never get fixed.
- vasachi 9y agoWhat? I thought it was _the_ java build tool...
- grouchoboy 9y agoThis mirrored repo https://github.com/apache/maven https://github.com/apache/maven says that the last commit was five days ago. So would not say that is no longer maintained.
- solatic 9y agoI wouldn't go so far as rbt to say that it's unmaintained, but the development attitude is that of maintenance (features like Java 9 modules compatibility) rather than active development. Gradle has improved by leaps and bounds very quickly; the Gradle build daemon makes build tasks feel much quicker and powerful in day-to-day practice, and is clearly now the preferred tool for new projects.
- cryptos 9y agoWhy does the Scala community needs its own build tool? Why not just use Gradle? Or if something is missing, adding this to Gradle and then using Gradle.
- dtech 9y agoYou can build Scala projects with Ant, Maven and Gradle, but for some reason, a language community often gravitates toward the language-specific tools.
- RX14 9y agoConsidering gradle is heavilly used in Java, kotlin, (and groovy) while it's DSL is in groovy (while the back end is largely Java these days), that's not always true.
- jurip 9y agoIt's possible that back in 2008 Gradle did not seem like an obvious choice (assuming it is now; I have no experience with it.) And after a community has effectively standardised on a tool, switching to something else isn't done lightly.
- cryptos 9y agoBut if SBT is at a point where a (more or less) complete rewrite is discussed, it is probably the time to think about Gradle a second time. Even the new Kotlin DSL should look familiar to Scala devs.
- aphexairlines 9y agoThe Scala community provides Gradle plugins for scala itself (through zinc), scoverage, scalastyle, scalafmt, wartremover, scala protobuf integration, and scala-aware intellij project generation from your build.gradle. It works well.
- vvillena 9y agoSBT ended up winning due to build plugins and cross compilation between multiple Scala versions.
- js8 9y agoI wish there was some attempt to standardize the build tools for different languages. Every language today has its own, it's crazy. At least makers of the make understood this.
- pathsjs 9y agoUsually it is because as soon as the build gets a little complex, you need to define your own logic. In a minute, you are scripting your build tool with a Turing complete language. And of course users of language X want to script their build using X. That just makes sense - define a build DSL inside your own language. For some reasons, though, the de facto build DSL used by Scala suffers by all the issues mentioned by Li Haoyi in his blog post
- wink 9y agoOf course it will be hard, but most build tools often do the same thing - no matter the language or ecosystem. I haven't seen any real effort to try to standardize on APIs, so you could write your "plugins" in your language of choice and the "glue" code would be this language-independent build tool. I'd say I've mostly given up on this. I have a Makefile for every project, which in turn of course uses the language-specific build tool, but for example when I wanted to use webpack (migrating from a mess of gulp+bower+npm from angular.js to just webpack for angular) I wrote a simple PoC Makefile with hacky sed-/awk-/lines and a lot of cp and cat in just a few hours (massive build script). Then the result was working as intended and I could refactor all the stuff where there's a nice webpack plugin and get rid of my Makefile hacks. Now in the end the Makefile just provides a common starting point that has "executable docs" for every language specific tool. "make bootstrap/test/run/build", no matter what language the project is in - for the low cost of having to update the Makefile when you change something major or some arguments. Not advocating this for all orgs (please use what makes YOUR team happy) but I've heard nothing but positive things about this from my team.
- Someone 9y agohttps://github.com/apple/swift-llbuild https://github.com/apple/swift-llbuild may be too low-level for what you envision, but captures a lot of your ideas, I think. https://llvm.org/devmtg/2016-11/#abstracts https://llvm.org/devmtg/2016-11/#abstracts has a presentation. It focuses on compiling with clang, but the system is more flexible. Slides at https://llvm.org/devmtg/2016-11/Slides/Dunbar-NewArchitectureForBuildingSoftware.pdf https://llvm.org/devmtg/2016-11/Slides/Dunbar-NewArchitectur..., matching video is at https://youtu.be/b_T-eCToX1I https://youtu.be/b_T-eCToX1I.
- danielbarla 9y agoIt's interesting that Martin Odersky (creator of Scala, and possibly also involved in SBT) responded in agreement, linking his own critique from several years ago.
- allengeorge 9y agoI found Odersky's comments and concern less useful than Li Haoyi's. Li's focused on the unclear - and broken - abstractions, while Odersky's seemed to focus more on the misapplication of language features. Am I reading this incorrectly?
- danielbarla 9y agoI think that's probably a fair comment (from my admittedly somewhat limited understanding). That said, both do seem to share a drive for simplicity and clarity at their core, and Li Haoyi's post does have the advantage of another 6 years of insight / subsequent changes to SBT.
- gmartres 9y ago> creator of Scala, and possibly also involved in SBT Martin has never worked on sbt. sbt started as a community project and is now maintained by Lightbend, which Martin co-founded.
- tekacs 9y agoFor those fed up of SBT, it's worth taking a look at CBT [0], which is an attempt to do this job more simply and intuitively using plain Scala code (no affiliation). [0]: https://github.com/cvogt/cbt https://github.com/cvogt/cbt
- pandemic_region 9y ago* totally unusable behind an authenticating proxy (even though they claim it works)
- CannisterFlux 9y agoOne solution I've used for an uncooperative proxy is to put my own proxy in front of it. Then I connect the tool to my proxy, which sets things up nicely for the real external-facing proxy. I've used privoxy for this, it's pretty easy to set up. Here's a post from some dude explaining what you might need to do: https://siderite.blogspot.com/2014/02/using-prixovy-to-forward-to.html https://siderite.blogspot.com/2014/02/using-prixovy-to-forwa...
- dullgiulio 9y ago"It looks like something the germans would have come up with... 70 yrs ago... in a submarine." Noting this down for random usages. Very clever.
- Tinyyy 9y agoAs an interesting side note, Li Haoyi is the son of Singapore’s prime minister Lee Hsien Loong.
- virtualwhys 9y agoInteresting indeed. Question: why would he not share the same family name? Completely ignorant here, is there no connection between childrens' names and that of their parents?
- tel 9y agoLee and Li are probably the same word, transliterated to English characters differently.
- emodendroket 9y agoYes, specifically, 李, which, at least if you count Korean variants "Ri/Rhee" and "I" and Cantonese "Lei," is the world's most common surname.
- deleted 9y ago[deleted]
- hardlianotion 9y agoInteresting. Very talented family.
- Cyph0n 9y agoI've been following his work for quite a while and never knew that!
- theCodeStig 9y agoThis is a topic that comes up on occasion in the engineering circles in Singapore. My guess, is that he'd rather be known for his engineering merit.
- vvillena 9y ago
- Fiahil 9y agoI had an interesting conversation once, in a Scala meetup. I was talking with someone about SBT being a gigantic pain in the ass, and their faire point was "I like SBT, it's better than Maven !". While SBT might be better than Maven for the long Scala compilation time, it's nowhere near the user-friendliness of more recent build tools in languages like Go, Rust, Javascript, or [put your favorite lang here]. It strike me how close the Scala community is to Java's.
- merb 9y agowhich build tool does go have? or JavaScript? Rust, yes. but the others are more glue than a real build tool. (and npm + gulp, grunt, webpack, browserify or whatever is way more painful than sbt, besides that there are better alternatives too all).
- camus2 9y agoGo doesn't have a build tool like SBT or Gradle, it doesn't even have an official package manager. Go has a compiler and that's all. You could argue Go is easier to build that Java, but it's because makes a lot of assumptions about how you organize your code on your HD which can be a hindrance if it doesn't fit the way your company operates. As always, Go is simple for simple use cases and get complicates as soon as you try straying from what go developers decided for you, there is no flexibility with that language. Javascript has tons of build tools that are all clunky and horrible to use.
- eip 9y ago+"I like SBT, it's better than Maven !"+ That's debatable.
- suls 9y agoIt is funny he mentiones Bazel in the article but some doesn’t consider Pants [1] at all. For me, not just in a work context, Pants is a clear winner. Most SBT project already have a bit of mono-repo flavour: main and sub-projects. Pants brings this to the next level and and speed and other goodies on top of it. Also, a lot of CI thinking has been put into the tool already so it’s a breeze to distribute the build across n shards .. [1] https://www.pantsbuild.org/scala.html https://www.pantsbuild.org/scala.html
- aphexairlines 9y agoDo you mean Pants is a clear winner compared to SBT, or compared to Bazel and Buck?
- suls 9y agoCompared to SBT. Last time I checked Scala support in both Buck and Bazel was very basic at best.
- ninjakeyboard 9y agoMostly it's slow. Otherwise it's okay.
- znpy 9y agoIt's nice to see how the bad things about the Scala ecosystem are finally getting out now that the hype is vanishing.
- Pelam 9y agoI've been happy Scala and Gradle user for years now and it keeps getting better. Also tooling works like a charm with IntelliJ first class support for Gradle. IMHO Gradle is in a sweet spot of making simple things really simple and not making complex things (integrating native, custom plugins, multi project, Java interop) unnecessarily complex. Also Gradle has been getting faster and more user friendly every release. I have been trying to gather motivation to tip my toe in SBT but without success. /fanboypost