what if the roc CLI had a roc init feature?
here's an idea for how it could work:
roc init examples/cli/main.roc (in the future the platform can be described by a package repo name instead of a local file path) and it prompts me for the name of the app I want to create, then creates that directory on the filesystem.init function which sets things up - e.g. creates an app module named main.roc in the specified directory, whose contents might (for example) do a "Hello, World!" equivalent for that platform.roc init command prints either an error message if the platform's init failed (e.g. due to a filesystem permissions issue) or else some instructions for what to do next (e.g. "I've created a Hello World example; here's how to run it"), and returns an exit code based on whether init succeeded or failedthis way, in the instructions for getting started as a beginner, we could say something minimal like "to get started making a command line app, run roc init examples/cli/main.roc and it will guide you through the process."
and then that guidance would also work for other platforms, e.g. @Brian Carroll's static site generator!
that’d be really helpful for rbt as well!
here's a more specific design idea: the platform provides a function like
init : Str -> Effect (Result { instructions : Str, files : Dict Str (List U8)) } Str)`
and then it either creates the files specified by the Dict Str (List U8) (mapping filenames to contents) and prints the instructions message and exits 0, or else it prints the error Str and exits with some nonzero exit code
this would mean that platforms which don't know how to write to the filesystem or print to stdout (e.g. they're targeting database extensions or text editor plugins or something and don't even want to link libc) still have an easy way to provide roc init functionality by using the roc CLI's ability to do those things
but also since it's an Effect, they can do additional setup stuff if they need to, which includes prompts to read from stdin if desired
that API would probably need to change in the future to accommodate an editor-based init workflow, but I think it's ok to figure that out later
I'm a little confused by the mixing of CLI-defined effects and platform-defined effects, but it sounds very useful
As I fiddle with some Roc, it occurred to me that good DX points could be gained if we offer roc init CLI command that would start scaffolds for new files.
I am sure we could make it very complicated but my needs would be covered by roc init app some-path/app-name and roc init mod some-other/modulename where it would create app-name.roc and modulename.roc files with basic header already setup.
I agree, it would be nice. There is an older thread with a link to a related issue https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Subcommand.20for.20generating.20a.20new.20main.2Eroc/near/409070829
I'm not as fond of roc init as I used to be. It's not very discoverable and copying an example from somewhere is extremely simple.
I'm in favor of the idea as another selling point for the "friendly" in "fast, friendly, functional". Some thoughts on what might be cool:
roc init -> scaffolds hello world, informs user of file write side effect (same behavior as cargo and zig init). cargo just does minimal hello world while zig does more to help out new users by explaining common patterns like arena allocation and demonstrates basic tests with lots of explanatory comments. Also interesting to note it defaults to name the package whatever dir you're currently in.
roc init app <path>/<name> -> scaffolds hello world but with <name> at <path>. Uses default generic platform by default.
roc init app <path>/<name> --platform <platform> -> scaffolds hello but with chosen platform URL or local path (perhaps could have aliases for common ones like basic-cli?)
roc init platform -> scaffolds hello platform. A platform scaffolder with lots of explanatory comments would actually be extremely useful for me, I just tried my hand at building one and there's just so much going on at so many layers of the stack that I'd have felt hopeless without an LLM to explain things haha. Could even have examples for the most common use cases like DSL creation etc.
Last updated: Aug 12 2026 at 12:35 UTC