Go on Embedded Systems and WebAssembly
tinygo.org
tinygo.org
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")
} package main
import "fmt"
func main() {
fmt.Printf("Hello World!\n")
}
• 2581616B (2.5MB) → 1714560B (1.6MB) (with -ldflags="-s -w")
• 1531920B (1.5MB) → 753680B (0.7MB) (with upx --force-macos)
That said, a trivial “Hello World!” isn’t a meaningful benchmark. If you’re going to play that game, you might as well swap `fmt.Printf` for `fmt.Println`, or even `println` to avoid the import statement entirely. At that point, you’re no longer comparing anything interesting, the binaries end up roughly the same size anyway.
This isn't a fault of TinyGo itself, it is just targeting a space that doesn't really prioritize embedded but got picked up for that just because. But without fixing this Wasm ecosystem issue, compiling Go to Wasm will never be a real thing.
For WASI, check out WASI Preview 2, https://docs.wasmtime.dev/api/wasmtime_wasi/p2/index.html
The company I work for is just now upgrading its edge WASI support to wasip2.
The essence of your first comment is still correct. Lots of libraries aren't there.
Enough are there, however, for some pretty substantial projects.
https://tinygo.org/docs/reference/lang-support/
And parts of the stdlib that don't work:
If you are thinking that this is a way to support mainstream go programming, you will be sorely disappointed.
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.
https://code.carverauto.dev/carverauto/serviceradar/src/bran...
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.
* 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"
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.
I use that capability, for instance, in go-wspr [1] to get very nice low-jitter timing for frequency corrections.
https://tinygo.org/docs/reference/microcontrollers/
A few ESP32s on there.
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".
https://github.com/tinygo-org/tinygo/commits/dev/
Maybe the opposite thing is happening, whereby the maintainers are getting overwhelmed?
Consider joining the slack channel #tinygo-dev on gophers.slack.com and pinging them about the PR.