Or zig build platform && add-instrumentation-layer && roc build && roc run | connect-effect-devtools
Insert a thin layer or wrapper between the host and roc, and automatically instrument the effects.
I think building a seperate zig toolchain layer is the way to go... and then if it proves itself to be invaluable to most devs, can then later just import it into the roc compiler itself, if desired. Although seperation could be nice for keeping things modular & minimal. Although roc would have the additional advantage of knowing about the platform's usage, maybe there is more useful information at that point.
And then with the information, one could build devtools & visualisations... and perhaps make something similar to redux-devtools & redux-saga-devtools...
In theory, this doesn't need to be built into the roc compiler itself, one could build a seperate buildchain tool that... takes a libhost.a, inspects the exposed functions, and then applies the same instrumentation logic as a thin wrapper. libhost.a -> libhost-with-effect-devtools.a
The host does the mallocs, so only the host knows about the current true app state.
But it could be inferred, from the calls.
And in addition, only the host knows about it's own additional private state & effects.
However... if one were to add a thin instrumentation layer...
One could monitor how many effects were called, which effects, how long they took.
And specifically for the mallocs, we could also infer what was app memory allocated, how much for how long etc.
From this information, one could make devtools like... "redux-devtools" and "redux-saga-devtools".
The key point, is that it would be automatic, and still very useful to app developers, no need to manually instrument the functions, and it would contain enough information to be very useful for application developers.
roc_send_http_request was called 200 times... what does a waterfall chart look like for that?
Can I replay & inject an effects? Can i send & inject mock effects to the app? etc. And this will only get increasingly more useful, as concurrency lands.
"These three http requests could be done concurrently."
"Oh wow, we seemed to be blocked waiting for this one specific very slow http effect... to complete."
What about roc_malloc, can we inspect/track those and render a linear memory visualisation...
But obviously, it's not a complete picture of the entire app... platform specific runtime information would still be missing... and platform devs would need to provide their own intergrated dev-tooling for that...
And chrome devtools, also exist... so maybe some value to get from that also, connect to it... like you would with nodejs.
I've spent a long time trying out different things... and my favourite approach I've landed on is what I've been calling an "observatory" which dumps to a sqlite db
Here is the docs for roc-ray's implementation https://github.com/lukewilliamboswell/roc-ray/blob/main/docs/observatory.md
From my experience I feel that it's best when it is heavily tailored for on specific platform
I have this dream of building a web app using basic-webserver and the datastar library to build exactly the app flamegraph concept. All the data is there now in a nice schema, but I've been distracted working on other things so far.
I've been waiting for a fix to land in a nightly and I plan to punch out a new release for roc-ray very soon. It could probably happen now, but I haven't looked at it for a couple of days.
This next release is very big on the feature front, so I wanted to put some release notes together to share with people.
Yeah, fair enough... chrome... has many web specific tools... inspect element etc.
Only a few tabs are generic to all application types.
First time i've seen datastar... looks like a great... frontend library?
I ported all the examples from the Datastar website to Roc in https://github.com/roc-lang/basic-webserver/tree/main/examples/datastar
Last updated: Sep 24 2026 at 15:59 UTC