No it’s fine. I get a very stack overflow “marked as a dupe” energy here. I personally thought it was on-topic and really not that much of a tangent (since I literally came up with the idea because of the discussion). So, I don’t feel like forcefeeding people that are resistant to that. “Remember to keep it boring, people!”
If you need me, I’ll be on the Purescript or Haskell discourse where the energy is more up my alley.
I think the sentiment was that you should have made a separate announcement of the fork itself in a separate thread, which would allow for holding possible off-this-topic discourse there.
People here are mostly discussing which scripting languages could be viable for improving the current Nixpkgs tooling. So, if I wanted to ask you a question a specific design choice, or to make a suggestion for a change, I would then likely feel as if this is not an appropriate place to do so.
Merely mentioning the project (and its relation to this discussion) was not a problem at all, so I kindly request that you restore those deleted comments.
That’s a great point, I was caught up thinking about the packages side of nixpkgs, not the nixos modules and the scripts they build. This would indeed be be a valid target for an alternate scripting language.
@harryprayiv I was not asking you to remove any of your posts, and I’m sorry if I made you feel like your contributions were unwelcome. We can disagree about what is off-topic and discuss it. Shutting down the conversation and deleting all your posts benefits nobody.
Lisp languages are friendly if you have a structural editor combined with a decent REPL. Some people like Lisp because they think they have these, for and only for Lisp, although actually Emacs is not structural and typical Lisp REPLs are not so decent. When presented as snippets in a repository of plain text files, Lisp degrades into poor serialization of AST. That is why most people don’t like it.
Ditto, I have a lot of respect for what lisp achieves and some of its properties, but I find reading and writing lisp painful. The good news is people who do like lisp already have Guix, which I’m told has a lovely community and is quite usable.
I’m being only half serious here but what about using Zig for this and writing more elaborate build.zig files?
I would still really like to see this happen.
I feel like paring nixpgks back to using only POSIX-compatible syntax is a non-starter. too many things become difficult workarounds (arrays and env handling bits iirc).
nuenv is a good example of what can be done from a clean sheet, although the blog post that goes with it points out some big limitations of what the current implementation can do, and the repo has not accumulated any changes in the last 2 years.
nix-hell seems like a nice tool for using outside builds, but I worry about using a language that’s so dependent on indentation in a context where we’re string-munging together scripts in many derivations and it’s so easy to mess up the indentation. Python suffers the same problem, as much as I love the language (fight me!).
build.zig is cool but feels like a make/CMAKE replacement more than a stdenv replacement, and the syntax is pretty heavy.
If we don’t want to do wholesale replacement, we could transparently switch bash in stdenv for brush, a rust-written drop-in replacement with better error messages, and a much nicer interactive mode for running in devshells and the like.
I’m personally a big fan of fish, which has some really nice scripting ergonomics, but is mostly posix-compatible enough that converting over derivations should not require many changes.
I could bike-shed options for interpreters and debate the nature of scripts for an eternity…
Actually changing stdenv will require either a mass-rebuild event and some serious effort into tracking down all the build failures, or a slow migration slog as we bring over packages or package sets one-by-one. Is the pain worth it?
Can we start by introducing some alternate stdenvs and allowing derivations to opt-in if they find the value greater than the pain? Would this require an RFC, or is it something that can be added incrementally?
Just wanted to say RFC process was discontinued a while ago RFCSC Meeting 2025-05-26 was the last meeting notes entry.
A lot of these shells like fish don’t support bash’s --rcfile flag, which is a critical piece of how devshells work. It’s used in the shebang line of the devshell RC script.
