3 ms·

"Some people might say it’s a bit like Lua with Python syntax" ye gods

benreesman 2y ago
I can appreciate that it might not sound that appetizing but it’s really pretty good. I worked on the original Buck and kind of caught the “principled and performant polyglot build system” bug and I’ve been diving down that rabbit hole since. There are still usability and adoption challenges, but it’s the future and between buck2 and bazel7/bzlmod the gap to slow, non-deterministic alternatives is closing fast. I wouldn’t write it off.
- __float 2y ago
  Why do you call out bzlmod? I haven't heard great things about it.
  - ithkuil 2y ago
    I'm happy with bzlmod. What I hate about it is that not every bazel ruleset I use has yet been ported to it. But it's getting there. For example in my monorepo I'm only missing rule_distroless and I migrated all my deps to bzlmod. The modules lock file situation has been greatly improved since 7.2.0-rc1. The lock file contains much less digests in it and its less likely to cause spurious merge conflicts With bazelisk and .bazelversion we managed to have everybody use the same version of bazel and thus we could cheaply try out the rc1 and so far is working fine.
  - benreesman 2y ago
    To the extent there’s a real issue with ‘MODULE.bazel’ (aka bzlmod), it’s that Bazel has such a rich ecosystem even on the old, janky ‘WORKSPACE’-style that the slick new thing that always works is impossible to migrate in one go. The Bazel team flags things off by default for years, and then things on for years, because they’re engineers and try hard not to break people’s shit. Are feature flags and migration paths and interim solutions more work? Yeah, no doubt. But for all their recent fumbles in AI and steadily downward trajectory on search and all the things that happens when a big company is run by people who were never all that technical? Google still has a hard core of the baddest hackers you don’t want to mess with.
- deleted 2y ago
  [deleted]

I can appreciate that it might not sound that appetizing but it’s really pretty good. I worked on the original Buck and kind of caught the “principled and performant polyglot build system” bug and I’ve been diving down that rabbit hole since. There are still usability and adoption challenges, but it’s the future and between buck2 and bazel7/bzlmod the gap to slow, non-deterministic alternatives is closing fast. I wouldn’t write it off.

__float 2y ago
Why do you call out bzlmod? I haven't heard great things about it.
- ithkuil 2y ago
  I'm happy with bzlmod. What I hate about it is that not every bazel ruleset I use has yet been ported to it. But it's getting there. For example in my monorepo I'm only missing rule_distroless and I migrated all my deps to bzlmod. The modules lock file situation has been greatly improved since 7.2.0-rc1. The lock file contains much less digests in it and its less likely to cause spurious merge conflicts With bazelisk and .bazelversion we managed to have everybody use the same version of bazel and thus we could cheaply try out the rc1 and so far is working fine.
- benreesman 2y ago
  To the extent there’s a real issue with ‘MODULE.bazel’ (aka bzlmod), it’s that Bazel has such a rich ecosystem even on the old, janky ‘WORKSPACE’-style that the slick new thing that always works is impossible to migrate in one go. The Bazel team flags things off by default for years, and then things on for years, because they’re engineers and try hard not to break people’s shit. Are feature flags and migration paths and interim solutions more work? Yeah, no doubt. But for all their recent fumbles in AI and steadily downward trajectory on search and all the things that happens when a big company is run by people who were never all that technical? Google still has a hard core of the baddest hackers you don’t want to mess with.
deleted 2y ago
[deleted]