Stream: show and tell

Topic: roc-ecs

view this post on Zulip Trevor Settles (Oct 08 2026 at 20:08):

Inspired by RocRay and Bevy, I've made an Entity Component System (ECS) implementation. I'm still working on it, but the core is there.
It uses Roc's type inference so that you can store arbitrary types of components in a single type of Archetype. All the components are stored as:

[
    Positions(List(Position))
    Healths(List(Health))
    ...
]

This allows each archetype to hold many columns of components that can then be joined at runtime, so everything is densely packed.

Each ECS world is split in two:

Right now, I've got an adapter for RocRay, but in theory it should be able to work with other IO, I just haven't tried it yet. Since Roc doesn't have concurrency yet all the systems are just World -> World, but once I can add some parallelism, I might consider changing that type.

Claude built a fun little Asteroids clone that runs at 100+ fps, so the performance isn't awful.

Also, whats the story for a package like the RocRay adapter that depends on a specific platform, uses types from it, but could also be used in other projects? Would I need to make a new platform that wraps RocRay, and exposes the adapter/ECS?

view this post on Zulip Aurélien Geron (Oct 08 2026 at 20:55):

Cool! I believe there were some discussions about packages that depend on a platform, I'll try to find them.

One option is to keep your package platform-agnostic by requiring a record containing the platform functions you actually need. The user would be responsible for choosing the platform, importing the relevant functions, and passing them to your package.

view this post on Zulip Aurélien Geron (Oct 08 2026 at 22:22):

Here's a PR that reorganizes roc-ecs into a more standard structure. I've removed the explicit dependency between RayEcs.roc and the roc-ray platform by making it produce commands rather than directly using roc-ray. The upside is that this now a regular pure package. The downside is that the user must add a little mapping function to actually execute the commands. It's arguably not a big price to pay to make the library totally independent of the underlying platform.
Note: perhaps it would be cleaner to hand the effectful functions directly to RayEcs at initialization time, so it can call the functions directly rather than producing commands, but it was easier to implement commands because I didn't have to worry much about the type of the effectful functions. There's probably room for improvement there.

view this post on Zulip Aurélien Geron (Oct 08 2026 at 22:28):

After reviewing and merging the PR, prepare a release like this:

cd package
roc bundle main.roc

Then create a new release on github, create a new tag (e.g., 0.1.0), give it a title (e.g., 0.1.0), describe the release, attach the *.tar.zst file created above, and publish the release. You can then replace "../package/main.roc" in the examples with the URL to your release: this makes it easier for people to try out an example without having to download your whole project.

Of course this can (should) all be done by CI. Check out some other packages for inspiration (e.g., roc-lang/unicode worklows).

view this post on Zulip Karakatiza (Oct 08 2026 at 22:40):

Is the recommended flow for releasing Roc packages described somewhere in a public doc? Or is it only an implicit convention across major contributors for now?

view this post on Zulip Trevor Settles (Oct 08 2026 at 22:52):

Sweet, thanks for that! I admit, I had no idea on how to release roc packages

view this post on Zulip Aurélien Geron (Oct 09 2026 at 05:24):

Karakatiza said:

Is the recommended flow for releasing Roc packages described somewhere in a public doc? Or is it only an implicit convention across major contributors for now?

That's a great question, I couldn't find such docs, I think it's mostly implicit convention (but I may be wrong). I believe there were some discussions in the past about adding a roc init command to create new packages or platforms, but I think that effort was paused.

In any case, I've released a template for pure Roc packages, see this topic.

view this post on Zulip Anton (Oct 09 2026 at 12:42):

Karakatiza said:

Is the recommended flow for releasing Roc packages described somewhere in a public doc? Or is it only an implicit convention across major contributors for now?

We also have a github action to help with this: https://github.com/roc-lang/release-package

view this post on Zulip Aurélien Geron (Oct 09 2026 at 20:30):

I just integrated roc-lang/release-package into the template.

Last updated: Oct 15 2026 at 17:56 UTC