Go on Embedded Systems and WebAssembly

 (tinygo.org)

163 points | by uticus 17 hours ago

7 comments

  • nasretdinov 16 hours ago
    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")
  }
  • carverauto 15 hours ago
    We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
    [-]
    • evacchi 15 hours ago
      Yay wazero maintainer here, thanks for the shout-out!
      [-]
      • pancsta 13 hours ago
        It was good to meet at wasm.io!
    • apitman 15 hours ago
      Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
  • pancsta 13 hours ago
    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 12 hours ago
    Could we compile tailscale with tinygo to run it on openwrt? Last time I checked tailscale was too large for 8MB flash routers
    [-]
    • mayama 8 hours ago
      Lot of stdlib, especially net, crypto, in tinygo doesn't compile, or if compiles has stubs as implementation that panics with not implemented. Few years ago, I tried compiling small terminal http client app and failed at compile stage.

      https://tinygo.org/docs/reference/lang-support/stdlib/

  • mi_lk 14 hours ago
    What are the tradeoffs compared to standard Go?
    [-]
  • tatjam 16 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 15 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.

      https://code.carverauto.dev/carverauto/serviceradar/src/bran...

    • nasretdinov 16 hours ago
      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 13 hours 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 15 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.
    • soypat 8 hours ago
      It is more performant than rust but less performant than Zig when not doing GC heavy stuff. https://github.com/tinygo-org/tinybench
    • randusername 15 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.

      [-]
      • jamesmunns 1 hour ago
        It's really not so different! In embassy, DMA transfers and interrupts become things that you can .await on, the process is basically:

          * The software starts a transaction, or triggers some event (like putting data in the fifo)
  * The software task yields
  * When the "fifo empty" interrupt or "dma transfer done interrupt" occurs, it wakes the task to resume
  * the software task checks if it is done, and either reloads/restarts if there's more to do, or returns "done"
        It's really not different than event driven state machines you would have written before, it's just "in-band" of the language now, and async/await gives you syntax to do it.

        Even if you don't know Rust, I'd suggest poking around at some of the examples here:

        https://github.com/embassy-rs/embassy/tree/main/examples

        And if you want, look into the code behind it.

  • febed 5 hours ago
    Does it support ESP32
    [-]