Hacker News Reader

Comment by kodablah | Hacker News Reader

Neat. I've always considered Go, with its (relatively) simple design and significant quantity of decent libraries to be very retargetable (I'm toying with targeting the JVM now).

I could see this as a little less likely though for limited resource use cases since much of the code is not written with that in mind. I'd be curious how the LLVM IR looks compiled to WASM compared to Go's built in (as of 1.11) support. Specifically the initialization of the unicode package with all its exposed structs and init struct creation has been a startup and binary size burden on any size-restricted context Go runs in. Causes lots of bloat on the WASM side.

I created an issue on some of the WASM bloat [0], but it's not really going to be addressed now.

0 - https://github.com/golang/go/issues/26622

View on HN

Yeah the heavyweight standard library is a big problem. I'm trying to solve it (in part) with smart analysis that tries much harder to remove dead code and dead global data. Maybe even try to run some initializers at compile time so the result can be put in flash instead of RAM.

In my experience, it's not the unicode package that's big but the run-time typing information and the reflect package used by packages like fmt. The fmt package doesn't know what types it will need to accept so it literally supports everything (including unused types).

And as you mention WASM: I've been thinking about supporting that too, exactly because WASM and microcontrollers have some surprising similarities (small code size, fast startup, little OS-support).

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support.

This project seems more immediately useful :)

Yeah, just wait until you see multiple megabytes of WASM instructions for tiny progs or the realize the team does not care about non-web targets. You're much better off leveraging Rust's WASM support for resource limited, non-web WASM targets.

In my case I was less interested in the WASM part of it than I was in something targeting a "no OS" environment. That said, for my target (those little Pine64 RTL8710 Cortex M3 MCU) you're almost certainly right. On the other hand it's a hobby project, and I like writing Go while I find writing Rust to be a bit of a chore. Also, it's a hobby project, so distractions like re-targeting WASM to the ARMv7-M are half of the fun :)

https://github.com/alexcrichton/wasm-gc

That's pretty cool!

If you want something now, I've also written and abandoned this: https://github.com/aykevl/tinygo-gccgo

It actually worked fairly well, but the code was way too bloated to be useful.

Honestly for what I'm doing what you have here is a pretty reasonable start. I'm comfortable writing (and calling into) C where the Go bits aren't in place yet, and I'm a lot more familiar with LLVM's internals than with GCC's if I need to debug something. We'll see what I get up to after brunch.

One request: if you're open to PRs (I can't promise I'll send any, but I'm trying to get into a habit of contributing to OSS with my hobby hackery), can you add a LICENSE file (context: the OSS patching policy I'm bound by is very friendly for projects on Github under most licenses -- https://opensource.google.com/docs/patching/ -- it's more problematic when the license for the code is undefined)?

I'm certainly open to PRs :)

Good catch on the LICENSE file, I totally forgot about it. I've added it now.

Reply on news.ycombinator.com