3 ms·

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 declar

by cbeach 2y ago

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.

fmbb 2y ago
Do you only declare the file names, or also file content and owner and group and everything up front? Sure it deliberately has a bunch of restrictions in its base form. But in order to use it for anything you have to write custom actions or download and execute custom actions others wrote. And this will mutate your file system and run arbitrary executables.
- winwang 2y ago
  As someone who worked a bit with Bazel actions and uses Scala: I think Bazel cuts down on the area where arbitrary I/O happens. Also, many executables come from pre-defined targets (e.g. java toolchains). One way to deal with I/O is if Mill injected its own implementation of a JVM filesystem/network layer, which I'm pretty sure it can do.
- recursivecaveat 2y ago
  Input and output files are tracked determistically via content hashing. It cannot reach outside of its sandbox and touch the network or actual filesystem. Those are all (generally pinned) inputs to the system. For a given version of a script and a tuple of input content hashes, you get the exact same output files every time. No way to accidentally iterate over a hashmap, embed a timestamp, or leave the filesystem in a weird state because you were interrupted.

3 ms·

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 declar

by cbeach 2y ago

fmbb 2y ago
Do you only declare the file names, or also file content and owner and group and everything up front? Sure it deliberately has a bunch of restrictions in its base form. But in order to use it for anything you have to write custom actions or download and execute custom actions others wrote. And this will mutate your file system and run arbitrary executables.
- winwang 2y ago
  As someone who worked a bit with Bazel actions and uses Scala: I think Bazel cuts down on the area where arbitrary I/O happens. Also, many executables come from pre-defined targets (e.g. java toolchains). One way to deal with I/O is if Mill injected its own implementation of a JVM filesystem/network layer, which I'm pretty sure it can do.
- recursivecaveat 2y ago
  Input and output files are tracked determistically via content hashing. It cannot reach outside of its sandbox and touch the network or actual filesystem. Those are all (generally pinned) inputs to the system. For a given version of a script and a tuple of input content hashes, you get the exact same output files every time. No way to accidentally iterate over a hashmap, embed a timestamp, or leave the filesystem in a weird state because you were interrupted.