[HN Gopher] Why does Mill use Scala?
___________________________________________________________________
Why does Mill use Scala?
Author : lihaoyi
Score : 46 points
Date : 2025-02-10 06:28 UTC (3 days ago)
(HTM) web link (mill-build.org)
(TXT) w3m dump (mill-build.org)
| koito17 wrote:
| 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.
| fmbb wrote:
| What is special in starlark that makes it hermetic and
| deterministic?
|
| Scala is deterministic.
|
| If you call functions that have side effects and
| nondeterministic behavior you can fall outside the comforts of
| determinism. But you can stumble upon library functions someone
| wrote in Starlark that accidentally put you there as well.
|
| The Starlark homepage says
|
| > Hermetic execution - Execution cannot access the file system,
| network, system clock. It is safe to execute untrusted code.
|
| But the last time I wrote Starlark it was to define build
| targets in Basel. And executing the builds definitely accessed
| my file system and the network, otherwise builds would have no
| results.
| cbeach wrote:
| Bazel enforces a hermetic sandbox for Starlark to operate
| within.
|
| All input files have to be declared, and the build process
| can only see files that are declared.
|
| Starlark cannot access arbitrary files at runtime, and it
| deliberately has no APIs for things like system time or
| random number generation, or global state.
|
| Scala, on the other hand, has no such restrictions. As much
| as I love Scala, I think it's an odd choice for a pure,
| deterministic system. Although perhaps if you use Scala to
| build a DSL (an area where Scala shines) you could engineer a
| pure functional sandbox within Scala.
| michaelmior wrote:
| > Scala is deterministic.
|
| I don't see how Scala is any more deterministic than any
| other language.
| toprerules wrote:
| 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.
| MathMonkeyMan wrote:
| This does work well. A team I was on at a past job did exactly
| this. On Unix the service literally ran `std::system("python
| config.py >config.json")` on startup.
|
| The problem with this is that the answer to the question "what
| kind of configuration can I expect?" is "simulate the script
| and find out."
|
| If the script is written well, and is short, then the
| parameters that are filled in by the runtime environment are
| apparent. Over time, though, there is a risk that the script
| will not remain written well, and it almost certainly won't
| remain short.
| threeseed wrote:
| > Everyone knows Python
|
| No they don't. Just like everyone doesn't know Cobol, Fortran,
| Scala etc.
|
| But by having a programming language as your build tool you now
| make it harder for new people to onboard. As in order to build
| project they often need to some unique, specific to the
| language syntax. And in order to find this syntax they look
| around on Github and because it's a programming language
| _every_ project has their own unique, specific to the project
| approach.
|
| Versus something like Cargo.toml where it's simple and
| consistent regardless of which project you look at.
| wocram wrote:
| I think it's hard to argue that Cargo.toml is any simpler
| than Python. Json might be ubiquitous enough for anyone to
| read and understand, but if Python is foreign than toml is no
| better.
| emidln wrote:
| > No they don't. Just like everyone doesn't know Cobol,
| Fortran, Scala etc.
|
| Sure somebody might not have Python experience, but it's
| pretty easy to just not hire someone who says they don't know
| Python and isn't willing to learn for the role. I don't know
| that you'd filter out many candidates out of any random 100
| devs.
| eptcyka wrote:
| Ah yes, the age old belief that all software is complex enough
| that one _must_ first run some other bespoke turing complete
| program to build every single piece of software.
|
| And of all the languages to pick for this, python, with it's
| non-hermetic execution environment is bound to bite you in the
| ass, once your buildscripts start depending on _libraries_. Oh,
| you could use _poetry_ to solve the library issue with python,
| or maybe it 'll be setuptools, pip or whatever is the flavour
| of the month in python packaging.
|
| After fighting with Nix for a sufficiently long time, I think
| most language specific build tools are not neccesarily the best
| solution to the problem of automating a build for bit of
| software written in language X. Complex projects will
| eventually evolve to depend on multiple languages (unless
| you're the Linux kernel), at which point the specialized
| language build tools turn into cumbersome barriers in the build
| process, where different build tools are not aware of the
| caching, conventions and configurations of any other tool. As
| such, in an ideal world, any new language would come with a
| compiler or bundler that can be supported well by higher level
| build/packaging tools. And bespoke python scripts ain't that.
| aidenn0 wrote:
| I don't know about Python specifically, but using a language
| I'm familiar with to generate ninja files (+ any
| header/environment/&c) for the build has become my go-to way of
| doing builds in the past 18 months or so.
| IshKebab wrote:
| Python is a terrible choice for that sort of thing. Who really
| wants to have to set up a venv and deal with pip nonsense just
| to write a config file? Hell even installing Python is
| sometimes difficult.
| agentultra wrote:
| 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.
| vander_elst wrote:
| It seems this is mainly a scala project and then they are using
| scala also for the configuration, it probably makes sense for
| them.
| kunley wrote:
| "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.
| wavemode wrote:
| What does it even mean to "build" Python?
| Kwpolska wrote:
| Because it's a Scala project, written by a Scala fan, simple as
| that. No need to come up with extra justification.
___________________________________________________________________
(page generated 2025-02-13 23:00 UTC)