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")
  }

TinyGo was instrumental in getting https://github.com/rcarmo/go-rdp to work. It generates very tight, pretty high performing WASM, and that allowed me to push all the RDP decoding to the browser side while making sure I had a sane test suite. Heartily recommended.

We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.

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

Could we compile tailscale with tinygo to run it on openwrt? Last time I checked tailscale was too large for 8MB flash routers

What are the tradeoffs compared to standard Go?

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?

Does it support ESP32

Its a fantastic project, but seems almost inactive now. I have a tiny PR pending for weeks, even reviewed, but not merged. I have another patch I have not submitted as I want to first navigate the earlier PR to completion. Both were bugs that bit me, and I ended up wasting quite a lot of time trying to find it:

1. go:embed supports "all:<pattern" while tinygo silently ignore it. I ripped my hair out trying to figure out why my files were not showing up in embedfs. PR pending.

2. go allows setting some global vars at the build cli (think build version/tag etc). In the code, one can define a default, and then the value provided (if any) on the cli can override it at build time. Tinygo fails to override the value at build-time, silently, if a default value is provided for the var in code. This PR I have not submitted yet, as its more intrusive.

I hope it picks up steam again soon. I love using go for embedded and CF worker use and tinygo makes both of these use cases much more viable than regular go. Honestly, I hope tinygo can be rolled over into the main go toolchain as "target arch".