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

151–160 of 176 posts

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

#151

Post by throwawaaarrgh »

> For example, configuration is in YAML, not a proprietary syntax.

This makes me sad. A product designed to be developer friendly and automate things should create a parser and custom config language, or at least borrow one. The whole reason there are so many is they are built for purpose to make a specific task easier. If you need features like templating and logic, you can slap in existing solutions like Jinja2 and Go templates. YAML is not a configuration format, it's a data serialization format. If you don't want to write a parser, use TOML.

My final note is: don't reinvent the wheel. There is a fully open source alternative to Drone.io (I can't remember the name) that forked a while ago. Drone is the best CI system for developers, hands down. Build on the open source codebase, build some proprietary extensions and a new UI, sell your product there. It's proven (because Harness now owns it) and you can help build the existing open source product at the same time.

Otherwise, I have no need for yet another build system. All build systems are pretty much the same to me (except Jenkins, which is pretty much the tenth circle of Hell) and I'd much rather use a fully open source one that I could pay for support + extensions for at work. Maybe you could make a better Jenkins?

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

#153

Post by mananaysiempre »

IshKebab wrote: post #132
hamandcheese wrote: post #127

Earlier quoted context omitted.

I think it's hilarious to say bazel focuses on correctness when it doesn't ship with any hermetic toolchains by default. Properly setting up hermetic toolchains is poorly documented and left as an exercise to the reader. I say this as someone who wants to love bazel... I just can't understand why it picks up impure toolchains from the system at all.

You have to remember that it was the very first system to even attempt hermetic & deterministic builds. Combine that with the fact that C++ toolchains at least make assumptions all over the place about being spewed over `/usr`... I think they just bowed out to practicality at that point. You're definitely right it should use hermetic toolchains. I'm curious which other Bazel-like build system does that by default?

> You have to remember that it was the very first system to even attempt hermetic & deterministic builds.

Given its Google-internal predecessors, it’s not clear how priority should be established (the general guideline in science is that non-public is not science, but that might not be what we care about here). The public Bazel, though, is from 2015, while the first releases of Nix date back all the way to 2004[1] and the thesis is from 2006.

Now Nix is not really at its best if used as a general-purpose build system, but it certainly has and uses hermetic toolchains.

[1] https://releases.nixos.org/nix/nix-0.5/manual/manual.html

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

#154

Post by qazxcvbnm »

hamandcheese wrote: post #145
eisbaw wrote: post #129

Earlier quoted context omitted.

Bazel plus nix.

This feels like the way, but comes with the huge caveat that it doesn't work with bazel remote execution (unless you can rig up something to sync your nix store to every remote builder).

I haven't used it personally, but the Nix manual mentions support for dealing with Nix stores in distributed builds https://nixos.org/manual/nix/unstable/advanced-topics/distri...

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

#155

Post by IshKebab »

hamandcheese wrote: post #144
IshKebab wrote: post #132

Earlier quoted context omitted.

You have to remember that it was the very first system to even attempt hermetic & deterministic builds. Combine that with the fact that C++ toolchains at least make assumptions all over the place about being spewed over `/usr`... I think they just bowed out to practicality at that point. You're definitely right it should use hermetic toolchains. I'm curious which other Bazel-like build system does that by default?

I wouldn't call it a bazel-like, per-se, but Nix seems to have tamed C++. I don't think it was easy, though.

As I understand it Nix can do hermeticity on a project level, but not on a build step level like you would need for actual development. So it's good for building OSes. Not for building software products.

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

#156

Post by c_s_guy »

andrew_ wrote: post #59
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…

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…

> However, it's not the taskrunner that I want.

Could you elaborate a bit on what you mean here? Is this saying Turborepo's task runner is flawed in some way?

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

#157

Post by oblio »

gen220 wrote: post #86
mileswjohnson wrote: post #83

Earlier quoted context omitted.

Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!

Take a look at Apache Aurora [1] if you want some inspiration on how to mold python into a config language. I used this system for a few years and mainly agree with the person you're replying to – having a proper programming language to define config is a very nice feature that I miss. [1]: https://aurora.apache.org/

What Python badly needs is Lua-like sandboxing/allowlisting.

You get an interpreter with access to 0 functions by default and can add stuff on top.

Maybe Python already has it, I'm not aware of it.

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

#158

Post by duped »

nsm wrote: post #113
duped wrote: post #79

Earlier quoted context omitted.

Turing completeness. No, I'm referring to using Python (waf, conan, etc), Javascript (nodejs scripts, esbuild, etc), and other "real" programming languages. It's incredibly frustrating to have to configure a build with something as shitty as YAML. There's a tangible amount of money I have wasted in organizations on it. A build is not actually a static configuration of another system. It's a program and deserves every…

You actually don't want a real programming language because their unbounded loops and standard libraries are sources of non-determinism that can introduce incorrectness in your build. Bazel's correctness is highly contingent on the same set of inputs producing the same outputs, and granularly tracking dependencies, running commands in sandboxes AND having a restricted build language is a key part of it. That said, St…

No, I do actually want a real programming language. Determinism is orthogonal to this problem and it is actually outside the scope of whether you use a hobbled config language or a full scripting language to define your build - you need sandboxing to actually achieve it (like Nix).

The reason you might want a Turing-incomplete language is that you can prove the build terminates. However that's a lie, since you will always need to escape to running programs outside the language!

Post reply on HN