Comment by imiric

Comment by imiric 2 months ago

Happy to see someone inspired by Nix, but wanting to carve their own path. Nix popularized some powerful ideas in the Linux world, but it has a steep learning curve and a very unfriendly UI, so there is plenty of room for improvement there.

I'm not sure if Lua is the right choice, though. A declarative language seems like a better fit for reproducibility. The goal of supporting non-deterministic builds also seems to go against this. But I'm interested to know how this would work in practice. Good luck!

hinkley 2 months ago

If you design it like SCons, it'll look imperative but behave more declaratively.

If I understand the architecture correctly, the imperative calls in the config file don't actually run the build process. They run a Builder Pattern that sets up the state machine necessary for the builds to happen. So it's a bit like LINQ in C# (but older).

I have no idea how that plays out single-step debugging build problems though. That depends on how it's implemented and a lot of abstractions (especially frameworks) seem to forget that breakpoints are things other people want to use as well.

Reply View 31 replies

zombiezen 2 months ago

That's accurate (unless the config file attempts to read something from the build process, that will trigger a build).
It's a good point about debugging build problems. This is an issue I've experienced in Nix and Bazel as well. I'm not convinced that I have a great solution yet, but at least for my own debugging while using the system, I've included a `zb derivation env` command which spits out a .env file that matches the environment the builder runs under. I'd like to extend that to pop open a shell.

Reply View | 30 replies
- pdimitar 2 months ago
  
  Surface-level feedback: get rid of the word "derivation". Surely there must be a better way to describe the underlying thing...
  
  Reply View | 25 replies
  
  imiric 2 months ago
  
  Agreed! It's such an alien term to describe something quite mundane. Language clarity is a big part of a friendly UI.
  
  Reply View | 3 replies
  
  umanwizard 2 months ago
  
  What’s wrong with it? It’s a term of art that means a specific thing in both nix and guix; it’d just be confusing if zb renamed it to something else.
  
  Reply View | 9 replies
  
  nurettin 2 months ago
  
  It is the name of a feature in Nix. This is as obfuscated as calling a rock a rock.
  
  Reply View | 10 replies
- skybrian 2 months ago
  
  One thing I like to see is a 'dry run' like 'make -n'. Although, maybe that's not possible in all cases.
  Another possibility might be to output a something like a shell script that would do a rebuild the same way, so you can see what it did and hack it when debugging.
  
  Reply View | 3 replies
  
  photonthug 2 months ago
  
  Yes. Dry runs at least, and better yet terraform-style planning that produces an artifact that can be applied. These should really be more common with all kinds of software
  
  Reply View | 2 replies

kortex 2 months ago

> The goal of supporting non-deterministic builds also seems to go against this.

I think this is actually a great escape hatch. Supporting non-deterministic builds means more folks will be able to migrate their existing build to zb. Postel's law and all that.

Reply View 1 reply

imiric 2 months ago

Right, could be.
One of the insane things with Nix is that the suggested workflow is to manage _everything_ with it. This means that it wants to replace every package manager in existence, so you see Python, Emacs and other dependency trees entirely replicated in Nix. As well as every possible configuration format. It's craziness... Now I don't need to depend on just the upstream package, I also have to wait for these changes to propagate to Nix packages. And sometimes I just want to do things manually as a quick fix, instead of spending hours figuring out why the Nix implementation doesn't work.
So, yeah, having an escape hatch that allows easier integration with other ecosystems or doing things manually in some cases, would be nice to have.

Reply View | 0 replies

sweeter 2 months ago

I thought of creating something similar and I was going to use a personal fork of the Go compiler with some mods, anko (which is a really cool go binding language) or righting my own DSL. It's quite the undertaking.

I like Nix and NixOS a lot, its really cool, but it has some really odd management issues and the language IMO is horrendous. I used NixOS for around a year and I was changing my Nixpkgs version and I got that same generic nonsense error that doesn't have any semantic meaning and I was just over it. I'm not too fond of commenting out random parts of code to figure out where something minor and obscure failed. Sometimes it tells you the module it had a problem with, or will point out an out of place comma, and other times its just like "idk bruh ¯\_(ツ)_/¯ "failed at builtin 'seq'" is the best I can do"

the paradigm is a million dollar idea though. I have no doubt its the future of a large portion of the future, both for programming and generic systems. I just wish it wasn't a pain to write and it had some sensible error handling.

Reply View 1 reply

danmur 2 months ago

The language has grown on me a bit. I initially hated it but a lot of my pain was not actually the language but the lack of good docs for the standard library.
Still struggle with the tracebacks though. It's painful when things go wrong.

Reply View | 0 replies

[removed] 2 months ago

[deleted]

Reply View 0 replies