[HN Gopher] Go on Embedded Systems and WebAssembly
       ___________________________________________________________________
        
       Go on Embedded Systems and WebAssembly
        
       Author : uticus
       Score  : 110 points
       Date   : 2026-04-03 16:57 UTC (6 hours ago)
        
 (HTM) web link (tinygo.org)
 (TXT) w3m dump (tinygo.org)
        
       | nasretdinov wrote:
       | Tinygo made a lot of progress over the years -- e.g. they've
       | recently introduced macOS support!
       | 
       | It does indeed produce much smaller binaries, including for
       | macOS.                 yuriy@MacBookAir ~/t/tinygo> time tinygo
       | build -o test-tiny main.go
       | ________________________________________________________
       | Executed in    1.06 secs    fish           external          usr
       | time    1.18 secs    0.31 millis    1.18 secs          sys time
       | 0.18 secs    1.50 millis    0.18 secs
       | yuriy@MacBookAir ~/t/tinygo> time go build -o test-normal main.go
       | ________________________________________________________
       | Executed in   75.79 millis    fish           external
       | usr time   64.06 millis    0.41 millis   63.64 millis
       | sys time   96.76 millis    1.75 millis   95.01 millis
       | yuriy@MacBookAir ~/t/tinygo> ll       total 5096       -rw-r--
       | r--@ 1 yuriy  staff    74B  3 Apr 19:17 main.go       -rwxr-xr-x@
       | 1 yuriy  staff   2.3M  3 Apr 19:18 test-normal*       -rwxr-xr-x@
       | 1 yuriy  staff   192K  3 Apr 19:18 test-tiny*
       | yuriy@MacBookAir ~/t/tinygo> cat main.go       package main
       | import "fmt"              func main() {
       | fmt.Printf("Hello world!\n")       }
        
       | tatjam wrote:
       | 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?
        
         | nasretdinov wrote:
         | 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 wrote:
           | 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.
        
         | carverauto wrote:
         | We're streaming RSTP camera feeds through WASM plugins and
         | host-bridge adapters, no problem. I was surprised how well it
         | worked TBH.
         | 
         | https://code.carverauto.dev/carverauto/serviceradar/src/bran...
        
         | clktmr wrote:
         | 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 wrote:
         | 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.
        
       | carverauto wrote:
       | We're using TinyGo and the Wazero runtime for our WASM plugin
       | system in ServiceRadar, highly recommend both if you're using
       | golang.
        
         | evacchi wrote:
         | Yay wazero maintainer here, thanks for the shout-out!
        
           | pancsta wrote:
           | It was good to meet at wasm.io!
        
         | apitman wrote:
         | Wazero is awesome. For anyone wanting to embed in languages
         | other than Go, check out Extism.
        
       | mi_lk wrote:
       | What are the tradeoffs compared to standard Go?
        
         | jrockway wrote:
         | It gets better every release, but there are missing language
         | features:
         | 
         | https://tinygo.org/docs/reference/lang-support/
         | 
         | And parts of the stdlib that don't work:
         | 
         | https://tinygo.org/docs/reference/lang-support/stdlib/
        
       | pancsta wrote:
       | TinyGo doesnt have networking in WASI[0] and the WASM websocket
       | module[1] was last updated 5 years ago. Go without stdlib is not
       | Go.
       | 
       | [0] https://github.com/tinygo-org/tinygo/issues/4880
       | 
       | [1] https://github.com/Nerzal/tinywebsocket
        
       | jackhalford wrote:
       | Could we compile tailscale with tinygo to run it on openwrt? Last
       | time I checked tailscale was too large for 8MB flash routers
        
       ___________________________________________________________________
       (page generated 2026-04-03 23:00 UTC)