4 ms·

no no no no no. Bazel has a some nice ideas, but has shat in my cornflakes too many times. It's really unusable for anything that isn't an all-inclusive monore

no no no no no. Bazel has a some nice ideas, but has shat in my cornflakes too many times. It's really unusable for anything that isn't an all-inclusive monorepo. It's funny because we with Nixpkgs want to be all-inclusive too, except we don't think that requires vendoring the world / perfect synchronicity.

klodolph 6y ago
Nix and Bazel solve different problems. I'm not sure exactly what you mean by synchronicity, but that's basically how e.g. package-lock.json works... it's the direction that everything is moving in, and Bazel is a target because it's imposing this on new frontiers rather than just being a new language where "things work that way".
- Ericson2314 6y ago
  > Nix and Bazel solve different problems. I think both sides want to erase that difference, and I commend them for it. > I'm not sure exactly what you mean by synchronicity, but that's basically how e.g. package-lock.json works... it's the direction that everything is moving in, and Bazel is a target because it's imposing this on new frontiers rather than just being a new language where "things work that way". package-lock.json stuff is fine, and Nix has long required that everything be locked. That is the good synchronicity: it's OK if upstream moves faster, downstream catches up and just pins whatever they are using. You can see how upgrade waves cascade downstream, this is because the sychronizing is local. The internal good model is everything just lives in one repro and must update all at once. This is global synchronicity. ---- It's a lot like 1 giant lock vs Multiversion concurrency control. The MVCC aspect is that there may be a few versions in flight as things cascade down, but old versions should be retired (like committed transactions) as new ones come. The consistency is basically the pinning; nevermind what other transactions/development is going one elsewhere, each package sees a consistent view as structured by the pins. If you go listen to Google people talk about dependency/version management. It's like they think it's global lock vs inconsistency. Monorepo or chaos. This false choice irks me. I guess their dev tools people should talk to their DB people?
  - klodolph 6y ago
    > If you go listen to Google people talk about dependency/version management. It's like they think it's global lock vs inconsistency. Monorepo or chaos. This false choice irks me. I watched this talk: https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI I’d say this is a much more nuanced look at dependencies & versioning. We all know these days that something like semantic versioning is not enough, because it is too easy to depend on behavior which the developers of your dependencies did not expect you to depend on. So you need something more powerful than just having a bunch of developers get together and agree not to break each others’ code. Bazel is a part of that solution—if you can analyze and understand the dependencies in a project, and do so in a very automatic and reliable way, you can provide people with tools tools for updating downstream code when upstream code changes. I think people are focusing too much on Bazel as only a build system and not as part of a platform for building developer tooling, and people are focusing too much on Bazel’s original incarnation as a build system for a massive monorepo. I think there’s also a reality that we must deal with that is—as software gets larger and more complex, and as we have more dependencies, relying on version pinning for stability is losing ground as a technique for making our software more reliable. We have many more dependencies in our software now, so just subscribing to a mail feed of all of the version bumps in the libraries you use would be enough to drown you, and the longer you stay on older versions the more painful it can be to upgrade.
amscanne 6y ago
Care to elaborate? Bazel doesn’t require vendoring the world, and I don’t understand the connection to Nixpkgs.
- Ericson2314 6y ago
  My bad experiences have been trying to package bazel and bazel-built things in Nixpkgs. Bazel and Nix both want to control everything...and it gets ugly. Nix is pretty wall layered, and while it has plenty of UX problems, it's quite easy to predict what it will do. Bazel has the classic problem of new well-funded software of being more polished than architected, and so feels like working with an amorphous blob where all that polish turns on you when you do something weird and now it oozes unforeseen complexity and interactions.
  - amscanne 6y ago
    I’m interested in the specific issues you hit, not just additional metaphors. Bazel, while there’s a learning curve, exists to provide hermetic builds, so I’m surprised that “what it will do” is not predictable.
    - aidenn0 6y ago
      I ran into an issue where bazel broke things pretty badly. Turns out that bazel does PID namespacing, and the build scripts assumed that no two programs with the same PID would share TMPDIR which caused some rather odd behaviors.
  - malkia 6y ago
    What does it mean by "bazel" wants to control everything? AFAIK, it simply needs ways to get to the source of another package - whether it's http_archive, or who knows what, and how to build it.

klodolph 6y ago

Nix and Bazel solve different problems. I'm not sure exactly what you mean by synchronicity, but that's basically how e.g. package-lock.json works... it's the direction that everything is moving in, and Bazel is a target because it's imposing this on new frontiers rather than just being a new language where "things work that way".

Ericson2314 6y ago
> Nix and Bazel solve different problems. I think both sides want to erase that difference, and I commend them for it. > I'm not sure exactly what you mean by synchronicity, but that's basically how e.g. package-lock.json works... it's the direction that everything is moving in, and Bazel is a target because it's imposing this on new frontiers rather than just being a new language where "things work that way". package-lock.json stuff is fine, and Nix has long required that everything be locked. That is the good synchronicity: it's OK if upstream moves faster, downstream catches up and just pins whatever they are using. You can see how upgrade waves cascade downstream, this is because the sychronizing is local. The internal good model is everything just lives in one repro and must update all at once. This is global synchronicity. ---- It's a lot like 1 giant lock vs Multiversion concurrency control. The MVCC aspect is that there may be a few versions in flight as things cascade down, but old versions should be retired (like committed transactions) as new ones come. The consistency is basically the pinning; nevermind what other transactions/development is going one elsewhere, each package sees a consistent view as structured by the pins. If you go listen to Google people talk about dependency/version management. It's like they think it's global lock vs inconsistency. Monorepo or chaos. This false choice irks me. I guess their dev tools people should talk to their DB people?
- klodolph 6y ago
  > If you go listen to Google people talk about dependency/version management. It's like they think it's global lock vs inconsistency. Monorepo or chaos. This false choice irks me. I watched this talk: https://www.youtube.com/watch?v=tISy7EJQPzI https://www.youtube.com/watch?v=tISy7EJQPzI I’d say this is a much more nuanced look at dependencies & versioning. We all know these days that something like semantic versioning is not enough, because it is too easy to depend on behavior which the developers of your dependencies did not expect you to depend on. So you need something more powerful than just having a bunch of developers get together and agree not to break each others’ code. Bazel is a part of that solution—if you can analyze and understand the dependencies in a project, and do so in a very automatic and reliable way, you can provide people with tools tools for updating downstream code when upstream code changes. I think people are focusing too much on Bazel as only a build system and not as part of a platform for building developer tooling, and people are focusing too much on Bazel’s original incarnation as a build system for a massive monorepo. I think there’s also a reality that we must deal with that is—as software gets larger and more complex, and as we have more dependencies, relying on version pinning for stability is losing ground as a technique for making our software more reliable. We have many more dependencies in our software now, so just subscribing to a mail feed of all of the version bumps in the libraries you use would be enough to drown you, and the longer you stay on older versions the more painful it can be to upgrade.

amscanne 6y ago

Care to elaborate? Bazel doesn’t require vendoring the world, and I don’t understand the connection to Nixpkgs.

Ericson2314 6y ago
My bad experiences have been trying to package bazel and bazel-built things in Nixpkgs. Bazel and Nix both want to control everything...and it gets ugly. Nix is pretty wall layered, and while it has plenty of UX problems, it's quite easy to predict what it will do. Bazel has the classic problem of new well-funded software of being more polished than architected, and so feels like working with an amorphous blob where all that polish turns on you when you do something weird and now it oozes unforeseen complexity and interactions.
- amscanne 6y ago
  I’m interested in the specific issues you hit, not just additional metaphors. Bazel, while there’s a learning curve, exists to provide hermetic builds, so I’m surprised that “what it will do” is not predictable.
  - aidenn0 6y ago
    I ran into an issue where bazel broke things pretty badly. Turns out that bazel does PID namespacing, and the build scripts assumed that no two programs with the same PID would share TMPDIR which caused some rather odd behaviors.
- malkia 6y ago
  What does it mean by "bazel" wants to control everything? AFAIK, it simply needs ways to get to the source of another package - whether it's http_archive, or who knows what, and how to build it.