Go — a modern programming language with roots at Google — is one of the new generation languages that would like to unseat C (and C++) for what we think of as traditional programming. It is only for PCs, though, right? Not so fast! TinyGo provides a compiler that — in their words — is for small places. How small? They can target code for the Arduino Uno or the BBC micro:bit. It can also produce code for x86 or ARM Linux (both 32- and 64-bit) as well as WebAssembly. They claim that a recent project to add ESP8266 and EPS32 support to LLVM will eventually enable TinyGo to target those platforms, too.
As you would expect, there are some subtle differences between TinyGo and the full-blown version. The compiler handles the entire program at once which is slower but offers more for optimization. Certain optimizations for interface methods are not used in TinyGo, and global variable handling changes to accommodate moving data from flash to RAM efficiently. TinyGo passes parameters in registers.
Other changes are more profound. For example, there’s no garbage collection yet, so you are urged to not perform heap allocations after initialization. There are also a few other major features not supported. Concurrency in the form of goroutines and channels, cgo, reflection, and three index slices won’t work. Maps are available, but only with certain key types. Because of the missing pieces, many of the packages in the standard library won’t build.
Of course, the other modern language in the same position is Rust and if you were wondering why Go instead of Rust, there’s an FAQ for that. Do you need Go on the Arduino? Maybe not. However, if you are a Go programmer, maybe this opens up some possibilities for you.
We remember a hacker jukebox that used Go. We also remember someone using it on the ill-fated Intel Edison.
And this was last week’s news. Next! Incidentally Al, Parallax called, they want you back.
Google huh?
A.K.A. Spyware Inc.
> A.K.A. Spyware Inc.
… because an ATMEGA328 with no built-in networking hardware is such a big spyware threat…
Might be about acceptance of the “Go” language… If a developer invested time to learn Go he will try to use it more often instead of another language he has to learn from scratch again.
The agenda:
– Seeding stage: create acceptance for exploitable (=security and price) solutions (complex programming languages where its easy to hide vulnerabilities deep in the foundation, vulnerable repositories with poor security screening due to high change dynamics, cloud computing where physical security of the machine is in the hands of others thus taking physical security away from individuals, make vulnerable solutions cheap and well supported like for cloud computing or software as a service, …)
– Growing stage: Increase the user base (create good press, feed social media with “success stories”, present how much money is to make by following this “new, hipp, agile” path of doing things…) This stage easily takes 5 to 15 years.
– Harvest stage: Once most developers abandon or forget the “old” solutions and are at stage where the “old” ways seem to demanding (cost, time, not possible to maintain anymore) increase the prices, sell the data even if it was intended to be kept private, create new rules where breaching these new rules comes with a penalty (cost, social de-ranking).
Go is in many ways simpler and safer than the alternatives. If someone insists on writing C they are more likely to write code with security issues hidden in fundamental pieces…
tinfoil hat alert!
PLEASE explain to me how this could happen with an *open source* PROGRAMMING LANGUAGE.
I don’t know a single developer who knows exactly one programming language. It doesn’t make sense for an employable developer today to know only one language… Lock-in is virtually impossible if not actually impossible.
Oh wait you listed stages: you are clearly more smarter than everywon else
If the source code is available it can be checked for any kind of spyware such as browsers like Chromium which is built from Chrome’s source but without the garbage that comes with stock Chrome.
Unseat C… Small places… I’m thinking of the Microchip XC compiler that can compile for the PIC10F206 with 512 flash words and 24 bytes of RAM, or even the 10F200 with 256 words of flash and 16 bytes of RAM.
I know XC is a rubbish compiler, and the PIC is a rubbish architecture. But to compile a high level language into that is a nice trick.
You haven’t really seen the worst of PIC until you are forced to work with CCS compiler.
Hehe yes I found a bug in their compiler back in the 90’s that stopped the project I was working on until they fixed it. I had to tell them exactly what was behind the bug (incorrect setting of a register) and how to fix it. You’d have thought they’d have given me a freebie (like a discount or whatever) for that, but no…
We don’t have to look that far. TinyGo is targeting AVR, so there’s this gem: https://hackaday.com/2014/03/20/usb-on-the-attiny10/ And a couple of years ago I read an article on using GCC with ATtinys with no RAM at all, thanks to binding variables to registers (https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind). Unfortunately I cannot find it now.
One of the maintainers of TinyGo here. First of all, thanks for including us here, Hackaday. We appreciate it!
A couple of corrections, TinyGo does in fact support garbage collection, and we have a couple of different algorithms you can choose from. It is worth pointing this out, although it is also true that it is not a good practice to do heap allocations on devices with such limited memory.
Another important point, TinyGo does in fact support both goroutines and channels, which are required for concurrency. The support is currently based on LLVM co-routines so it runs pretty efficiently. That said, we are in the process of adding a more powerful scheduler to allow for even more concurrency especially on 32-bit ARM processors.
We are actively working on the next release of TinyGo which will be adding a lot more compatibility with the various parts of the Go stdlib and also other packages written in Go.
Lastly, a bit of trivia. I am that someone who was running Go on the Intel Edison. Now with TinyGo around, we have the option to run Go on even smaller devices.