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
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
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.
carverauto
We're streaming RSTP camera feeds through WASM plugins and host-bridge adapters, no problem. I was surprised how well it worked TBH.
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
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
We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
evacchi
Yay wazero maintainer here, thanks for the shout-out!
apitman
Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
mi_lk
What are the tradeoffs compared to standard Go?
jrockway
It gets better every release, but there are missing language features:
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
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
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.
carverauto
We're streaming RSTP camera feeds through WASM plugins and host-bridge adapters, no problem. I was surprised how well it worked TBH.
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
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
We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
evacchi
Yay wazero maintainer here, thanks for the shout-out!
apitman
Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
mi_lk
What are the tradeoffs compared to standard Go?
jrockway
It gets better every release, but there are missing language features:
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.
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?
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.
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...
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.
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.
We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
Yay wazero maintainer here, thanks for the shout-out!
Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
What are the tradeoffs compared to standard Go?
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/
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
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.
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?
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.
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...
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.
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.
We're using TinyGo and the Wazero runtime for our WASM plugin system in ServiceRadar, highly recommend both if you're using golang.
Yay wazero maintainer here, thanks for the shout-out!
Wazero is awesome. For anyone wanting to embed in languages other than Go, check out Extism.
What are the tradeoffs compared to standard Go?
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/
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