Live data from Hacker News

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

news.ycombinator.com

131–140 of 176 posts

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

#132
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…

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?

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

#133
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…

> Does it enforce hermecity or deterministic builds or give me tools to accomplish it? I wouldn't say moon is hermetic, nor are we trying to be. We don't use the sandbox approach for tasks, and run against the original files. For the languages we support, this works best. As for deterministic, we try to be. We have a "toolchain" where we download languages/tools in the background, and run tasks using these tools. Thi…

How do you target large codebases then? The whole point of hermeticity is to allow you to reliably not rebuild and test everything on every commit which is the issue most large codebases have.

Also a bit disingenuous to describe it as language agnostic if it only really works with non-compiled languages.

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

#134
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…

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.

Yeah it can be done but it's painful. In general the Bazel rules are lower quality than Bazel itself - and rules_python is one of the better ones!

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

#135

Configuration is code, so the YAML written in your tool is still code, code that developers are consuming and versioning. Making it YAML doesn’t make it not code . Your YAML configuration files are proprietary syntax , it is a proprietary code syntax written in a language (YAML) lacks basic abilities for logic or control flow. In a system of any worthwhile complexity, inevitably custom build logic will have to be exp…

Why? Why YAML? Why? YAML is absolutely terrible!

Aside from the classic `country_code: NO`, the other day I ran into issues with scientific notations. Now, guess, which of the following are strings, and which are numbers:

- 1e+10

- 1.e+10

- 1.0e10

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

#136
post #128
post #73

Earlier quoted context omitted.

Look at https://moonrepo.dev/docs#supported-languages They only fully support Javascript. The complex stuff, like defines, C++ toolchain, dynamic libs, etc.. is all out of scope.

Wow true. Claiming to be a build system yet being limited to JS... Apparently, the legions of JS developers think the web is the only thing that exists today.

Apparently, the legions of JS developers think the web is the only thing that exists today.

That's very unfair to JS devs. We're well aware that other things exist...

...because we're trying to replace them all with JS.

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

#137
post #135

Configuration is code, so the YAML written in your tool is still code, code that developers are consuming and versioning. Making it YAML doesn’t make it not code . Your YAML configuration files are proprietary syntax , it is a proprietary code syntax written in a language (YAML) lacks basic abilities for logic or control flow. In a system of any worthwhile complexity, inevitably custom build logic will have to be exp…

Why? Why YAML? Why? YAML is absolutely terrible! Aside from the classic `country_code: NO`, the other day I ran into issues with scientific notations. Now, guess, which of the following are strings, and which are numbers: - 1e+10 - 1.e+10 - 1.0e10

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

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

#138
post #118

Earlier quoted context omitted.

Yes! Prune then zip the output folder.

Kind of. Poster asked if you can prune only deps and exclude dev deps. That's currently unsupported: https://github.com/vercel/turbo/issues/1100

That's correct. However, I've tried to use prune now, not sure if I am using it correctly, but that's why I do:

I build my packages regularly (not pruned), then I prune with scope "backend". Apparently the pruned directory contains node_modules with empty packages, not sure what reason is for that; I just ignored it. In the resulting directory I then run `pnpm install --prod`. Only the regular dependencies will be installed. I think this is enough for my usecase. I am not sure if prune is supposed to be used for this approach though.

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

#139
post #114
post #99

Earlier quoted context omitted.

Are you sure you can't have your cake and eat it too? You can have many configuration options, but give each one a sane default.

In my experience (Bazel, sample size of 2 projects), the complexity doesn't come from configuration options that have defaults, but from how well the "mental model" of the build system fits the preconceived notions of how to structure, organize, and depend on code in an existing project. Almost none of the complexity comes from what configuration options I've registered ahead of time. It comes almost entirely from, "…

Ironically this means the best time to adopt Bazel is from the very start. Despite the fact Bazel doesn't add much at that point in time it's when the cost is lowest and it prevents impedance mismatch from being introduced.

This runs counter to how most people think of things like Bazel which are tools you should only reach for when the situation has already grown out of control.

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

#140
post #80

> We wanted our system to be enjoyable to use and easy to understand, but also solve the same problems as existing systems. For example, configuration is in YAML, not a proprietary syntax I'm incredibly skeptical of this. I'm ex-meta and have worked a lot with the enterprise solutions you're talking about and the choice of starlark (originally python) as the build definition language is one of the killer features of…

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

Yeah, 100%, use a scripting language. Maybe JS? You could use deno core https://deno.com/blog/roll-your-own-javascript-runtime
Post reply on HN