5 ms·

Have you looked into using TinyGo[0]? It's a Go-for-embedded compiler and can compile Go to WASM as well. It's supposed to result in much smaller artifacts. [

Have you looked into using TinyGo[0]? It's a Go-for-embedded compiler and can compile Go to WASM as well. It's supposed to result in much smaller artifacts. [0]: https://tinygo.org/docs/guides/webassembly/ https://tinygo.org/docs/guides/webassembly/

TobyTheDog123 4y ago
In my experience, TinyGo is far from ready for prime time, mainly because of its lack of support for JSON marshaling/unmarshaling. I run Go code in Cloudflare Workers, and just use the regular-ol' WASM targets (GOOS=js/GOARCH=wasm)
- oefrha 4y ago
  Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.
thefounder 4y ago
I'm using a lot of reflection and I believe tinygo has had some issues with the reflect package. I'm not really ready to dig into Tinygo issues. I've spent a lot of time dealing with Go's own reflect issue(i.e [0]) in its default implementation. https://github.com/golang/go/issues/15924 https://github.com/golang/go/issues/15924
- TachyonicBytes 4y ago
  TinyGo does indeed have problems with the reflect package, as well as many others, one which I've managed to help with [1]. The developers have been very helpful, but the reflect package is still a big missing piece. Your framework sounds interesting. Do you develop it in the open? [1] https://github.com/tinygo-org/tinygo/issues/3274 https://github.com/tinygo-org/tinygo/issues/3274
  - euroderf 4y ago
    Lack of reflection also creates issues for (for example) XML decoding, but I found that it's possible to delete reflection code from the source and compile it with basic decoding support. No annotations - but this is OK because Go's XML annotations are evil.

TobyTheDog123 4y ago

In my experience, TinyGo is far from ready for prime time, mainly because of its lack of support for JSON marshaling/unmarshaling. I run Go code in Cloudflare Workers, and just use the regular-ol' WASM targets (GOOS=js/GOARCH=wasm)

oefrha 4y ago
Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.

thefounder 4y ago

I'm using a lot of reflection and I believe tinygo has had some issues with the reflect package. I'm not really ready to dig into Tinygo issues. I've spent a lot of time dealing with Go's own reflect issue(i.e [0]) in its default implementation. https://github.com/golang/go/issues/15924 https://github.com/golang/go/issues/15924

TachyonicBytes 4y ago
TinyGo does indeed have problems with the reflect package, as well as many others, one which I've managed to help with [1]. The developers have been very helpful, but the reflect package is still a big missing piece. Your framework sounds interesting. Do you develop it in the open? [1] https://github.com/tinygo-org/tinygo/issues/3274 https://github.com/tinygo-org/tinygo/issues/3274
- euroderf 4y ago
  Lack of reflection also creates issues for (for example) XML decoding, but I found that it's possible to delete reflection code from the source and compile it with basic decoding support. No annotations - but this is OK because Go's XML annotations are evil.