Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Moonrepo (YC W23) – Open-source build system

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 176 posts

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#31

Post by beisner »

mileswjohnson wrote: post #15
beisner wrote: post #2

What's the motivation for using YAML instead of Starlark (Bazel, Buck) or something closer to Python (Pants, please.build)? Seems as though much of the other monorepo tools have (kinda) standardized on this. As I understand it, the primary reason these build systems leverage these Python-variants is so that the build rules, toolchains, constraints, and build definitions can all be written in the same language (since…

We chose YAML for a few reasons. The first being that we wanted a format that is basically universally supported everywhere. This filtered down to JSON, TOML, and YAML. JSON is an awful configuration format, so that was a no go. TOML is pretty great, but is also not very ubiquitous. That left us with YAML. The second reason is we wanted something language agnostic and not proprietary. It also helps that many other to…

Gotcha, understood. Mirroring @Denzel's edit, I think that rationale makes sense for configuring some of the intermediate glue which is project-specific. For instance, running test suites, orchestrating deployment, and other more custom actions which aren't terribly reusable across projects (think Bazel's 'genrule'). Caching test results in a distributed way is a great use case, and environment isolation (i.e. without forcing the user to define a Dockerfile or similar, and leaving environment configuration to the build system) seem like great use cases.

However, I think for describing actual build toolchains this way of implementing things might end up being significantly more complicated (and require even more arcane end-user cognitive load) than the Starlark/Python-based build rule / toolchain / constraint approach for actually assembling libraries, binaries, and other compiled artifacts. There are a combinatorial number of backends, conditional options settings, etc. which will be hard to capture with a purely declarative system. For instance, a C++ binary might needs platform-specific compiler flags, or some #ifdef nonsense. YAML doesn't have a clean way of implementing conditionals based on some constraint. So for heterogenous ecosystems (C/C++, Python, container assembly, GPU development, microcontrollers, etc.) this pushes a ton of complexity into the build rules themselves which may be opaque to end users (and thus introduce a ton of cognitive load, steep learning curves, hard-to-debug errors, etc.).

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#32

Post by randall »

computershit wrote: post #18
randall wrote: post #16

Earlier quoted context omitted.

IDK. I've been using buck for a bit, and having python within grasp is pretty useful. I don't like yaml for a variety of reasons, but the biggest of which is I like my config being able to be generated... maybe that's an anti pattern? IDK. Would love to know more about your take on yaml vs anything more pythoney.

What makes yaml not generatable?

Sorry, I meant more dynamic than generatable... like doing stuff in the build file to build something complex in a more simple way.

It's really 'do you make config an artifact, or do you make it code' sort of argument.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#33

Post by IceWreck »

You're building something like buck/blaze and replacing starlark with YAML ? I want a full programming language when defining complex rules. Build systems do a lot more than execute commands.

You lost me there. Buck/Blaze aren't perfect but configuration was never an issue.

Moon like it is currently is a glorified task runner.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#34

Post by jedberg »

My advice to anyone making a new build system:

Most likely you did this because you felt all the other ones are too complicated.

But the reason the “enterprise” ones are so complicated is to serve their enterprise customers, who need “just this one feature” so they can use it. But those customers pay the bills.

So basically you have to choose complexity and profit or simplicity and less (or no) profit.

Good luck! But make sure you’re ready to make that choice.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#36

Post by Denzel »

mileswjohnson wrote: post #17
Denzel wrote: post #7

Earlier quoted context omitted.

Not to mention using an actual language aids readability, extensibility, and static analysis, unlike a data exchange format. Starlark is a benefit, not a con, so YAML feels like a major step backwards. I'm generally happy with Blaze/Bazel, so I'm not necessarily in the target market for Moonrepo, I guess. EDIT: This isn't really competing with Blaze/Bazel either when I look at the execution model. It goes back to imp…

Yeah that's fair feedback. At this time, we consider ourselves more of a Bazel-lite than an actual Bazel replacement. Once we support more languages and features, this may change in the future.

I'm not trying to be overly critical here, in fact, I want to share the type of empathetic feedback I'd hope to receive as a founder.

Have you actually talked to Blaze/Bazel users to understand what frustrations (if any) they have with their current build system? Have these users asked for a Bazel-lite? If so, and you still want to position yourself as Bazel-lite, then you should include some of their direct feedback and write your messaging accordingly.

As a daily Blaze/Bazel user, I don't have a desire for a Bazel-lite. I've worked at a midsize company that used Bazel, and I'm working at the company that created Blaze/Bazel.

Disclaimer: Opinions expressed are my own; not representative of my employer.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#37

Post by tunkafor »

bunged wrote: post #19
mileswjohnson wrote: post #13

Earlier quoted context omitted.

So moon wouldn't replace your actual CI pipelines. It would be a tool that runs _in your pipeline_ to effectively run tasks as fast as possible. For example, in CI, tasks are only ran if they are affected by files changed in the pull request. No more running everything unnecessarily. We also support remote caching of artifacts, which helps to speed up CI even further, by avoiding long build times.

Interesting, so does it keep all the intermediates from previous builds and then does an incremental build on top of this? Like doing a local dev build but in the cloud?

We've had a lot of success with Brisk (https://brisktest.com/) doing this exact thing. It keeps our environment running so we don't have to rebuild on every run, kind of like a dev build. It's really fast.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#38

Post by thundergolfer »

jpgvm wrote: post #21

Bazel has a heavy focus on correctness (pretty much to the exclusion of everything else). Where does Moon fall on the correctness gradient? Does it enforce hermecity or deterministic builds or give me tools to accomplish it? In the same vein as those questions how does caching work? Is it content based like Bazel or mtime like Nx et al? If there is no sandboxing does it do input tracking or is there manual "cache key…

To be clear, Bazel focuses on correctness because it's essential to acheiving performance at scale.

If you don't have correct caching of intermediate build artifacts, a system can't handle the compile and test requirements of large codebases.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#39

Post by lhorie »

IMHO, if you're targeting the Javascript ecosystem, this area is already fairly crowded, with Turborepo, Nx and various open source tools providing various degrees of functionality (Bazel, Pants, Lerna, etc) already competing in the space.

I'm a tech lead for the web monorepo at Uber. We talked to the Turborepo guy a few years ago, and he admitted that he wasn't sure if it could handle our scale in terms of all the bells and whistles that a repo of our size leverages - and his is one of the more feature packed commercial offerings in this space.

As a random example: we see thousands of commits a week, so invalidating the whole build graph when the lockfile changes is a complete non-starter, yet most turn-key solutions target small teams and are not equipped to cope with this problem. Phantom dependencies[0] are a problem with disjointed build graphs. Etc.

As someone who's evaluated a ton of these systems, I would love to see where your experience in this space is coming from. A new kid in the block will have a lot to prove.

[0] https://rushjs.io/pages/advanced/phantom_deps/

Post reply on HN