roc platform templates · show and tell

Just wanted to share an update for platform template repositories. Mostly copied from platform-switching examples for now. The idea is to have a more idiomatic example using the host language ecosystem e.g. build.rs, or build.zig etc.

https://github.com/lukewilliamboswell/roc-platform-template-go
https://github.com/lukewilliamboswell/roc-platform-template-swift
https://github.com/lukewilliamboswell/roc-platform-template-zig
https://github.com/lukewilliamboswell/roc-platform-template-rust
https://github.com/lukewilliamboswell/roc-platform-template-c

I figured it would be useful to share what I have so far, however there are a couple of changes I would like to make in the short term;

update to an API of main : Task {} [Exit I32 Str]_ instead of main : Str as that will be more useful as a starting point, and also to include an example effect in the host.
update the build script to support surgical linking. At the moment only the rust template has this. This should be straight forward; we build the app into a dynamic library first, and then build the host loading the app as a dynamic library instead of linking with a static library, so we can pre-process the executable for the surgical linker.

Things I think will be helpful in the medium/long term;

include a std library implementation for e.g. RocStr, RocList for these languages
develop the glue scripts to generate the types for a specific platform, I'm currently thinking a package with common data structure and functions will also be helpful here... though this needs further investigation. Another idea is to first transform the glue types provided by the compiler into an intermeditate representation and then code gen the source, which should be much easier to test and maintain.

Luke Boswell (May 18 2024 at 13:29):

Another idea -- add example github actions for packaging and docs

Luke Boswell (May 18 2024 at 19:08):

I've updated the zig platform to use a Task based API now.

If anyone with some Zig experience is able to cast their eyes over it, that would be appreciated.

Maybe @Silver you are interested?

Damian Reeves (May 18 2024 at 22:43):

Ia there a reason why the roc examples shows JVM interop as opposed to a platform? What is the main distinction?

Luke Boswell (May 19 2024 at 04:19):

I haven't looked at that example (I haven't used Java before). But my guess is that for the JVM we need to have the host toolchain drive the linking. So we compile the roc app into an object first using roc build --no-link and then use the C header and FFI to call into roc.

Luke Boswell (May 19 2024 at 04:20):

That is a similar workflow to the roc-wasm4 platform, where we have zig control the build so we have finer control over the memory layout of the final .wasm library, but in this case it is so we can interop in a way that works for Java.

Luke Boswell (May 20 2024 at 06:11):

Some updates to the above;

Go, Zig & Rust Examples: We now re-generate glue files with each build. This is using a URL release of a new package lukewilliamboswell/roc-glue-code-gen, so we don't need to hard code these files. As we make improvements to the glue package this will automatically reflected in the generated files. For now, this is limited to hand-rolled roc_std implementation, next step is to generate the specific types for any platform.
Zig Example: build.zig now cross-compiles for all of the supported targets at once. This is a really nice experience when packaging the platform as we can bundle all the prebuilt-binaries from one machine. I haven't been able to test all of these combinations, but it looks like it should work, if you test this please let me know if it works for you.
Zig Example: build.roc uses -Doptimize=ReleaseSmall which gives small prebuilt-binaries. The whole platform/ folder is only 610KB in total size on my machine; this includes all of the binaries and platform source files.

Last updated: Jul 06 2025 at 12:14 UTC

Stream: show and tell