Luke Boswell (Jul 12 2026 at 11:36): Luke Boswell (Jul 12 2026 at 11:36):blu said:
We could ... design our "perfect" reproducible system from scratch, but even though there are many improvements in Guix's design, nobody uses it because nix dominates their niche. So I think any system that we built would have to have backward compatibility with nix to gain adoption. That way everyone could immediately use this tool to take advantage of nix's package repository, which is the largest in the world.
So you got me thinking about this... and I had a rough idea, so I figured I'd scaffold out something and see how it goes.
https://github.com/lukewilliamboswell/roc-blueprint
Basically the starting point was -- could you bootstrap something which used pure Roc data structures in a generic way to describe the build graph, but still be 100% Nix (and guix etc) compatible from the start?
The idea is two Roc packages that work together...
1) the first roc-blueprint builds the graph and
2) the second roc-blueprint-nix takes that and lowers it to Nix specific details.
At some point in the future you could add another package which takes the same description and lowers it to guix.
Even further in the future you could build a Roc platform that replaces the whole Nix part out with something that operates purely on the blueprint data.
I haven't got much Nix experience, aside from using dev flakes that someone else built. So I figured it'd be easier for me to just build the packages and make a few examples to test it out. (Also I was half looking for another interesting shaped repo to test the new roc-lang/release-package GH actions on, and this dual package thing turned out to uncover some interesting new edge cases)
What is here so far is pretty limited -- but my hypothesis is we could start here with some CI setup etc and grow this organically from a something basic that is working.
It's also just piping stdio to a file... when basic-cli or other platforms come online they can write to a file and remove the shell workaround, or possibly provide a more advanced setup.
Luke Boswell (Jul 12 2026 at 12:29):Also -- I'm probably not going to work on this much in the short term, I want to focus on basic-cli etc but couldn't help myself this evening. :sweat_smile:
So please poke at it and make any changes or mess around with the design or ideas etc. I'm not attached to anything here.
blu (Jul 12 2026 at 15:30):Wow! This is pretty much exactly what I had in mind! I was actually working on my own implementation last night, which probably has a couple implementation distinctions we can consider. But you hit the nail right on the head this.
And this:
Even further in the future you could build a Roc platform that replaces the whole Nix part out with something that operates purely on the blueprint data.
Is pretty much where I was taking this _eventually_ (although this is probably down the road as Nix interop I'm sure will be desirable for quite some time).
I'll toss up my own repo on this tonight (and an article -- I believe there are far reaching downstream implications if we get this right and I'd love your thoughts on all of it. This can also be a good test bed to showcase the power of Roc), and perhaps we can merge the best of both.
My basic thesis is that conceptually, reproducible systems have many superior downstream effects than our current imperative ones, but in practice the only implementations we have are unusable to most people. I believe Roc can be the foundation upon which a much more user friendly system rests. But anyway! More on this later. I'll link my post here tonight.
Also -- I'm probably not going to work on this much in the short term, I want to focus on basic-cli etc but couldn't help myself this evening. :sweat_smile:
I'll offer you a trade, I've been looking for ways to dig into contributing to the broader Roc ecosystem and I've been looking a lot into CLI design lately at clig.dev in preparation for this project. I'm new to Roc, but I'll do what I can to help you with the basic-cli (feel free to kick over boring stuff) if you'll keep brainstorming with me on this :D
Richard Feldman (Jul 12 2026 at 16:02):fun fact: one of the use cases I had in mind when I first came up with the idea for Roc (back when it didn't have a name and I mostly-jokingly referred to it as "typed pure functional Lua") was Nix.
I didn't have any more specific thought than this: "you shouldn't have to invent a new language for this use case, there should be a nice, typed pure functional language you could get off the shelf to describe these things without worrying about side effects etc."
Tobias Steckenborn (Jul 12 2026 at 17:07):On the IaC side of things there are also some interesting approaches, e.g. https://v2.alchemy.run/ as an alternative to terraform. Could at one point also be an interesting area.
blu (Jul 12 2026 at 18:19):fun fact: one of the use cases I had in mind...was Nix.
you shouldn't have to invent a new language for this use case, there should be a nice, typed pure functional language you could get off the shelf to describe these things without worrying about side effects
It's funny because the reason I discovered Roc is because the chain of thoughts I had was: "Nix is a great idea but it's so crufty and hard to learn, I bet if we just made it super pleasant to use people would use it", but then I slowly realized that the "accidental complexity" went all the way up from the high-level tooling down to the language itself, so I thought "Ok, well maybe I should just make use a high level lang. to compile to it or just use a config lang. like TOML". TOML of course is limited because you need conditionals at some point (e.g. if system == "linux" then ...) and so I started digging and boom there was Roc. And then once I discovered this platform concept it just clicked and I thought "oh, this is it!"
On the IaC side of things there are also some interesting approaches...
Thanks for sharing this, I hadn't seen this one. There have been many attempts to work around the various problems in Nix. Most of them are an abstraction layer on top of one piece of Nix to improve UX (i.e. Nickel, devenv.sh), some are re-or-alternate implementations of Nix (e.g. tvix and only one (guix) has attempted to reproduce the whole stack, but they're losing out to Nix which has all the mindshare in this space.
But a solution that compiles down to Nix and offers UX improvements all the way up from the language layer could potentially piecemeal replace the externals and internals while maintaining backward-compatibility, and no one seems to have done that well yet.
Luke Boswell (Jul 13 2026 at 00:28):blu said:
I'm new to Roc, but I'll do what I can to help you with the basic-cli (feel free to kick over boring stuff) if you'll keep brainstorming with me on this :D
I don't need help with basic-cli -- it's been slow progress as we drip feed through bug fixes upstream... my goal is to try and cut a RC today (even if I'm stubbing out broken things)
Luke Boswell (Jul 13 2026 at 00:30):I'm happy to help with this Nix project ... if you have questions or anything. I'm just not a big Nix user so I think the next phase (for roc-blueprint at least) is really to try it out and see where the real issues are.
blu (Jul 14 2026 at 15:21):Began integrating this here.
Last updated: Jul 23 2026 at 13:15 UTC