Right now we don't have any support for Android and iOS in particular, but we do support Linux/ARM (regular Linux). It's an interesting use case however.
> In my understanding it supports most of the TLS stack and many other standard libraries as well
We don't have a proper net package yet so usage on Android/iOS will be rather limited.
Supporting GC on WebAssembly has been a _major_ pain for TinyGo because WebAssembly doesn't allow access to the stack. It's really slow and I'm still not confident it's bug free. Having a GC integrated in WebAssembly itself should solve these issues.
Unfortunately, the current GC design for WebAssembly doesn't support interior pointers which is going to be difficult to work around (but I don't think it's impossible). Interior pointers are normally required in Go.
Not on the heap, but it can certainly have uninitialized variables on the stack. These cannot be created in normal Go code but the optimizer may decide to leave some values uninitialized when it determines that this is safe to do.
Oops, those docs need updating. The GC now works on all platforms (including RISC-V and WebAssembly!) except for AVR because the AVR backend is just too unreliable at the moment and you wouldn't want a GC in 2kB of memory anyway.
That should be possible: there is also experimental AVR support. Experimental because the LLVM backend is unfortunately too buggy to be used in real programs (but is improving!).
The first step to make this happen, would be to add a PIC backend to LLVM.
Hehe, LLVM takes about an hour to compile on my laptop. The compiler itself is not tiny in any way. It really refers to the size of the binaries produced which is usually very small. For example, for WebAssembly, reductions to 3% of the original size are not uncommon.
The conservative mark-sweep implementation was the easiest to write: I don't think there is any real GC that is simpler. In the long term, the plan is to add other GCs that are precise and can be used in a real time context.
However, note that such a conservative mark-sweep GC is good enough for many use cases already (look at MicroPython!) and that other GCs will likely cause additional RAM/flash bloat.
There are 3 LLVM-based Go compilers that I'm aware of: gollvm, llgo, and tinygo. Of those, only TinyGo reimplements the runtime that causes lots of (code size) overhead in the other compilers.
There is more to a toolchain than translating source code to machine code. I'm sure the others do that job just as well, but only TinyGo combines that with a reimplemented runtime that optimizes size over speed and allows it to be used directly on bare metal hardware: binaries of just a few kB are not uncommon.
https://tinygo.org/usage/important-options/
Take a look at the `-gc` flag. The values have changed in the latest version (need to update the docs!) but it does provide an option to disable the GC entirely.
I once asked this a cryptographer. His response was that he would do the following things (if I remember correctly):
* Discuss the result with a few cryptographers he trusts, to check whether he didn't make a mistake and to make sure he's not the only one who knows about it.
* Write a paper. Put in all kinds of silly things, because it will get published anyway.
* Publish proof of having found the algorithm, together with a hash of the paper.
* Wait ~3 years until everyone has moved to a better algorithm. The normal responsible disclosure period is 3-6 months but this is so big it has to take a bit longer.
* Publish the paper.
I certainly think this is pretty dangerous. It may in fact be better to do the initial publication anonymously... and make sure you avoid all possible traces (the NSA will do everything in their power to get a hold of you).
Yes, there is a fair bit of documentation. But it is nowhere near any popular general purposes language. Also, most documentation isn't very accessible if you're not a compiler developer already.
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'm using this exactly. It's not the nicest interface but it supports almost everything that LLVM does.
https://github.com/llir/llvm looks nice but I don't think you can interface with LLVM from there, which is needed if you want to do more advanced stuff.
All backends supported by LLVM should be fairly easily supported by TinyGo. In fact, I've had the blinky example running on an Arduino a while back (8-bit, 2kB RAM, 32kB flash). There is nothing in the Go spec that requires a 32-bit system, just like there is nothing in the C standard that requires a 16-bit system (ints are at least 16 bits).
The biggest obstacle is not the fact that it is 8-bit, but the fact that it is a Harvard-style processor with a separate address space for code and data. I've added a section to the README to explain this. Also, garbage collection is going to be painful.
Alyssa said in her talk that they'll probably get it working in 6 months or so: https://www.youtube.com/watch?v=pDsksRBLXPk&t=2932s