Launch HN: Moonrepo (YC W23) – Open-source build system
101–110 of 176 posts
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#102Congrats on the launch! Indeed interesting space. I wonder if it has some overlap with https://skaffold.dev/ . I would be curious to hear the differences.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#103Earlier quoted context omitted.
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…
Off the top of my head, some companies that successfully use Bazel: SpaceX [1], Datadog [2], Databricks [3], Stripe [4], Uber [5], etc. That's a good 10k+ engineers using Bazel successfully in the wild. There's more, of course. [1]: https://www.youtube.com/watch?v=t_3bckhV_YI [2]: https://www.youtube.com/watch?v=H67uuwVO1tc [3]: https://www.databricks.com/blog/2019/02/27/speedy-scala-buil... [4]: https://stripe.com/b…
Large companies, with established platform / ops teams, who can support Bazel and push for its adoption within an engineering organization definitely exist. There's probably a few Xooglers working there who'd like to see it happen too.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#104I'm not a lawyer, but given that monorepo was in use in the versioning/build space long before launch, I would have been hesitant to launch with a name where it's going to be an uphill battle to enforce trademark. (I also worked for Google a while back, and they were very conscious about not using Google as a verb internally, losing a slow battle against the tide of trademark dilution.)
It took me three readthroughs to notice as well, but the name is actually `moonrepo` not `monorepo`.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#105Apologies if this sounds reductive but can I think of it as an open source CircleCI? The thing that annoys me most about CircleCI, TravisCI, Github Actions and Appveyor is that there is no simple way to run the same thing locally to debug or test workflows without creating either git history mess or temporary hacks like taking off branch restrictions in the yaml.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#106Earlier quoted context omitted.
Off the top of my head, some companies that successfully use Bazel: SpaceX [1], Datadog [2], Databricks [3], Stripe [4], Uber [5], etc. That's a good 10k+ engineers using Bazel successfully in the wild. There's more, of course. [1]: https://www.youtube.com/watch?v=t_3bckhV_YI [2]: https://www.youtube.com/watch?v=H67uuwVO1tc [3]: https://www.databricks.com/blog/2019/02/27/speedy-scala-buil... [4]: https://stripe.com/b…
No one has, to my knowledge, argued that Bazel isn't useful or worthwhile. My point was adopting Bazel is costly for an engineering organization, and you may not need all of its features. Bazel-lite may be enough. Large companies, with established platform / ops teams, who can support Bazel and push for its adoption within an engineering organization definitely exist. There's probably a few Xooglers working there who…
My response shows these hypotheses to be false. You’re correct, no one’s arguing whether Bazel is useful or worthwhile, not even I.
> Large companies […] who can support Basel within an engineering organization definitely exist.
Ok great, we agree. You’ve revised your point from earlier.
> There’s probably a few Xooglers […]
A baseless hypothesis that’s confirmed false by all the references shared with you. Feel free to plug all the lead engineers’ names into LinkedIn to verify that the majority are not ex-Google.
> Bazel-lite may be enough.
Sure, it may be. That’s why I’m offering the constructive feedback to go talk to the thousands of active Bazel users to see whether and what they want from a Bazel-lite, if that’s the positioning Moonrepo wants to choose.
Usually, there’s a strong rationale and need behind an organization’s adoption of Bazel. Some of that rationale is captured in the references shared earlier. These organizations need Bazel; they’re generally happier with Bazel than their previous systems. These baseline needs represent table stakes for any build system that wants to compete with Bazel.
If Moonrepo wants to compete where Bazel is weak, then I’m suggesting that they need to sharpen their communication such that an engineer well-versed in Bazel has an “aha!” moment within 2 minutes. The proverbial elevator pitch.
Once again, I’m not dissuading Moonrepo from pursuing their vision. I’m offering constructive feedback on their messaging/positioning — the type of feedback I’d like to hear as a founder.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#107IMHO, 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…
Nx is hot garbage imo. Buggy, overly verbose, inflexible, poorly documented, and I'm dubious about their peer review process. If I don't need build caching I'm not using any tool but PNPM and its workspace toolset - that's literally all most people need for a monorepo. I've looked into Turborepo, and its simplicity versus Nx is a strength. However, it's not the taskrunner that I want. I now work in a monorepo where b…
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#108IMHO, 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…
Nx is hot garbage imo. Buggy, overly verbose, inflexible, poorly documented, and I'm dubious about their peer review process. If I don't need build caching I'm not using any tool but PNPM and its workspace toolset - that's literally all most people need for a monorepo. I've looked into Turborepo, and its simplicity versus Nx is a strength. However, it's not the taskrunner that I want. I now work in a monorepo where b…
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#109I'm not going to click "learn more" because you've given me absolutely no reason to. The page may as well just be "log in with github" and nothing else. That'd serve the same functionality, and have an equally convincing pitch to prospective customers.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#110Earlier quoted context omitted.
No one has, to my knowledge, argued that Bazel isn't useful or worthwhile. My point was adopting Bazel is costly for an engineering organization, and you may not need all of its features. Bazel-lite may be enough. Large companies, with established platform / ops teams, who can support Bazel and push for its adoption within an engineering organization definitely exist. There's probably a few Xooglers working there who…
> 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. My response shows these hypotheses to be false. You’re correct, no one’s arguing whether Bazel is useful or worthwhile, not even I. > Large companies […] who can support Basel within an engineering organization definitely exist. Ok great, we agree.…
Even in my original reply:
> 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.
Emphasis on almost since you've missed it three replies now.
What are you even getting at here? I freely admit that some companies adopt Bazel. Many do not. You doing a Bing search to find the ones that do doesn't change that fact.
> Ok great, we agree. You’ve revised your point from earlier.
I haven't revised anything. You misread, but feel free to be needlessly hostile defending a product your current employer makes against a newly launched competitor. I use the word competitor loosely. It's not a good look either way.
> That’s why I’m offering the constructive feedback to go talk to the thousands of active Bazel users to see whether and what they want from a Bazel-lite, if that’s the positioning Moonrepo wants to choose.
Why would they need to talk to people who are actively using Bazel to see if they want Bazel-lite? It's a small population that's already, presumably, well served.
There's a whole other, much, much larger segment of customers who'd love to use Bazel-lite that aren't using Bazel, for many reasons, including the high cost of adopting and supporting it. I'm one of those customers. Unsure why this point escapes you.
Your advice, by the way comes off as attacking their idea and trying to tear it down regardless of how many times you preamble it's constructive criticism.