Hi, in this conference (https://www.youtube.com/watch?v=6qzWm_eoUXM), @Richard Feldman shows an example of a possible webserver platform. Is the source code of this example platform available online to play with?
I don't have any background with Rust / Zig (find the syntax not very friendly), but I would like to try a bit and learn by this way (I'm a golang dev, but sadly it won't be possible to write platform with it, or will it be?)
Thank you for your amazing work
I think a few toy web platforms have been made over time. Not sure which was used for the talk (need to re-skim the talk to maybe figure out).
As for golang: It could be used as a host language since it does support cffi. That being said, I don't think it is a good host language. go does cffi poorly and it ends up having a lot of overhead. Go would also potentially have a hard time making Roc types due to not really being a low level systems language. Also, not sure how the GC would behave assuming you want it to automatically deal with Roc refcounts.
I don't remember where that one was either - honestly it was super hacked together and not a great foundation anyway :big_smile:
that said, I'd be totally happy to help if you'd like to tackle getting a real webserver platform up and running!
We also now know more about dealing with async rust so probably could build something even nicer. That being said, staying in the land of synchronous effects makes life easier for implementation.
Tangentially, do we have some high-level non-committal table/checklist of things Roc can / kind of can / can't do currently? "Async is hard today for platforms" is great to know, so I'm curious if there are other synopses like that.
I think as glue becomes more and more complete, it is greatly changing that picture. So that will be huge for all things platforms
If there was a small POC of a webserver handler platform, it would be a big help to guide me as a true beginner in platform author (+rust dev). Sorry for me empty background, I only have the motivation with me :sweat_smile:
sure! is there a low-level language you'd be more comfortable in than Rust? (e.g. C, C++, Zig)
I've done 3 years of C/C++ but it looked nothing like I've seen in platform examples :thinking:
I wanted to learn Rust, it would be a good opportunity (if it doesn't bother you as it seems platform should be written in Zig)
I probably wrote the most developed rust web platforms so far, but they are quite messy and probably not the best to learn from. They were first hacks into the world of async rust. Also, I ran into a compiler bug that made me have to structure some code weirdly. Also, learned a number of things about rust async after coding them up that would have made the rust side much nicer.
https://github.com/bhansconnect/roc-async
https://github.com/bhansconnect/roc-todos
So well these may not be too helpful, i would be willing to help make a better base for someone to build off of.
It's potentially true that the primary Go toolchain would not work well for building a Roc host, though the Go project also officially maintains gccgo as an alternative implementation, both to aid novel uses of the language, and to ensure the language specification is respected (much as Python does with CPython and Jython), rather than risk specification-by-implementation via a sole implementation.
gccgo is a language frontend for gcc, and thus interoperates with C ABI things with no additional overhead. If you can get gcc to compile a C object that you can link with Roc, or vice versa, then you should be able to with Go as well via gccgo, and thus Go may be a reasonable host language for Roc.
anyone thought about what a BEAM-like (or even better, BEAM-hosted) platform would look like?
For go, i don't think that gccgo would significantly help with Roc interop. Gccgo still follows the go spec. This means that it has a lot of constraints due to runtime, GC, and how it decided to implement certain structures. Of course you can always do go -> c -> roc, letting c deal with all the low level details and types. I just don't think it would be very ergonomic.
Also, the gccgo docs advise against using is limited c interop. They push for use of cgo.
Anyway, in general, i think it should be possible, but i don't think it would be ergonomic. I also think there is a good chance that it would lead to a lot of extra annoyance around memory management and copying data that may significantly hurt performance.
I know that Erlang/BEAM Supports C ABI, but I have no idea how any of that would work.
I've been thinking a little about BEAM interop with roc as well. I think it would be possible to get quite far with rustler. I may look at that soon-ish
https://www.reddit.com/r/rust/comments/113dp70/ractor_not_just_another_actor_framework/
instead of using a BEAM platform, might be worth while to look at one that could by built with the ractor rust frame work.
it was developed by a lot of the erlang devs who worked on whatsapp at meta.
Interesting, I do love actors :)
I'd like to use them for plugins for the roc editor
Last updated: Jul 05 2025 at 12:14 UTC