blu (Sep 19 2026 at 02:23): blu (Sep 19 2026 at 02:23):I was working on kai and read this excellent Matklad article where he shares this:
I've been using zig build as my test/workflow/CI/check runner, and I think it's really cool that zig built build.zig.zon as a pseudo language for managing their own projects. This way, everything can be in Zig and really simplify environment setup and reduce accidental complexity and drift. In the spirit of John Carmack's "The tool you are already using is enough"
I think it would be really cool if Roc had something mirroring Zig's concept, a build.roc.ron format where you can just write all your project-level commands. We could basically just do it the way Zig did it, but it would be easier to read because it's Roc :D I started prototyping this here for eventual use in Kai.
I've also been maintaining a tidy.roc script which allows me to maintain a set of invariants that I can run against my code, like requiring tests for every plugin for example and have found this really helpful.
For the tidy.roc concept, that one is a bit tougher to think about how to codify into a useful general package, but figured I'd share something that's been bringing lots of value to me, especially enforcing standards on the ever-drifting agents.
Let me know what you think about whether this idea is worth pushing further!
Luke Boswell (Sep 19 2026 at 03:03):My roc pandoc package uses Roc for everything https://github.com/lukewilliamboswell/roc-pandoc/tree/main/scripts
I will eventually migrate everything to Roc I think, but it's not as high a priority for me as getting major bugs fixed and cutting releases.
Luke Boswell (Sep 19 2026 at 03:04):I would think it is a goal for Roc to be competitive for scripting like this... so if anyone finds any friction it would be great to know about it.
Richard Feldman (Sep 19 2026 at 03:30):yeah I'm cautiously interested in this, but I would definitely want it to be .roc and not .roc.anythingelse :smile:
Richard Feldman (Sep 19 2026 at 03:31):one thing I would very much want to avoid is any expectation that these would get run during package or platform installation
Richard Feldman (Sep 19 2026 at 03:31):it's very important that we maintain an invariant of "installing packages is free of side effects and cannot possibly be used as a malware vector"
blu (Sep 19 2026 at 13:13):Yeah I thought the .zig.zon was interesting, I'm sure there was some esoteric reason I didn't understand why that was done.
one thing I would very much want to avoid is any expectation that these would get run during package or platform installation
Makes sense to me. No bootstrap process then for roc build.
blu (Sep 19 2026 at 17:20):My roc pandoc package uses Roc for everything https://github.com/lukewilliamboswell/roc-pandoc/tree/main/scripts
@Luke Boswell Curious how the dev experience has been for you using that compared to other repos using different things for scripting/testing/CI etc.
Luke Boswell (Sep 20 2026 at 09:35):It's hard to be objective because I'm so involved with everything, and this was my first package where I've used Roc for scripting... I probably spent more time golfing and trying different permutations of things. I wanted to explore a few different ideas here. I was also trying to validate or road test some of the recent changes for basic-cli.
Looking back and comparing with my python scripts I think using Roc is very favourable.
What I like about is are the types and how easy it is to re-use helpers. I don't need a task runner, I've got thin apps sharing common Modules for the workspace. I suspect this will be more maintainable and I think it's easier to follow.
I would say there is still lots of experimentation to do in this space, but I am pretty confident from our experience last time around with the first version of Roc it will be really nice.
Last updated: Sep 24 2026 at 15:59 UTC