Go on Embedded Systems and WebAssembly

 (tinygo.org)

97 points | by uticus 5 hours ago

5 comments

  • nasretdinov 3 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 3 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 2 hours ago
      Yay wazero maintainer here, thanks for the shout-out!
      [-]
      • pancsta 51 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.
  • pancsta 59 minutes 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

  • mi_lk 1 hour 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.

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

    • nasretdinov 3 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 56 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.