Jon Pretty

I find it amazing how skeptical scala devs are of source deps, but rust, haskell and many other communities seem to use them just fine.

I’m pretty much on board, but it’s important to be precise. Publishing will not go away unless you’re working in a silo company that has no need to share artifacts with the rest of the world (which is pretty exceptional).

I don't think so. Builds are usually simple. I think we could easily design a standard way to describe dependencies and compilation flags other than sharing compiler output. Approximately zero effort has been expended on this compared to the effort on sharing binary artifacts.

I challenge your assumption that builds are simple. Builds are incredibly complicated, especially in the Scala world, because we’re used to move all the infrastructure/checks/release management to the build tool side. This doesn’t happen in other communities, but it does in ours.

Builds are simple in the bazel and pants world, sure, but migrating from a complex build to a simple one takes not only time but expertise that people don’t usually have.

I think it can be done mostly with tooling. Build should be about expressing dependencies and the options to the compiler to build the code. End of story. All the other scripting that has been tacked on is not good design in my view. We need to factor the build problem out.

I agree on the factoring but precisely because tools like bazel have such a generic purpose build graph they will become beasts at the end that will do everything. So I’m not sure we’re headed to that refactoring you mention. The only novel thing is that removing binaries...

...actually removes a lots of complexity of the core of the build tool. But that’s pretty much it, everything else stays.