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

41–50 of 176 posts

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

#41

Post by ctvo »

Denzel wrote: post #36
mileswjohnson wrote: post #17

Earlier quoted context omitted.

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…

Let me give them feedback in the vein of what you're asking for. I want the following as a user:

- Distributed cache of built artifacts. Work with my company's network topology and security requirements. Make this easy to setup, operate, and seamless for developers to opt into

- Seamless monorepo support (multiple languages)

That could be considered Bazel-lite. And yes, I'd take it over Bazel currently.

If you don't work at Google, convincing your engineering organization into learning Bazel is almost always a non-starter. Who uses Bazel in the wild? Xooglers primarily.

Their value proposition is sound.

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

#42

Post by mileswjohnson »

djstein wrote: post #35

congrats on the launch! can you share any information on how the system is currently deployed? or how it will be deployed for on premises solutions? also: are you looking for any other founders?

We haven't built the on-prem solution yet, but we're leaning towards using Helm charts + Kubernetes. At minimum, it will all be Dockerfile based.

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

#43

Post by duped »

I'm supremely disappointed to see another service using YAML to configure task running. I do in fact need a real programming language to do this, and copying others in this vein is inheriting mistakes and not picking a battle-tested solution.

What you will find is the vast majority of your configurations will invoke a make.sh script that does everything that you want to support in your system.

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

#44

Post by mileswjohnson »

Denzel wrote: post #36
mileswjohnson wrote: post #17

Earlier quoted context omitted.

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…

A lot of our decisions were based on our past experience with Bazel. We both have worked at companies that tried to use Bazel and failed miserably. There's stuff we like about Bazel (and copied in some capacity, like file groups), and definitely parts we hate about Bazel.

Bazel doesn't work well for every language, but for those languages that it does, it definitely makes sense to use Bazel. For those languages that work better with something more lightweight, that's where moon comes in. I'm assuming you work at Google, so you're experience around Bazel is probably much better than those that don't work at Google.

I appreciate all the feedback and comments though, very much appreciated.

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

#45

Post by thundergolfer »

mileswjohnson wrote: post #30
pdeva1 wrote: post #22

one of the reasons Bazel needs BUILD files with explicit inputs /outputs defined per file is to do fine grained incremental builds and test runs. so if i change say foo.c, i only need to recompile foo.obj and run ‘foo-tests’. Moon seems to take globs as input. Thus modifying even a single file inside ‘src’ dir will trigger rebuild/retest of the entire ‘project’

Our configuration is using globs but under the hood we content hash all the files that match the glob, and only run/cache if the aggregated hash has changed. For the languages we currently support, this is more than enough. Once we dive deeper into compiled languages (probably starting with Rust), we'll look into more granular reactivity and possible use something like sccache.

Bazel's glob does the same thing. I'm not sure what the OP means, Bazel's incrementality is aided by fine-grained build input specification, but it's incrementaility is at core a combination of deterministic build rules, storage of build rule execution history, and early-stopping.

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

#46

Post by mileswjohnson »

ctvo wrote: post #41
Denzel wrote: post #36

Earlier quoted context omitted.

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…

Let me give them feedback in the vein of what you're asking for. I want the following as a user: - Distributed cache of built artifacts. Work with my company's network topology and security requirements. Make this easy to setup, operate, and seamless for developers to opt into - Seamless monorepo support (multiple languages) That could be considered Bazel-lite. And yes, I'd take it over Bazel currently. If you don't…

Thank you. This is how we feel as well.

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

#47

Post by palmdeezy »

lhorie wrote: post #39

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 b…

Turborepo author here…

We do not invalidate the whole graph anymore for a lockfile change. We now have a sophisticated parser that can calculate if a change within the lockfile should actually alter the hash of a given target. In addition to higher cache hit rates, this is what powers our `turbo prune` command which allows teams to create slices of their monorepo for a target and its dependencies…useful for those building in Docker.

Prune docs: https://turbo.build/repo/docs/reference/command-line-referen...

Turborepo is much more scalable now than when we spoke pre-Vercel acquisition. It now powers the core web codebases at Netflix, Snap, Disney Streaming, Hearst, Plex and thousands of other high-performance teams. You can see a full list of users here: https://turbo.build/showcase

Would be happy to reconnect about Uber’s web monorepo sometime.

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

#49

Post by mileswjohnson »

beisner wrote: post #31
mileswjohnson wrote: post #15

Earlier quoted context omitted.

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. withou…

I don't disagree here. At the moment, moon leans closer to a task runner, with hashing, incremental caching, and other features tacked on. All of our currently supported languages are not compile based languages, and run with pre-built binaries.

Once we starts supporting more languages, especially compile based ones (probably Rust first), our decision around YAML will probably change. Off the top of my head, a non-YAML format would probably be used as a secondary format, kind of like how a Dockerfile works.

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

#50

Post by arnorhs »

Awesome, congrats. I've been an early trier of moon repo and I really fell for the slickness of the website and the name, when evaluating build tools.

I've primarily worked in typescript codebases and have used raw yarn workspaces, lerna, nx and recently evaluated moon and turbo.

The funky part is I eventually simply went with nx, not just because I've used it before, but also because I felt like the configuration is just simpler and more lightweight. Esp. since you can pretty much roll with it without defining much more than single simple config file - while moon required some 2-3 separate config files, plus config files in each project (I understand the per-project config is not required, I don't remember why I needed it - something to do with my build tasks)..

In any case I intend to give it another shot soon.

As for the whole config in yaml vs json vs toml or whatever, not a deal breaker since most of the time these sorts of configs are perhaps not something you end up interacting with programmatically - I know a lot of people enjoy editing yaml more than json files

Post reply on HN