
What's wrong with the default build tool for Scala - nuriaion
http://www.lihaoyi.com/post/SowhatswrongwithSBT.html
======
allengeorge
Well...

* 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
All 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
The 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
Some 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.

------
js8
I 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
Usually 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

~~~
js8
I am not sure if build scripts really need to be Turing complete. Wouldn't
something like Dhall be appropriate?

~~~
crdoconnor
I am. I need turing complete code to build stuff very regularly.

I'd rather we aimed to make build scripts that are turing complete and as
short and simple as possible rather than non-turing complete.

~~~
Someone
Can you explain what you do that requires a Turing complete build language and
couldn’t be done, for example, in the ‘make equivalent’ of the dtrace
scripting language?

~~~
crdoconnor
* Checking some condition before building something in a particular way.

* Retrying something if it fails.

* A hundred other different scenarios which crop up occasionally, require about 4 lines of turing complete code, and are an absolute bitch to handle in a language deliberately designed not to make it possible.

~~~
Someone
Ability to do _if…else_ doesn’t imply being Turing complete. Neither does the
ability to retry operations.

An easy way to see that is that “Turing complete” implies “can be used to
simulate any Turing machine”, which in turn implies “suffers from the halting
problem”. Consequently, any language that doesn’t suffer from the halting
problem cannot be Turing complete.

So, for example, any language that doesn’t allow backwards jumps, or only uses
loops with numbers of iterations that are provably finite at compile time
isn’t Turing complete.

~~~
crdoconnor
It actually does imply turing completeness, it just doesn't guarantee it. I
know of no build language that builds in the ability to do conditionals and
loops that isn't turing complete. At that point... why bother? Why not just
use a _good_ turing complete language and give it some libraries that make
building software easier?

There's a lot of times and places where removing turing completeness makes
complete sense - configuration, user stories, translation files and simple
DSLs that operate in a very restricted problem space, etc. Building software
_isn 't_ a restricted problem space.

~~~
Someone
Because those complete languages _are_ Turing complete. That means, for
example, that the build system cannot guarantee that a build will finish, even
ignoring that individual steps may run forever.

Some argue Dtrace’s scripting language and PDF (and, IIRC, various packet
filter languages) are popular because they aren’t Turing complete.

~~~
crdoconnor
>That means, for example, that the build system cannot guarantee that a build
will finish

That's impossible anyway because one of the plugins or the core build code may
never halt.

Abandoning turing completeness shouldn't be about that anyway. It should be
done because it's demonstrably not needed to solve a problem.

------
tekacs
For 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)

------
danielbarla
It'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
I 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
I 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.

------
Fiahil
I 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.

~~~
camus2
Go 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.

------
suls
It 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
Do you mean Pants is a clear winner compared to SBT, or compared to Bazel and
Buck?

~~~
suls
Compared to SBT. Last time I checked Scala support in both Buck and Bazel was
very basic at best.

------
cryptos
Why 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
You can build Scala projects with Ant, Maven and Gradle, but for some reason,
a language community often gravitates toward the language-specific tools.

~~~
RX14
Considering 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.

------
dullgiulio
"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.

------
Pelam
I'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

------
znpy
It's nice to see how the bad things about the Scala ecosystem are finally
getting out now that the hype is vanishing.

------
pandemic_region
* totally unusable behind an authenticating proxy (even though they claim it works)

~~~
CannisterFlux
One 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-
forwa...](https://siderite.blogspot.com/2014/02/using-prixovy-to-forward-
to.html)

------
gcb0
never 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.

~~~
rtb
Maven is no longer maintained, and has many long-standing bugs that may never
get fixed.

~~~
vasachi
What? I thought it was _the_ java build tool...

~~~
oblio
It is. It doesn't even need to be updated that often as most of the
functionality is in plugins. A large set of which are maintained by the core
development team.

------
ninjakeyboard
Mostly it's slow. Otherwise it's okay.

------
Tinyyy
As an interesting side note, Li Haoyi is the son of Singapore’s prime minister
Lee Hsien Loong.

~~~
virtualwhys
Interesting 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
Lee and Li are probably the same word, transliterated to English characters
differently.

~~~
emodendroket
Yes, specifically, 李, which, at least if you count Korean variants "Ri/Rhee"
and "I" and Cantonese "Lei," is the world's most common surname.

