from Hacker News

Why does Mill use Scala?

by lihaoyi on 2/10/25, 6:28 AM with 75 comments

  • by toprerules on 2/13/25, 9:00 PM

    The best config system I've ever seen used plain old Python to generate static configs. Everyone knows Python. Python is easy to do data munging in, as demonstrated by it's popularity as the #1 data science tool. There's boundless libraries to make Python more functional, use stricter typing, or reduce the amount of side effects it can cause. Even Starlark is just a dialect of Python.

    You can spend decades building a complicated configuration language, use a bespoke functional language as Mill does, but if you're a single company that can enforce code quality and just wants to get the job done, I feel like everything else is just unnecessary and over-engineered to scratch some academic itch for a "better system" that enforces "purity" at the cost of velocity.

    I also think that now that LLMs are on the rage, how much context do you think they have for bespoke config language vs Scala vs Python? I think we know the answer to that one.

  • by koito17 on 2/13/25, 9:00 PM

    The article fails to mention whether Scala can ensure code is deterministic and hermetic. Starlark code is deterministic and hermetic, but the article never mentions this. Unfortunately, Starlark does not have static typing, but I think types would make Starlark one of the best languages today for build configuration.

    In the Clojure community, there was a huge push for "builds are programs". I somewhat agree with this assertion, but I also think "one should restrict the class of programs a build belongs to". Neither Clojure nor Scala, compared to Starlark, seem to offer a way to ensure builds belong to a deterministic subset of programs.

    Thus I am still wondering "why Scala?". I have never used Scala, but reading this whole article gives me the impression that Mill is the Scala equivalent of Clojure's tools.build. That is not what I would want in a build system.

  • by Kwpolska on 2/13/25, 10:31 PM

    Because it’s a Scala project, written by a Scala fan, simple as that. No need to come up with extra justification.

  • by kunley on 2/13/25, 10:21 PM

    "Mill is a fast, scalable, multi-language build tool that supports Java, Scala, Kotlin, and Python".

    So, while I understand this tool can resonate in the JVM world, I have no idea why one would want to pull Java into their toolset in order to build Python.

  • by vander_elst on 2/13/25, 9:49 PM

    It seems this is mainly a scala project and then they are using scala also for the configuration, it probably makes sense for them.

  • by rpcope1 on 2/13/25, 11:07 PM

    One interesting thing is that there are comparisons to Maven and Gradle but not sbt. Do people just not use sbt anymore or is it omitted because it's also Scala and/or prone to becoming a mess?

  • by gdgghhhhh on 2/13/25, 11:05 PM

    The title really confused me until I realized this has nothing to do with https://millcomputing.com/ :-)

  • by ncgl on 2/16/25, 1:22 PM

    The first thing any self respecting python dev is going to do on a new repo is implement typechecking. And the second thing they're going to do is complain about pip/pyenv.

    These days I would trade my python experience for scala, even knowing it'd mean less job prospects. We make a lot of excuses for python.

  • by Lyngbakr on 2/13/25, 11:45 PM

    I'm surprised that Lua wasn't included in the discussion. I'm not saying they necessarily should have chosen to use it, but it's a notable omission given its popularity as a config language.

  • by rubenvanwyk on 2/15/25, 6:41 AM

    A lot of these reasons also apply to Kotlin and Kotlin is arguably simpler than Scala, why not just use Kotlin? It is much more widely adopted than Scala.

  • by agentultra on 2/13/25, 9:49 PM

    I'm not big on programming languages being used for configuration. It adds a lot of complexity and maintenance burden. Configurations are often read and your reader isn't a compiler but now they have to imagine what the final configuration state will be after evaluating the "program" that generates the configuration. I think plain old configuration languages are better, even if verbose, since the usual text-based tooling works quite well for managing, searching, etc.

    I use nix a lot and the main thing that bothers me about it is the language. People are quick to get clever with it. It becomes a morass of code that is difficult to read for anyone but experts and when it breaks and your not that expert... good luck fixing it.