We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
evacchi 2 hours ago [-]
Yay wazero maintainer here, thanks for the shout-out!
pancsta 29 minutes ago [-]
It was good to meet at wasm.io!
apitman 2 hours ago [-]
Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
mi_lk 1 hours ago [-]
What are the tradeoffs compared to standard Go?
tatjam 3 hours ago [-]
Writing embedded code with an async-aware programming language is wonderful (see Rust's embassy), but wonder how competitive this is when you need to push large quantities of data through a micro controller, I presume this is not suitable for real-time stuff?
carverauto 3 hours ago [-]
We're streaming RSTP camera feeds through WASM plugins and host-bridge adapters, no problem. I was surprised how well it worked TBH.
You can disable GC in tinygo, so if you allocate all the necessary buffers beforehand it can have good performance with real-time characteristics. If you _need_ dynamic memory allocation then no, because you need GC it can't provide realtime guarantees.
Groxx 34 minutes ago [-]
Doesn't seem like those should be mutually exclusive, though the habits involved are quite opposing and I can definitely believe they're uncommon.
E.g. GC doesn't need to be precise. You could reserve CPU budget for GC, and only use that much at a time before yielding control. As long as you still free enough to not OOM, you're fine.
clktmr 2 hours ago [-]
I've written a fair amount of code for EmbeddedGo. Garbage Collector is not an issue if you avoid heap allocations in your main loop. But if you're CPU bound a goroutine might block others from running for quite some time. If your platform supports async preemption, you might be able to patch the goroutine scheduler with realtime capabilities.
randusername 2 hours ago [-]
Can you elaborate on this and how it would be different from signaling on interrupts and DMA?
Hardware-level async makes sense to me. I can scope it. I can read the data sheet.
Software async in contrast seems difficult to characterize and reason about so I've been intimidated.
It does indeed produce much smaller binaries, including for macOS.
[0] https://github.com/tinygo-org/tinygo/issues/4880
[1] https://github.com/Nerzal/tinywebsocket
https://code.carverauto.dev/carverauto/serviceradar/src/bran...
E.g. GC doesn't need to be precise. You could reserve CPU budget for GC, and only use that much at a time before yielding control. As long as you still free enough to not OOM, you're fine.
Hardware-level async makes sense to me. I can scope it. I can read the data sheet.
Software async in contrast seems difficult to characterize and reason about so I've been intimidated.