Suppose I want to implement an in-memory cache for an append-only DB table. I might pre-populate it at startup, but after that it will query the database for a value after checking a hashmap, updating the hashmap if the value is found.
Is there a way to do this in pure Roc without a bunch of cloning? My understanding is that I'd need to keep the refcount at 1, and I'm not sure how easy/hard that would be. Would it be more straightforward or otherwise better to implement this in the platform host?
Context:
I need a mapping of account numbers, inventory locations, etc. to TigerBeetle Account IDs (128-bit int). My plan was to create an entry in postgres every time we add an account with appropriate metadata. However, we'd need to cache those mappings in memory to avoid bottlenecking TigerBeetle.
Additional context: This would be in a web server platform, so potentially multiple request handlers would need access to the cache simultaneously.
In basic-webserver we integrated Sqlite for in-memory storage, so that is something the platform provides. (It hasn't been ported to the new zig compiler yet though so there isn't a release or demo I can give you).
Yeah, SQLite could work too. I guess my main question is whether it's possible to do this in pure Roc (efficiently) or whether it needs to be done by the platform
In pure Roc things like lists are reference counted in memory automatically (or you can manually Box also to heap allocate), so this is efficient for in-memory caching.
If you are wanting to have multiple threads or concurrency I think you will need to have the platform support the specific use case as it is very context dependent.
That makes sense. I totally forgot about Box. That would be my way to get a pointer to pass around :sweat_smile:
I was thinking I'd have a Dict of potentially tens of thousands of k,v pairs, so wanted to be sure to avoid copying
I feel like you will be able to pass a Dict around efficiently ... but I'm a bit fuzzy on the details
How you do that exactly to avoid copies is probably more advanced I guess. We talked previously about having tooling that can help you identify where a copy might happen in your code, but it was a long time ago and I can't remember much about it.
Passing a Box Dict or a Dict is no different here except that Box is less convenient. Both with pass by pointer rather than coping (Dict just passes a pointer and two u64s instead of one pointer). Both will mutate in place if the refcount is one. Both will duplicate the entire underlying data if the data is mutated with more than 1 reference.
I'm not sure the state of Box optimization in the zig compiler. But hopefully it would actually mutate in place.
Box is already implemented and working well as far as I know
In the case above I think the muplte request handler requirement likely will lead to needing to rely on sqlite though. Otherwise you won't be able to update in place. I don't think basic webserver exposes any way to update globally shared state. With some sort of centralized command architecture you could do it.
Are there any plans for roc to have built in actors or at least something like atoms?
Just a thing to hold a state, you give a function to get a new state, and you can retrieve the state - thread safe would be amazing :)
I love actors, I think the plan was to keep those kinds of things on the platform side until we find a compelling reason why we should not do that.
It makes sense that it would need to be part of the platform via SQLite or something else since its basically shared mutable state.
Not sure how i forgot that a Dict was a pointer anyway but clearly it happened :sweat_smile::upside_down:
I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements
I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements
FYI, I'm planning to start implementing #off topic > New Perceus algorithm alternative just dropped soon, which should dramatically decrease the number of refcounts that are happening (no idea how long it will take to add though!)
Richard Feldman said:
I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements
FYI, I'm planning to start implementing #off topic > New Perceus algorithm alternative just dropped soon, which should dramatically decrease the number of refcounts that are happening (no idea how long it will take to add though!)
Is it already in :eyes: ?
https://github.com/roc-lang/roc/pull/9595
https://github.com/roc-lang/roc/pull/9604
Yes... :grinning_face_with_smiling_eyes:
Last updated: Jun 16 2026 at 16:19 UTC