Live data from Hacker News

Zb: An Early-Stage Build System

zombiezen.com

121–130 of 132 posts

Re: Zb: An Early-Stage Build System

#121

Earlier quoted context omitted.

How do you handle flakes pushing an entire copy of the repo into the nix store? Is this not an issue for you somehow?

The repo being evaluated? Not an issue for me. In the dev scenario disk is plentiful; in production it can be garbage collected out or avoided by using copy-closure type workflows or nix2container (eg just not running nix evaluations directly in the target environment).

That makes sense. I naively tried flakes for a nix-shell replacement for a couple environments, one was a node app with large node_modules dependencies and the other was a windows app I was running in a local wine root. In both cases re-evaluating the flake was very slow because of the volume of data being copied. I want to do more with flakes but I’m skeptical that they end up being a good per-app workflow when the whole app isn’t using nix for build and dependencies end-to-end.

Re: Zb: An Early-Stage Build System

#122

Earlier quoted context omitted.

I'm about to start a project where I thought Nix might be useful. What do I need to watch out for? Where is it going to piss me off and send me back to Docker?

There are no guardrails. Whenever something goes wrong, you'll get weird cryptic errors in a seemingly unrelated area and have no clue how to fix it until you post to a support group to discover that you put a comma in the wrong place. You'll spend a LOT of time fighting the system, which gets old fast. Docker may have a sucky plan format (and they STILL won't let you set your goddamn MAC address), but it's good enou…

Oh, and my personal favorite: Programming by maps.

Any time you put in a key that it doesn't recognize, it just gets ignored. So you get to spend hours/days trying to figure out why the hell your system won't do what you told it to, and won't even validate that what you put in makes sense.

Re: Zb: An Early-Stage Build System

#123
post #24

Earlier quoted context omitted.

Definitely interesting, but it's flat-out wrong about the limitations of `make`. In particular, the `release.txt` task is trivial by adding a dummy rule to generate and include dependencies; see https://www.gnu.org/software/make/manual/html_node/Remaking-... (be sure to add empty rules to handle the case of deleted dynamic dependencies). You can use hashes instead of file modification times by adding a different kind…

I guess you aren't keen on Java then? Complex dynamic dependency graphs aren't difficult for humans to handle or many build tools other than make.

    > I guess you aren't keen on Java then?
Can you explain more? I don't follow.

Re: Zb: An Early-Stage Build System

#124

Earlier quoted context omitted.

The part you seem to deliberately miss is that what is obvious to people deeply invested in Nix is not obvious to anyone else. I for one can't trace the train of thought that is going from "intermediate build artifact" and somehow arrives at "derivation". I found out just enough about Nix to reject it. My take is still informed, I simply didn't buy its pitch.

I geniunely thought you knew nothing about derivations and were criticizing the blogger for writing the term in their blog, not the term standard to Nix itself. Which is just as weird to me as complaining about std::string, well why call it a string? it is obviously text!

No need to resort to obvious straw man arguments, you can just accept some people dislike the dev UX of Nix and move on, which is basically what me and others have been trying to say in this entire sub-thread, some much more detailed than me.

No idea why you keep digging at this, the takeaway was clear at least three comments ago.

Re: Zb: An Early-Stage Build System

#125
post #24

Earlier quoted context omitted.

Definitely interesting, but it's flat-out wrong about the limitations of `make`. In particular, the `release.txt` task is trivial by adding a dummy rule to generate and include dependencies; see https://www.gnu.org/software/make/manual/html_node/Remaking-... (be sure to add empty rules to handle the case of deleted dynamic dependencies). You can use hashes instead of file modification times by adding a different kind…

I guess you aren't keen on Java then? Complex dynamic dependency graphs aren't difficult for humans to handle or many build tools other than make.

I'm not keen on Java for other reasons. The fact that a single .java file can generate multiple .class files is annoying but not something tools can't handle (it's actually similar to .h files for C/C++ - remember, we only need the complete dependency graph for the rebuild, not the current build).

The main part that's difficult for humans is if there's a non-public class at top level rather than nested (I forget all the Java-specific terminology for the various kinds of class nesting).

Re: Zb: An Early-Stage Build System

#126

Earlier quoted context omitted.

I geniunely thought you knew nothing about derivations and were criticizing the blogger for writing the term in their blog, not the term standard to Nix itself. Which is just as weird to me as complaining about std::string, well why call it a string? it is obviously text!

No need to resort to obvious straw man arguments, you can just accept some people dislike the dev UX of Nix and move on, which is basically what me and others have been trying to say in this entire sub-thread, some much more detailed than me. No idea why you keep digging at this, the takeaway was clear at least three comments ago.

[deleted]

Re: Zb: An Early-Stage Build System

#127

Earlier quoted context omitted.

I geniunely thought you knew nothing about derivations and were criticizing the blogger for writing the term in their blog, not the term standard to Nix itself. Which is just as weird to me as complaining about std::string, well why call it a string? it is obviously text!

No need to resort to obvious straw man arguments, you can just accept some people dislike the dev UX of Nix and move on, which is basically what me and others have been trying to say in this entire sub-thread, some much more detailed than me. No idea why you keep digging at this, the takeaway was clear at least three comments ago.

FYI "here's what I genuinely thought" is not a straw man. Now I am genuinely sorry for ever responding to you. Say hello to others for me.

Re: Zb: An Early-Stage Build System

#128

Earlier quoted context omitted.

No need to resort to obvious straw man arguments, you can just accept some people dislike the dev UX of Nix and move on, which is basically what me and others have been trying to say in this entire sub-thread, some much more detailed than me. No idea why you keep digging at this, the takeaway was clear at least three comments ago.

FYI "here's what I genuinely thought" is not a straw man. Now I am genuinely sorry for ever responding to you. Say hello to others for me.

The straw man was your std::string example. It was nowhere near the same as you claimed.

Say hi to the others in your club of "I'm gonna pretend I didn't get it for no reason whatsoever" for me.

Re: Zb: An Early-Stage Build System

#129

Earlier quoted context omitted.

I guess you aren't keen on Java then? Complex dynamic dependency graphs aren't difficult for humans to handle or many build tools other than make.

> I guess you aren't keen on Java then? Can you explain more? I don't follow.

Java dependencies are too complicated for make. See https://www.oreilly.com/library/view/managing-projects-with/...

Re: Zb: An Early-Stage Build System

#130

Earlier quoted context omitted.

FYI "here's what I genuinely thought" is not a straw man. Now I am genuinely sorry for ever responding to you. Say hello to others for me.

The straw man was your std::string example. It was nowhere near the same as you claimed. Say hi to the others in your club of "I'm gonna pretend I didn't get it for no reason whatsoever" for me.

It was an example, you thought it was a bad example, and the rest were just inane accusations.
Post reply on HN