I'm trying to make my first dummy platform in zig but the example in platform-switching/zig-platform
doesn't compile for me.
My zig version
is 0.10.0-dev-3685
.
Maybe I'm too far in the future, but what do I need to build a platform? Is it written somewhere?
I think we are still zig 0.9.0
We're on 0.9.1
Upgrading to 0.10 is a big job and work is ongoing.
Trying to work out if this is a bug, or something wrong with my config. I'm on M2 MacOS 12. When I run the example zig platform in Nix shell I get the following.
$ roc run rocLovesZig.roc
🔨 Rebuilding platform...
An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: https://github.com/roc-lang/roc/issues/new/choose
thread '<unnamed>' panicked at 'cannot find `str.zig`. Check the source code in find_zig_str_path() to show all the paths I tried.', crates/compiler/build/src/link.rs:217:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'Failed to (re)build platform.: Any { .. }', crates/cli/src/build.rs:332:46
did you build from source here? or download the binary?
I've built from source
I suspect you need to run roc
from the top-level directory of the repo
That does it. Thank you.
Can you file an issue for this? I thought we fixed roc so that directory of execution shouldn't matter as long as roc and the lib dir are together.
I revisit Roc every few months and start writing a platform + host in an empty folder. I generally alternate between Zig and C when doing this.
My ultimate hope is that the compiler will check for missing symbols in the host / platform, let me use my own build setup for the native code, and just figure out what I'm missing to be a complete platform and give me nice errors.
I have seen this "An internal compiler expectation was broken." many times in this process, and I hope Roc will take "platform from scratch" as a serious usecase and work towards making this a nicer experience.
Imagine grabbing a roc binary, and trying to run it in an empty folder, it failing and looking for a platform, you create the platform roc files, then it fails with a further error, and you just keep using the errors to guide you towards a complete platform hello world.
Interesting. Hopefully some of the roc glue
changes will be landed soon. Then it will be possible to setup roc glue
for zig. That should really help with making platforms in zig.
Imagine grabbing a roc binary, and trying to run it in an empty folder, it failing and looking for a platform, you create the platform roc files, then it fails with a further error, and you just keep using the errors to guide you towards a complete platform hello world.
I am not sure if this workflow will ever be a target use case. Not to say we shouldn't have good guides for it. Just that an end user downloading Roc would likely be pushed towards application development and not platform development.
For most users, a platform will just be a url that roc can grab some precompiled executables from.
Brendan Hansknecht said:
Imagine grabbing a roc binary, and trying to run it in an empty folder, it failing and looking for a platform, you create the platform roc files, then it fails with a further error, and you just keep using the errors to guide you towards a complete platform hello world.
I am not sure if this workflow will ever be a target use case. Not to say we shouldn't have good guides for it. Just that an end user downloading Roc would likely be pushed towards application development and not platform development.
Good guides is also fine, but I think it's important to consider the possible benefits of making platform development attractive too. Ultimately, the more people are trying out both sides of Roc, the more powerful and varied both platforms and libraries can be.
Hey, what's the state of platform dev in Zig currently ?
There are several Zig platform examples in the repo. Glue code generation is not done yet but work is underway.
Could you tell me more about glue ? I'm a bit confused on its purpose
Also given what you said, those that mean that I could write my own Zig platform right now ?
The Zig host program needs to pass Roc values into the Roc app and receive them back. If the Roc code contains user defined types then we need Zig descriptions for those types. And Zig functions to construct and access that data. That's glue code.
Yes you can but you need to manually write the glue code and it is not a very smooth process. In practice you will probably have to spend time fighting with calling conventions.
Platform development is not yet as smooth as app development and is not documented yet because there are a few projects going on to redefine how it works.
So I should wait a bit more before getting myself into it ?
Depends a lot on your attitude towards having an experience like that, I don't know you or your preferences.
If you are interested in digging into a lot of unknowns then maybe it's fun for you
If you want documents and to just get an app built then I'd say wait a while longer
Yeah I'd like to try actually !
Ok cool! There is another stream about platform development so I'd suggest asking more questions there when you need to. In the meantime start by looking at the examples in the repo!
Thank you, I found this person that has lots of Zig paltforms too https://github.com/lukewilliamboswell
Yeah Luke is active here on Zulip and there are a couple of other people too.
Yeah, we are always here and willing to help. Writing a zig platform today just requires some extra help to get the wiring to roc correct.
Smooth platform development is key to Rocs success, that's already clear at this point. Getting this part right will be decisive ..
For sure. Rust has the best story currently, but things are still early. Once some major platform changes land, I think a lot more effort will go into docs and glue that make platform development a lot clearer and smooth.
@Slazaa what kind of platform are you thinking about? Is it something to tinker and experiment with, or maybe you have a specific use case in mind? I may be able to share a link to a similar project :big_smile:
@Luke Boswell Yeah well I'd like to make a game dev platform, I saw that you made something with mach, that's super cool
Yeah I really enjoyed that experiment. Unfortunately it's not something easy to share at the moment with most people because you need to be comfortable using zig nightlies and updating zig dependencies regularly. Also there were a few workarounds to get it working with just simple List U8 between Roc and Zig. without zig glue it's harder to write those types manually and I still barely know Zig
After that experiment I had the idea of maybe exposing the WebGPU API to roc via Tasks maybe to configure shader pipelines etc from Roc. Just thought that might be a cool project with the potential for Roc to be able to make high performance cross-platform graphics.
I wonder how complex would be to implement a roc to spir-v compiler
If I understand correctly, spir-v is a compilation target and not really a platform.
So it would more be the case that we could utilize llvm to compile for spir-v (though I think it may be a special snow flake that is not the easiest to just compile for)
At that point, a platform in some other language that compiles to spir-v (or just loads and interacts with a spir-v binary) could be written
but I have very limited knowledge in this area
Brendan Hansknecht said:
If I understand correctly, spir-v is a compilation target and not really a platform.
You get it right. That would be awesome to have a spir-v compilation for a possible webgpu platform. It means gpgpu in roc or, in other words, roc for shaders. Just like https://github.com/EmbarkStudios/rust-gpu
It’s more about the @Luke Boswell idea above than about the thread in general
my gut feeling is that roc is really dynamic in terms of allocations and that won't go well (just thinking about how futhark was design because it targets this specific use case).
I am really confident that zig and mach combined with roc will be awesome in the medium to long term. Since my last mach experiment we've made a lot of progress with roc-gui and roc-wasm, so now we have all the parts to build a much nicer graphics platform. There are a few other things on my list I'd like to do before I revisit this idea, but it's definitely something I'm looking forward to trying out again. One really cool thing I like about zig platforms is how easy it is to build a roc package url with all the artifacts for multiple architectures using zig cross compilation.
Is Rust the only platform language right now with glue support?
Yes, though it's still a WIP.
There is a zig spec but it currently doesn't really do anything yet
crates/glue/src/ZigGlue.roc
It just generates the list.zig
, but should be easy to extend to the rest of the standard library
Last updated: Jul 05 2025 at 12:14 UTC