Richard Feldman (May 29 2024 at 06:33): Richard Feldman (May 29 2024 at 06:33):I've been thinking for awhile about how to revise the roc subcommands to be simpler and more obvious. Here's the design I'm currently thinking of:
dbg always does the same thing regardless of what command you use (that is, we no longer sometimes ignore it)expect always does the same thing regardless of what command you use, unless you explicitly added the --optimize flag (in which case it gets ignored)roc foo.roc (foo.roc is optional and defaults to main.roc) works the way roc run does today: it always runs foo.roc even if there are compile-time errors. In the future, we have a platform-specific concept of "this platform supports 'watch mode' with hot reloading" (e.g. basic-webserver would support this but basic-cli would not); with this command, "watch mode" is always enabled when the platform supports it.roc build always builds the executable even if there are compile-time errors.roc dev and roc run (although later we may want to repurposeroc run for running scripts or something) Richard Feldman (May 29 2024 at 06:34):we used to have something closer to this, and we introduced roc dev based on the feedback that it was common to want to "only run once I've addressed all the compile-time errors" and prepending with roc check && to get that behavior was annoying
Richard Feldman (May 29 2024 at 06:34):however, that was before we had a language server and editor extensions!
Richard Feldman (May 29 2024 at 06:34):my thinking is that now, if you want to fix all your compile errors before running, you'll fix them in your editor anyway and won't be reliant on roc check to do that
Richard Feldman (May 29 2024 at 06:35):which means we can simplify the CLI subcommand structure
Kiryl Dziamura (May 29 2024 at 06:35):Possibly related issue: https://github.com/roc-lang/roc/issues/6637
Richard Feldman (May 29 2024 at 06:36):yeah, this design overlaps with some of that, except for the "flags" section
Luke Boswell (May 29 2024 at 06:39):Do you have any reasons why roc build should be happy to build even if there are errors?
Luke Boswell (May 29 2024 at 06:40):I really liked the idea of * Prioritise **safety** and **performance**, panic/crash at compile time for roc build.
Luke Boswell (May 29 2024 at 06:43):Do we want dbg in a "release" build?
Luke Boswell (May 29 2024 at 06:44):Same with inline expects, doesn't this slow down "release" builds?
Richard Feldman (May 29 2024 at 06:44):I'm assuming "release" builds would have --optimize
Richard Feldman (May 29 2024 at 06:44):I which would drop expects
Richard Feldman (May 29 2024 at 06:46):setting aside dbg for a moment, it's an interesting idea to have roc build default to --optimize because it does seem to be pretty common that people build Roc programs and forget to use --optimize
Richard Feldman (May 29 2024 at 06:46):e.g. when benchmarking things
Richard Feldman (May 29 2024 at 06:46):however, I'm not sure if in those scenarios people are actually using the roc build command :sweat_smile:
Luke Boswell (May 29 2024 at 06:53):My logic is that if you are building the app into an executable then it is because you plan to run it many times. -- so you care about performance and safety
Richard Feldman (May 29 2024 at 06:55):I'm also not sure how often in general people will be directly running roc build for releases as opposed to using something like a GitHub Action to do automate building for multiple targets etc. - and I'm sure those will use the appropriate optimizations because someone will report it if they forget and then it will be fixed for everyone
Luke Boswell (May 29 2024 at 06:55):As opposed to a script (or in a dev loop) where you want to build fast, and don't mind if the runtime is not as optimised.
Richard Feldman (May 29 2024 at 06:56):at Vendr we exclusively did roc build but it was through roc-esbuild and whether optimizations were enabled depended on whether it was a prod build
Luke Boswell (May 29 2024 at 06:56):Why wouldn't we default to --optimize? I may be missing something here... it's just that we ask the LLVM backend to run the full optimisations right?
Luke Boswell (May 29 2024 at 06:58):Or another way, you would use roc instead of roc build if you are not building a release?
Luke Boswell (May 29 2024 at 06:58):I'm interested to learn and explore this. I have very limited experience with this topic.
Luke Boswell (May 29 2024 at 06:59):The main motivation for my proposal was to simplify the subcommands and avoid the confusion between roc, roc run and roc dev which has come up a couple of times.
Richard Feldman (May 29 2024 at 06:59):if I'm using Roc to build a plugin for another system (e.g. an editor extension, or at Vendr a Node.js extension) then I'll only ever be doing roc build, including for development
Richard Feldman (May 29 2024 at 07:00):yeah I think we should do that either way (as noted at the start of the topic) - the question is just whether roc build should have the same default optimization level as all the other commands, or if it should be special
Luke Boswell (May 29 2024 at 07:00):In that case, you may want the dev backend and something else might be calling roc build and driving the linking etc... so that may be why we don't default to --optimise
Kasper Møller Andersen (May 29 2024 at 07:00):I think roc build also makes sense if you are compiling some application for your own use (e.g. some package you pulled from a Linux distribution)
Kasper Møller Andersen (May 29 2024 at 07:01):In which case you would also want to optimize
Luke Boswell (May 29 2024 at 07:03):I guess a similar logic for the CI/CD release applies there though. If roc build is being called by something else which is driving the process then it could also use --opt none or --opt size.
Kasper Møller Andersen (May 29 2024 at 07:06):I would also think it would be good to allow creating optimized builds still with inline expects kept. For example, if a customer is running your software, but runs into an issue, being able to hand them a build with expects in would be very useful as a way to help triangulate the problem.
Luke Boswell (May 29 2024 at 07:06):Richard Feldman said:
my thinking is that now, if you want to fix all your compile errors before running, you'll fix them in your editor anyway and won't be reliant on
roc checkto do that
Do we need to keep roc check then? it sounds like errors and warnings are going to be picked up by the language server, and/or at build time.
Richard Feldman (May 29 2024 at 07:11):CI will often want to run roc check I suspect
Richard Feldman (May 29 2024 at 07:13):and also I do think it's important that people have access to that locally if they don't have an editor set up (even if we assume that an editor setup will be the norm)
Richard Feldman (May 29 2024 at 07:13):importantly, I don't think roc check or roc build have ever been confusing
Richard Feldman (May 29 2024 at 07:14):the confusing part has been roc vs. roc run vs. roc dev - those are the ones I think should be collapsed into one command
Richard Feldman (May 29 2024 at 07:14):and I think roc with no subcommand is the best choice, in part because it's what many other languages do (e.g. it's python foo.py not python run foo.py) and also because that frees up roc run to be used for future script-running purposes
Richard Feldman (May 29 2024 at 07:18):also, separately I do like the idea of changing --optimize to --opt=speed vs --opt=size vs --opt=none (default), in part because it didn't occur to me until this discussion that --optimize is the American spelling, so it invites unnecessary annoyance for people who are used to the non-American spelling :sweat_smile:
Richard Feldman (May 29 2024 at 07:21):regarding whether dbg should be omitted from optimized builds, I have a concern that people maybe trying to debug something in a situation where optimization is a hard requirement (e.g. a part of a game that doesn't run fast enough to be playable without perf optimizations, or a binary that doesn't fit on an embedded device with limited memory unless size optimizations are always used) and then they just can't debug it
Richard Feldman (May 29 2024 at 07:21):or at least can't debug it using printline debugging, which is something I think should always be available!
Richard Feldman (May 29 2024 at 07:22):that said, I could see an argument for a --disallow-dbg flag which could be added to any command (roc build, roc test, etc.) for use in CI servers, so they could fail the build if any dbgs are left in
Oskar Hahn (May 29 2024 at 07:43):Would you consider, that calling roc (without a subcommand) starts the repl?
I don't have used python for a long time. But all the time, I want to do a small calculation or some filesystem manipulation in a loop, I call python, since it is the easiest way to start a repl.
When the roc repl gets the ability to run some basic Tasks, I think it will get very useful.
I think, the way python works, is intuitive. python starts the repl, python file.py runs the file. Maybe roc could do the same.
Last updated: Jun 16 2026 at 16:19 UTC