Andrea Bueide (Sep 01 2024 at 17:24): Andrea Bueide (Sep 01 2024 at 17:24):I've been exploring / thinking about creating a platform / api for creating nix packages with roc, I think it could yield some interesting results. I know roc doesn't have a fully implemented package manager / registry a la cargo, but do you guys think that if we do build one, one that integrates with nix might be plausible?
Brendan Hansknecht (Sep 01 2024 at 17:55):I don't fully understand the question. Probably cause this feels like two separate ideas to me:
Andrea Bueide (Sep 01 2024 at 18:25):You're right it would be 2 different ideas. I was thinking of using roc as sort of a nix++ language where we could get the benefits of roc's type system (which I think is a perfect balance for build declarations). I've always had a few gripes with nix lang's error messages and type system. All though I can't really imagine how you'd do this without essentially creating a roc -> nix lang transpiler which seems like it would be pretty difficult.
Originally I was thinking if this idea was done it might make sense to make a more domain specific roc package management system on top of it which could pull in nixpkgs as dependencies, along with some platform integrations to call / interact with binaries from nixpkgs via some sort of roc ffi. For example this would allow you to make a roc cli program which can depend on other cli programs on nixpkgs (ffmpeg or imagemagick for example), but also be able to publish roc libraries to nixpkgs and be able to depend on roc libraries in nixpkgs or another rocpkgs repo and utilize the already existing nix infrastructure (cachix, deployment tools, flake version pinning, nix gc, reproducibility etc).
Anton (Sep 02 2024 at 10:27):It doesn't seem like it would be worth the effort to put roc packages on nix, they can't be prebuilt or depend on things like ffmpeg or imagemick. For platforms it could make sense.
Luke Boswell (Sep 02 2024 at 11:31):It seems to be a topic of conversation already.
https://www.reddit.com/r/NixOS/s/9V0qTvizHL
Bjørn Stabell (Sep 04 2024 at 05:20):It would be pretty cool to use Roc instead of Nix for sure (flake.roc), ideally in a way so all dependencies are imported and type checked... so you essentially just 'run' the flake.roc?
Hannes (Sep 04 2024 at 12:54):There's a project called Glistix that compiles Gleam to Nix, so it's definitely feasible, but, like Glistix forked the Gleam compiler, it will probably require forking the Roc compiler, mainly because Roc and Gleam are strictly evaluated and Nix is lazily evaluated.
Andrea Bueide (Sep 04 2024 at 19:55):oh wow I did not know about Glistix, it looks quite comprehensive and pretty much exactly what I was thinking about with roc. Maybe would be best to not duplicate efforts there. I think if roc were to have some sort of nix-like build system maybe it could build on top of the nix daemon/store instead of trying to transpile to nix and build its own thing where we can take advantage of tail call recursion and optimistic mutation performance improvements and focus on being blazing fast. I didn't actually know that nix itself didn't even support tail call recursion so it makes sense a language transpiled to nix couldn't, and that would ring true of the other benefits roc provides.
Bjørn Stabell (Sep 04 2024 at 20:51):Just thinking out loud, probably crazy ideas:
Last updated: Jun 16 2026 at 16:19 UTC