This content is based on the audio recording of #84 Hardware hacking with TinyGo and Gopherbot[1] from April 2019, organized and translated.
Mat Ryer[2] co-hosted the first one-on-one interview show with special guest Ron Evans[3]. Mat asked Ron to teach us about hardware hacking techniques involving Go, Gophercon[4], TinyGo[5], and Gopherbot[6] in IoT.
During the process, there were appropriate edits to fit common Chinese expressions, and the copyright belongs to the original author.
Mat Ryer: Hello everyone, I’m Mat Ryer. Guess what time it is today? That’s right, it’s Go Time! We are preparing for the robot uprising, *spoiler*: it’s going to be very cute. Today we’re going to talk about TinyGo[7] and Gopherbot[8], and I have the creator of Gopherbot with me; I’ve heard some people call him the “Santa Claus of the open-source world.” That’s Deadprogram[9], also known as Ron Evans. Hi Ron, how are you?
Ron Evans: Hi, everyone. Actually, today is TinyGo Time.
Mat Ryer: Yes, TinyGo Time.
Ron Evans: Exactly.
Mat Ryer: Do you prefer people calling you Ron or Dead?
Ron Evans: Well, I’m not dead yet, so…
Mat Ryer: Then let’s call you Ron.
Ron Evans: Right, Ron is fine. But I prefer people to call me Deadprogram, like Prince—you wouldn’t call him Pri, you would just call him Prince.
Mat Ryer: Right, Deadprogram. It can also be like a crashed symbol or something else… Anyway, welcome to the show.
Ron Evans: Only if I have disagreements with the record company will I do that.
Mat Ryer: [laughs] Honestly, I think that’s very likely to happen, Ron.
Ron Evans: It’s not impossible.
Mat Ryer: Great. This is actually our first time doing a show like this. It will be a very intimate show, close to the microphone, warm, just me and Ron today, chatting about these topics.
Ron Evans: And robots, of course. Just you and me, plus a bunch of robots.
Mat Ryer: Right. We’ll learn more about these mischievous little robots, probably starting with TinyGo, because I think that’s where it all begins, and Go plays a role here, right?
Ron Evans: Yes. I’ve been on GoTime before, discussing some other projects I’ve been involved with in the Go space—robots, drones, computer vision, most famously the Gobot project… Last year I also talked about GoCV, which is a computer vision project using Go and OpenCV… But what I’ve always dreamed of, or wanted from the very beginning, is to be able to run Go on tiny chips, on these microcontrollers. These are very small chips that exist in everything, like keyboards, mice, brake systems… These little chips connect to the physical world, making things happen at the right time, or not happen, hopefully everything goes smoothly… But we’ve never been able to run Go on these tiny chips because they are just too small. Go is a great language, very powerful, capable of doing many amazing things, but it’s not known for being small. The number of keywords in Go is small, but the binaries it generates are large, let’s just say that.
Mat Ryer: Yes. So Go is too big for these microcontrollers.
Ron Evans: Yes, and several orders of magnitude too big. A simple Hello world program, when compiled on a Linux operating system, is about 1.1MB in size. To be fair, it includes the entire Go runtime; it almost contains everything you might need… A program that just outputs Hello world and a program that performs some fairly complex processing won’t differ much in size because once you hit that initial baseline, the difference isn’t very noticeable. But when we’re talking about microcontrollers, we might be discussing processors with only 64k of RAM, or even less.
I’ve always wanted this but it’s never materialized, and people always said, “Deadprogram, you’re crazy, this will never happen.” But a few people have tried and done some cool things. There used to be a project called Emgo[10], which basically transpiled Go to C code, and then you could compile it using the GCC compiler for different ARM-based embedded devices. It was a step in the right direction, but it wasn’t pure Go code. Nonetheless, it was a very cool project, and its main developer did a lot of amazing work… But it still didn’t meet my goal.
I’ve discussed this with some others, trying to persuade those I thought could really solve this problem: “How can we compile Go into something so small?” Until last year, around September, I learned about the TinyGo project, which was initially started by my main collaborator Ayke van Laëthem[11]. He was involved in several projects in the embedded space, especially MicroPython[12], which is a version of Python that can run on microcontrollers.
His attitude was: “If Python can run on microcontrollers, if JavaScript can run on microcontrollers, then why can’t Go?” But his approach is very unique and very powerful.
In fact, Go is written in Go. The Go compiler is written in Go.
Mat Ryer: It wasn’t written in Go before, right?
Ron Evans: Right, it wasn’t. It was originally written in C…
Mat Ryer: Well, why didn’t they use Go back then?
Ron Evans: …so you had to use a C compiler like GCC to compile Go, and once you compiled the Go compiler, you could use it to compile Go programs. So until --- I can’t remember which version… probably around 1.5.
Mat Ryer: I remember it that way too.
Ron Evans: I don’t remember the exact version, but compiling the Go compiler itself is a very complex task. But then at one point, the Go compiler was entirely written in Go. This was very useful for the Go core team and for anyone wanting to contribute to the Go compiler because if you can read Go, you can read the compiler code… This is also a problem faced by some other very cool open-source languages like Ruby or Node.js, where people say, “Oh, I want to contribute to this project,” but they find out, “Sorry, it’s not written in JavaScript, it’s written in C++, and I don’t know C++, so… Sorry, I can’t really contribute.” So Go is written in Go, which undoubtedly lowers the barrier and creates new possibilities.
Because Go can parse its own language in Go, you can use Go’s own libraries and tools, and then transform it into what is called Static Single Assignment (SSA) form, which is --- when you hand the text of Go to the Go compiler, the compiler parses it, breaks it down and transforms it into SSA form, and then the toolchain of the Go compiler transforms it into machine code.
Mat Ryer: Understood.
Ron Evans: So Ayke’s idea was: “Well, if I can get this SSA form, I can use the LLVM toolchain to transform it into binary code.” LLVM is a set of compiler libraries and tools that have been around for quite a while. I’m not sure how long it’s been, but I’ve been using it for at least 12 years, and it has probably been around longer than that… It’s very well known because some languages use LLVM, and those languages have attracted a lot of interest. One of them is Swift. Swift is a language based on the LLVM compiler toolchain. Another is Rust.
Ayke uses the SSA form generated by the Go compiler toolchain, and then TinyGo --- this compiler project --- takes this SSA form and transforms it into LLVM intermediate representation (IR), so it can be compiled for target architectures supported by LLVM. Some of these targets are microcontrollers, like Arduino, which uses AVR microcontrollers. All ARM-based microcontrollers, like Adafruit’s Circuit Playground Express, which is a very cool microcontroller… All new Arduinos are based on these types of ARM microcontroller architectures, like Arduino Zero and MKR1000. So almost all interesting, small, cheap chips are based on this microcontroller architecture, and if we can compile code to these devices…
This February, I first presented TinyGo at the FOSDEM[13] conference in Brussels, and it was very exciting. Ayke came from the Netherlands, along with contributors from other places… After my talk, we held the first “like-minded” meeting, and the organizers of FOSDEM generously scheduled my talk in the main hall, so I was actually the first person to talk about Go in the main hall of FOSDEM. It was amazing. I thought, “You should pick a real Go expert first, but… hey, TinyGo! Let’s get started!” However, it was really exciting to share these achievements, and we released the first version of the software.
I demonstrated a lot of demos, but the most attention-grabbing was that I compiled a 500-byte TinyGo program that runs on an 8-bit microcontroller called ATtiny85, which has only 8k of RAM.
Mat Ryer: Wow.
Ron Evans: So I can compile a Go program for an 8-bit microcontroller with only 8k RAM.
Mat Ryer: That’s really small.
Ron Evans: Yes, very small. I chose it basically because the microcontroller has the word “tiny” in its name, I admit.
Mat Ryer: Haha. So Go source code is transformed into SSA, and then the TinyGo toolchain takes it from there to generate these small programs… So what’s the cost? What do you lose? What’s missing from the 1.1MB version of Hello world in the 11k version?
Ron Evans: That’s the key --- we can’t compress 100% of the information into 0% of the information; I believe that’s impossible…
Mat Ryer: Right, exactly.
Ron Evans: It doesn’t include everything in Go. A big difference is that when you’re running on bare metal without an operating system, the runtime is different… So we have to implement runtime calls differently.
Another challenge is the Go standard library. We can compile a lot of the standard library, but there are some parts we can’t because they are tightly coupled with the runtime itself.
Mat Ryer: Yes.
Ron Evans: So in those cases, we need to implement a version of the standard library that is more operating system-agnostic. So this involves some trade-offs. We currently can’t compile all of the Go code… but that’s not our primary goal either.
The Go core team is doing an excellent job. We’re not trying to replace Go, nor are we saying “Go is bad, TinyGo is good.” Not at all. Quite the opposite, our viewpoint is: “Wow, Go is such a great language, we want to run Go code in more places. Can we propose a new Go runtime and standard library implementation while still using the same Go programming language? And if so, can we still use Go’s standard library?” Maybe all of it, or most of it, at least a significant portion.
However, due to the environment it needs to run in, there are some trade-offs. However, a huge benefit is that we don’t need to carry all the extra stuff. After all, no one is going to use the entire standard library at once. If you really did that, your code would be extremely large, my friends!
Mat Ryer: You definitely don’t want to run such large code on tiny edge hardware… Some things are obvious, like operating systems, opening files, etc. --- they might differ in a situation with little file systems. I’m not sure if that’s a good example.
Ron Evans: That example is actually quite good. On microcontrollers, you don’t have a file system at all, right? But you can… we haven’t implemented it yet, but it’s on our roadmap. Many small devices typically have flash memory or SD card interfaces. These devices usually use SPI interfaces, which is a low-level hardware interface that microcontrollers can use to communicate with devices. This way, the device can have a file system. It’s very common for these devices to use FAT file systems by default… So when you get an Adafruit Circuit Playground Express, it comes with 1MB of flash memory that you can use to store various data files you might want to read from your microcontroller code. Ultimately --- we currently don’t support that in TinyGo, but it’s on our roadmap; for example, you can have wav files and then play them using the built-in DAC (digital-to-analog converter)… so you can play wav files as part of some interesting interactions. Or you can log data remotely… for those devices that are not always connected to the cloud, or those that are not intended to connect to the cloud, you might still want to be able to save data.
Mat Ryer: Right.
Ron Evans: Maybe you want to train your device to recognize your voice, but you don’t want to send any data to the cloud; you need some kind of local storage. So these are the low-level interfaces you need to implement. Some people use what are called real-time operating systems to implement these functions, which is not a complete operating system, but it may have certain features… like some memory allocation features, file read/write features, network features, etc… but we try to use it wherever we can with the Go standard library.
Mat Ryer: So in this case, does TinyGo need to have its own OS package? The functionality of this package is completely different but may replicate the interface of the standard library OS package? Would you handle it that way?
Ron Evans: That’s actually what we’re doing in multiple scenarios. For example, we’ve been adding support for MacOS in an operating system-agnostic way. But a better example is in bare-metal environments, where we need to be able to say, “Oh, there are no operating system primitives at all,” so we either implement them ourselves or not implement them in some way.
We discussed the main challenges we encountered on the TinyGo wiki page[14], one of which is the tight coupling of Go’s current implementation --- that is, the tight coupling between the runtime and the standard library. In fact, there were some very cool talks about this topic… I attended one of the talks discussing the design of Go 2.0. Ian Lance Taylor did this talk, discussing the transition to Go 2.0[15]. He’s done this talk several times; the first time I saw it was at GopherPalooza[16], which I remember was held in San Francisco. It was a very cool conference held last year. He discussed the tight coupling between the runtime and the standard library, and some proposals for decoupling… so that if you correctly implement the runtime, theoretically the entire standard library could still continue to work.
For TinyGo, this is a huge technical challenge, but we can work around this by re-implementing some logically primitive operations, especially when you’re running on devices with very limited memory.
There are also some other important differences, like how microcontrollers actually work? On microcontrollers, you have registers, which are typically used for very low-level hardware communication. It can turn on and off an LED through GPIO interfaces, or it can communicate with other chips directly connected to the microcontroller, like the SPI interface in our little flash example, or many sensors use the I2C interface, like digital compasses (more formally known as magnetometers), accelerometers (motion detectors), thermometers… many sensors use the I2C interface.
One of the most important jobs of TinyGo is to create drivers that provide standard interfaces --- also defined in Go --- so that you can write some code, and if it uses the same LIS3DH digital accelerometer on the Circuit Playground Express board, the same code can be ported… Today there’s a project on Hacker News and some websites about a homemade smartwatch --- I don’t know if you saw that project today --- it uses the same digital accelerometer. So we might --- I haven’t gotten that hardware yet, and I haven’t looked closely, but if it uses one of the processors supported by TinyGo, we could theoretically run TinyGo on that watch and connect to the same sensor it already has, almost without changing the code, possibly not needing to change it at all.
Mat Ryer: Wow, that’s awesome.
Ron Evans: Yes, this hardware abstraction layer is very important because you don’t always know exactly what target hardware you want to use, so we can decouple those drivers that know how to perform standard functions, like reading temperature, detecting motion from accelerometers, no matter what chip it runs on, whether it’s from Microchip, or Nordic Semiconductor, NXP, or Intel… By doing this --- it aligns with Go’s spirit; Go tries to be OS- and architecture-agnostic; we’re just extending that to Go OS with no operating system… that should be our ideal use case.
Mat Ryer: Yes. You just mentioned interfaces… does that mean you can write unit tests in this area? If you’re dealing with an interface in Go, is this a testing opportunity that doesn’t require physical hardware? You can just write test code targeting that interface.
Ron Evans: Yes, that’s absolutely true… First, about testing. Testing is absolutely essential in any modern software development.
Mat Ryer: No doubt about it.
Ron Evans: However, it’s already the 21st century, and most embedded software still primarily uses informal manual/functional testing. The joke is: “Hey, I just looked at this program, it has 10,000 lines of code and no tests.” “What?! That’s unacceptable!” “Oh, it’s an embedded program.” “Oh, never mind. Just release it.”
Mat Ryer: [laughs]
Ron Evans: “Don’t worry, it’s just on a jet plane, or maybe on a laser for brain surgery… nothing too important.” “We don’t really know. We just sell these chips to someone, and they sell them to some companies, and in the end, they use them to do something.”
Mat Ryer: That’s true… it’s not their problem, right?
Ron Evans: “The problem will get solved eventually.” So this way is clearly not the right way to develop software. So, first of all, as you said, we can use interfaces to test things that don’t necessarily need to connect to physical hardware. We are currently using QEMU for some of this work, which is a hardware simulator. There are also some other cool projects… Antmicro has a project, I can’t remember the name right now, but its specific function is to provide some simulations of microcontrollers. So there’s a lot we can do to comprehensively test different embedded systems using modern languages and modern compilers --- if we’re talking about software reliability, this becomes even more important when it comes to edge devices because security is clearly a big issue… but there are also some secondary impacts; if it collects information incorrectly, it could lead us to overlook some problems… for example, a sprinkler system might not be critical, but if it wastes a lot of water, that’s very bad in the long run.
Mat Ryer: Yes.
Ron Evans: In the short term, it’s also very bad because you’ll get a huge water bill. So by testing, we can avoid these problems. Another is time testing. If we want to test our sprinkler system to ensure it works correctly, if we only have physical functional tests, then every iteration we have to run it for a whole week to ensure it turns on and off at the right times.
If we could write some unit tests to test whether it triggers events at the right time, we could speed things up --- this is normal iterative software development; the right simulation mechanisms and interface designs can help build better architectures. If we combine these, this really is our only hope for writing software that touches the physical world.
Mat Ryer: Yes.
Ron Evans: The last mile.
Mat Ryer: Yes, touching the physical world is a good point, and I can now talk about the exciting giveaway we’re going to have today. We’re asking everyone to either rate the podcast (preferably positively) or share it, telling your friends about this podcast, especially this episode… So when this episode goes live, if you share it on social media or just recommend it to a friend. If you want to participate in the giveaway, please take a screenshot to prove you actually shared it and send it to [email protected]. Details will be in the show notes, but you definitely don’t want to miss this opportunity because I think the prize is amazing. Ron, now might be a good time to talk about that prize, and we can dive into that project.
Ron Evans: Yes, we’re going to give away a Gopherbot. What is Gopherbot? Gopherbot is a plush toy gopher that can be programmed with TinyGo.
Ron Evans: Many people have these very cool gopher plush toys, which they got at Gophercon and other cool events… I collaborated with my brother Damon, who is also a hardware hacker; he designed a 3D helmet, and I installed lots of LEDs and sensors in it… People really liked it. So we thought, “Wow, this is a great way to raise funds for our open-source efforts while also creating a very cool, programmable, collectible robot plush toy.” So Gopherbot is our way of expressing that. It uses a very cool plush gopher from the Golang Market, combined with a custom 3D printed helmet.
There are two different plush colors and ten different helmet colors. I haven’t decided how many different LED colors there will be yet… I haven’t told everyone they can choose LED colors. That will be a surprise after the event. It has an Adafruit Circuit Playground Express microcontroller built in, which is a very cool round microcontroller made by Adafruit. This company is based in New York and does very innovative things in hardware and software.
Inside the helmet, there’s an RGB LED array that contains 15 different LEDs, each of which can individually control its RGB color. We also have a spring-loaded LED that really can spring load. You can “buzz” it, and it still works.
Mat Ryer: That’s my favorite part. If you go to Gopherbot.com[17], there’s a gif, I guess you made it, Ron, that showcases this project, showing the little Gopherbot. And one of the scenes is a clip of Ron bouncing it on top of his head. It’s fantastic, so you definitely need to check out Gopherbot.com.
Ron Evans: That was the most engineering-challenging part --- an LED that can be mounted on a spring and still flash while the spring is bouncing.
Mat Ryer: [laughs] Yeah. I mean, as far as software development task requirements go, this is definitely one of them. You see, I’m really glad this thing is happening because I’ve seen some talks about TinyGo, and whenever software touches the real world, I get really excited… because I’ve basically spent my entire career doing web development. So when I heard about TinyGo, I was thinking, “How do I play with this? I hope there’s a kit I can assemble and start actually writing code and doing something…” And then, of course, Gopherbot came along, and that’s exactly its purpose, isn’t it?
Ron Evans: Exactly. This kit includes an LED helmet, a spring, a circuit board, and a backpack that can connect… The circuit board has a lot of sensors inside. There’s a light intensity sensor, an accelerometer that can detect motion on the X, Y, Z axes, or detect if it’s being moved… There’s also a built-in MEMS microphone that uses the I2S interface for sound recording. There’s a DAC that has a little speaker… It also comes with nine NeoPixel LEDs that you can control their colors individually…
We’ve posted a lot of videos on Furriebot’s Instagram, showcasing different scenes --- it looks like it’s been filtered, but actually, none of the photos have been filtered. They were all shot with my Android phone, just different angles. Some photos were taken with some famous robots or toys, along with my collectibles… I really love toys.
Mat Ryer: What’s that Instagram account?
Ron Evans: Furriebot[18].
Mat Ryer: I’m surprised that account name hasn’t been taken. So can you write TinyGo code and then flash it to Gopherbot? Is that how it works?
Ron Evans: Exactly right. You write code on your computer, compile it, and then transfer the code to the microcontroller, which is that little Circuit Playground Express board. From that point on, you can disconnect from your computer because all the Go code runs on that little circuit board.
For example, if you want to make a little toy like an electronic pet that walks around with you, or you want to go to a party and have its mask flash to the rhythm of the music, or run on battery --- you can do that. The Gopherbot itself doesn’t have built-in wireless communication, but you can easily add it.
I demonstrated a project at FOSDEM where I connected an ESP8266 Wi-Fi chip to the microcontroller, giving it Wi-Fi capabilities. But that’s not something we have built in. I think people don’t necessarily want a connected toy, but they do want a programmable toy.
Mat Ryer: Yes.
Ron Evans: Those are two different things. One is “Oh, Hello Barbie is listening to you and sending your deepest thoughts back to our headquarters…” You know, that’s not necessarily a good thing. The other is that you can program Barbie to do different things. The creators of Barbie might say, “Oh, what if Barbie says something we don’t want to hear?” Well, that’s the point, isn’t it?
Mat Ryer: Yes, that is the key.
Ron Evans: Programmable toys will be used for things the creators didn’t foresee, and that’s exactly the point; that’s what makes them fun.
Mat Ryer: Right.
Ron Evans: We’ve seen some sad news, like Anki. Anki was a very cool robot startup that received very generous funding. They made a splash with their Bluetooth remote-controlled cars at Apple’s WWDC a few years ago… but they suddenly announced the company was shutting down, which is a real shame. It’s unfortunate news. But I think one of the problems with their product was that they made non-programmable toys. Those toys could only do the functions built into their API and couldn’t go beyond those limits, so all the software development work depended on their own team. And if you wanted to go beyond those features, you either couldn’t do it at all, or you’d have to put in a lot of reverse engineering costs like we did with the Tello drone. If it weren’t for our six-person team being a bit crazy about getting it to fly, we wouldn’t have spent so much time writing Lua scripts and other things; it wouldn’t exist.
Do toy manufacturers really need to restrict you like that? And actually, they could just put in a little more effort --- in my opinion, all toys should be programmable. All toys should be hackable. Especially if it has programmable capabilities, those capabilities should be opened up. At least that way we can confidently look at it and say, “Oh, it’s not actually spying on us and sending information back to Gopherbot headquarters.” [laughs] It’s programmable; you can add that functionality yourself, but that’s not what we intend to do.
Mat Ryer: [laughs] Right, but you’re right; I think it applies to everything. Making things hackable so people can play with --- that’s where the fun is, isn’t it? That’s where all the fun is. For toys, I was the same way when I was a kid; after playing with them for a while, probably a few months, I would definitely get a screwdriver because I wanted to see what was happening inside. So we’ll do that anyway; they might as well let us do it.
Ron Evans: Yeah, right. I bet you how many of your toys last an hour without being taken apart? We should ask your parents to find out. [laughs] I bet almost none survive the first few days without being taken apart because they’re not meant to, right? If they really said, “Yes, this toy can be taken apart and put back together again and still work,” wouldn’t that be great?
Mat Ryer: Yes. On the other hand, the counterexample is Lego. Lego is trash if you don’t build and modify it. Otherwise, it’s just a bag of bricks. So yes.
Ron Evans: Exactly. Stepping on it is dangerous.
Mat Ryer: Exactly. In fact, in our country, the only thing worse than that is the British power plugs.
Ron Evans: Oh, yes.
Mat Ryer: They’re inherently very dangerous. They’re essentially spikes up, so… [laughs] Many of us have painful memories of stepping on plugs. By the way, Ron, it’s funny… Justin Clift was on Slack --- by the way, listeners, if you’re listening live, you can join Gopher Slack or the #gotimefm channel… Justin Clift was over there, and he just mentioned WebAssembly, and someone tried it, and the TinyGo compiled 2.5MB Go WebAssembly binary is only 575 bytes, which is pretty good.
Ron Evans: Yes, we’ve said we’re not trying to take over all use cases of Go, that’s true, but there may be some we can do a little better (pun intended). I can now say the pun of Tiny and Go at the same time, ideally in the same sentence.
Mat Ryer: Wow, that’s awesome.
Ron Evans: This is a triple pun. Few people attempt it, and occasionally someone succeeds, but I’ll see if I can pull it off.
Mat Ryer: Occasionally succeeding is just a pun.
Ron Evans: Yes, that’s right. WebAssembly is very interesting. For those listeners who are completely unfamiliar with it --- although I’d be surprised --- WebAssembly is a new attempt to create a new web runtime environment that allows code to access more local features in web browsers, improving processing speed and making it more efficient. It’s not meant to replace JavaScript, but to enhance it for various reasons, performance is undoubtedly one of them, especially in many cases.
Many languages can compile to WebAssembly; in fact, it’s an instruction set designed to be executed in a sandbox. LLVM is the compiler toolchain --- you might remember, TinyGo uses it to generate code… LLVM can generate WebAssembly as its backend.
We have a few people focusing on the WebAssembly part. My understanding of it is surprisingly limited; I’m still learning. Justin Clift is working on this, and Johan Brandhorst recently gave a great talk at DotGo, where he mentioned TinyGo, and now he’s also part of our TinyGo team, helping ensure TinyGo’s safety on the web.
Back to the start --- Go is great, Go is powerful, but Go is too big; downloading a 1MB thing to your mobile device is basically unworkable, especially when we’re talking about remote areas where bandwidth is very expensive and limited, or even possibly not achievable at all.
So if we could compile Go code into code that can run in WebAssembly and achieve smaller executable files while retaining the syntax and features of Go that we love --- wow, for something so small, that’s a huge leap forward. So this is an important area of development for TinyGo. Microcontrollers are one, WebAssembly is another, and there are two more I want to briefly mention.
Justin said in the Slack channel: “After gzip compression, it can drop to 408 bytes.” Yes… sometimes you think, “Can we save a few more bytes?” You have to save a few bytes because you can… but that’s also important. We’ve been very lax in our use of technology. Our overuse of technology is astonishing.
As a young programmer, one of the most amazing things I saw was GEOS on the Commodore 64. It was actually a complete windowing operating system running in 64k of RAM. It was incredible. I once met one of the creators, and I was a total fan. I said, “How did you do that? It’s incredible.” Then I think about how much we waste resources now, thinking “Oh, it’s okay, computing is cheap.” But computing is not cheap. It’s just that the costs are externalized. The cost of power, the cost of cooling --- many of these costs are shifted to the environment rather than being paid for by anyone.
Over time, computing efficiency will become more important, both in terms of resource utilization and because our demand for computing is increasing. We want machine learning algorithms to run on edge computing devices, where they can really make an impact. Although the things Machine Box does are cool, it doesn’t help with the collision avoidance algorithms for drones because we need to execute that algorithm directly on the drone; otherwise, if the Verizon network is poor that day, it won’t work, right?
Mat Ryer: Yes, exactly.
Ron Evans: These things all have their use cases. This is not a binary choice. It’s a false dichotomy. TinyGo’s mission is to say: “There are places Go hasn’t gone yet. We want Go to go there.” Because any sufficiently mature language has more than one implementation. Look at how many implementations Python has. Look at how many compilers C has. How many implementations does C++ have? How many implementations does JavaScript have? And Go only has one until TinyGo came along. I’ve seen some other attempts, but none truly said they wanted to “use Go itself to write a new Go that is still Go but can do some important things.”
The last big topic is the future. The future… [singing] “The future ah ah ah ah ah…” [laughter] We are currently in the most exciting time for computing that I’ve ever seen. No joke. Why? Because we are at the first step of a Cambrian explosion of custom silicon.
For years, we’ve been discussing, “Wouldn’t it be great if you could create dedicated chips that make certain types of processing more efficient and cheaper?” But there hasn’t been a practical way to do that. You need to find those chip designers who have the esoteric knowledge and pay huge licensing fees to those companies providing help --- not just because they let you do it, but also because of patent issues, but you really can’t do it without their help. Like, “I’m going to make a new chip.” Ten years later, “Yes, we’re going to make a new chip.” “How’s that going?” “Well, it’s really hard to do.”
RISC-V is a technology that some people have heard of, and some have just heard the buzzword… it’s actually an open-source chip design set, so you can build your own custom chips just like we can build custom operating systems from some parts of Linux --- we’ll be able to do the same with custom silicon. So TinyGo will be able to run on RISC-V because it uses the LLVM backend… I’m waiting for my Sci-Fi prototype board to arrive. I was originally going to run a demo before telling anyone, but I’m too excited because many people are doing some cool things with RISC-V, and I’m still waiting for my shipment… I can’t wait; I have to say something.
Mat Ryer: [laughs]
Ron Evans: But if you think about what this means, especially in addressing those problems that are too expensive because they require too many sensors, or too difficult because the sensors are too far away… you know what problems I’m talking about, and of course, climate change. That famous Bret Victor[19], known for his amazing experiments in programming interfaces… if you haven’t been following the latest developments from Dynamicland[20]… it’s a very bad name, but the technology is incredible, programming the real world using physical objects… what they’re doing is just astonishing.
Mat Ryer: Wow.
Ron Evans: I can’t believe I’m forgetting that name now… awkward. But he has a great blog post called “What Can We Do About Climate Change as Technologists?” Clearly, this is one of the most important issues of our time, as it impacts the physical world we live in. What can we do as technologists? He listed different technologies, whether it’s better visualization and scientific analysis technologies… this is a bit far from me because I’m not a scientist (though I know some), and I don’t have peer-reviewed papers… but I’m a technologist, so one of the areas is that we need better technology to control the physical world, monitor and control the physical world, as part of our broad response to these changing environmental conditions.
To do this, we first need to be able to reuse a lot of existing technologies. There are many chips --- we need to be able to recycle them. This is one of the reasons I’ve spent a lot of time studying the AVR (Arduino) capabilities of TinyGo. It’s a very old architecture, very limited functionality, but there are a lot of chips and development boards that can be reused to do useful things we need to do.
Every sufficiently advanced technology starts off as a toy. This is a modification of a quote by Chris Dixon… but you start with the toy concept and play with those concepts. So when you say, “I’m playing with it,” you don’t have to be doing anything useful or working, right? “I’m playing with WebAssembly.” That means “I’m not really responsible for writing a WebAssembly program that works. I’m just trying it out.”
Mat Ryer: Yes.
Ron Evans: So there’s no pressure. I can freely learn and experiment without being responsible for anything specific. At some point, I either put it aside and play with something else, or I’ve crossed the chasm from “Are you still playing?” to “Yes, I’m now using it to do X,” where X is some useful task. That’s where it all starts. So toys are the first step for us as developers to adapt to these new things --- back to what Matt just said… you’re a web developer; you know a lot about web technologies and have thought deeply about them… now you can apply those principles to edge computing and address some of those issues. The developers we need will come from that working group. There won’t suddenly be a bunch of mysterious robot experts who are fully formed and ready. We have to work with the human beings we have now. We are the rescue team, and that’s all there is to it.
Mat Ryer: [laughs] That’s why I love the Gopherbot project, because it gives everyone that opportunity. It gives you something to play with and provides you with everything you need. So I encourage everyone to check out Gopherbot.com.
Ron, will you be going to Gophercon[21]?
Ron Evans: Yes, actually, this year’s Gophercon will be the biggest and best ever. It will be held in San Diego, this place…
Mat Ryer: Very hot.
Ron Evans: …in Southern California; my family lives there, so you might meet my parents… but more importantly, on community day --- Gophercon is a four-day conference. The first day is tutorials and workshops. There will be some really cool workshops. Mark Bates will do a cool one about testing… Mat, are you doing anything?
Mat Ryer: No, I’ll be speaking.
Ron Evans: I know Johnny will do one, and Bill Kennedy will do one too… there are really many great trainings. Then the second and third days of the conference are all talks, full of learning opportunities and interactions… but the last day of the conference is definitely the best. If you haven’t planned to stay for the last day, you’re missing out. It’s community day, and every year we hold hardware hacking activities; we call it “Gobots and Other Flying Objects,” and it’s getting bigger every year. In fact, it’s taking up more and more space. They gave us a double-sized area. We have a drone area where you can fly Go-driven drones…
Last year we did GopherCar[22], which is based on Donkey Car, a self-driving car project using Raspberry Pi, Go-driven, using cameras, combining Gobot and GoCV… We have many kits for sensor hacking, all provided by different sponsors. So you don’t need to bring any hardware; we’ll bring a lot of hardware. We have tons of giveaways, activities, fun… so this is definitely amazing; if you don’t go, you’ll definitely regret it… because not only will you learn something, but more importantly, you’ll have a lot of fun.
Mat Ryer: Ron, I just thought of a question. When we talk about TinyGo running in the browser or on these microcontrollers, how is garbage collection handled? Because that’s also one of the reasons these binaries get big and fat --- that’s due to the existence of the runtime. So how does TinyGo handle garbage collection?
Ron Evans: Currently, TinyGo has relatively limited support for garbage collection. On some architectures, like ARM Cortex-based microcontrollers, TinyGo implements a very simple mark-and-sweep garbage collection. On AVR microcontrollers, like Arduino, there’s no garbage collection implemented at all. This is partly due to the limitations of 8-bit processors; I remember it’s like the data and instructions are not in the same memory space, or something like that. The AVR architecture has some quirks; I might be mistaken, but there’s currently no garbage collection implemented.
However, it turns out you can write useful code without garbage collection. One way is to use structures that contain the required memory, and another is to use global variables. We’ve also implemented some things like circular buffers that are very useful when performing various IO operations. So even without garbage collection, you can write useful code. However, one of TinyGo’s goals is to support garbage collection and be able to support multiple garbage collection algorithms and backends.
One thing we want to do is to be able to plug TinyGo into systems so that we can use the memory allocators and deallocators of real-time operating systems. That way, if you want to call some C code from Go --- by the way, one of the big advantages of compiling and linking with LLVM is that we don’t need all the stuff like cgo in mainstream Go implementations; for us, they ultimately are just function pointers, so we can make calls between Go and C faster because in TinyGo, ultimately, they are all binary code.
Mat Ryer: That’s really cool.
Ron Evans: In the current version of TinyGo, we’ve spent a lot of time simplifying the installation process, removing some extra dependencies. We haven’t completely removed all dependencies; if you want to compile code for ARM Cortex-based microcontrollers, you still need the Clang compiler. But the next version of TinyGo will eliminate that, so you’ll be able to compile Go and C code using just the TinyGo compiler.
This will bring us into a very exciting area --- you need some existing C code to run code on these different microcontrollers. Some are SDKs for real-time operating systems, like Zephyr[23] (a small real-time operating system for resource-constrained embedded interconnected devices, mainly microcontrollers that support multiple architectures), FreeRTOS, and Riot OS, and so on.
Another example is some closed-source code that provides open APIs, like Nordic Semiconductor[24] (a chip company from Norway established in 1983) for Bluetooth Low Energy implementations, like the BBC micro:bit. This is a very cool little board that all kids in the UK got a few years ago, and there are still many… Mat, you probably got one from some neighbor kid…
Mat Ryer: [laughs] No, I got it legally.
Ron Evans: Yes, sir, I believe you got it legally. [laughter] The BBC micro:bit comes with Nordic Semiconductor’s nRF51 chip, which includes a complete Bluetooth Low Energy protocol stack if you can call those closed-source code libraries.
One of our major goals is to be able to combine all this code, to execute very small and fast code while still using Go’s concurrency model… because we can run goroutines on these microcontrollers, which is itself quite amazing. For example, in our Gopherbot demo kit, that end glowing LED is actually running in its own goroutine.
Mat Ryer: Wow… that’s surprising. It actually supports goroutines.
Ron Evans: Yes. But there are some differences and limitations. The implementation of goroutines in TinyGo uses Clang’s coroutines, which is another module for concurrent execution that can accomplish most of what we expect goroutines to do. We’ve implemented channels, but there are some limitations, the biggest one being that we haven’t implemented the select statement yet. Once the select statement is implemented, channels will become more useful… but you can use them now. Additionally, there’s a developing branch that implements some sync/atomic functionalities so you can synchronize between goroutines when needed.
Mat Ryer: Awesome. If there are listeners who want to get involved, or if they’re interested in implementing channels or select functionalities, how should they provide help? What kind of help are you looking for right now?
Ron Evans: We’re looking for Tiny gophers of all experience levels, especially those who don’t have much experience. If you’ve never tried these things, we especially need you because you’re the perfect candidate to help us improve the onboarding process to make it easier for more people to get started with TinyGo and try to make various interesting devices and gadgets, or industrial systems and such.
On the other hand, contributing to TinyGo itself. We’ve spent quite a bit of time improving the process of installing TinyGo from source code. We have some make tasks that allow you to install the latest LLVM from source, making it easier for those who want to delve into it and add new features to TinyGo.
One of the most interesting contributors is Carolyne Van Slyk[25], who has been adding testing functionalities to TinyGo. This way, we can execute testing code with TinyGo. This will be very useful, and understanding the internals of Go testing is also very interesting.
Mat Ryer: Well, I think so.
Ron Evans: So there’s no better way to learn how they work than by building something that uses the same tools.
Mat Ryer: Yes, that’s awesome.
Ron Evans: I also want to mention --- for those who want to really understand the underlying mechanisms, Ayke published a very cool blog post yesterday on Aykevl.nl called LLVM from a Go perspective[26]. It shows, through some very simple Go code examples, how those codes are first transformed into Go’s SSA form, and then into LLVM IR form. It’s a great way to understand --- whether you’re interested in helping contribute to TinyGo or just want to understand how modern compilers work at a low level --- this blog post is fantastic. I’ve been reading it repeatedly, and each time I feel, “Oh, that’s how it is.”
Mat Ryer: That would also be a great topic for a talk.
Ron Evans: Everyone thinks I did all the hard work, but I believe others did all the hard work. I think this is called a “virtuous cycle.” Of course, the power of open source lies in our collaboration, whether directly through code contributions or indirectly through feedback “I tried this, but it didn’t work. Where did it go wrong…”
A few years ago, I heard a very cool talk in London by a woman involved in IoT-related work. I don’t remember her name, but she made a very good point about the confusion those just starting out face when making circuit connections. Generally, the red wire represents positive, and the black wire represents negative, right?
Mat Ryer: Right.
Ron Evans: But if you don’t know that, you won’t realize that colors are significant; that’s actually a convention. No one would explain that to you. This is very critical information, so when you’re starting out, you don’t even know what information is critical. So if you’re having trouble trying to get something to work, you’re not alone; we need to know these issues so we can help others who encounter the same problem… because sometimes we might know too much. We’ve already installed everything; we might not even know the problems in the installation process.
Mat Ryer: Yes, that’s a good point. So whether you have experience or feel ready to contribute, don’t hesitate to take a look because you might be surprised. Ron, your advice is really great. One of the great things about projects like TinyGo and Gopherbot is that the contributors and maintainers are very friendly and inclusive to others; that’s very important for the community.
We’ve previously mentioned an issue where one of the pieces of advice I always give in interviews is that if you don’t have anything else to talk about in the interview, then get involved in some open-source projects. TinyGo is a great example because it also involves real-world applications, which is always an interesting and exciting topic. So this is also my advice for those entry-level or just starting to learn programming.
Ron Evans: That’s absolutely true… and you also need an edge. That edge might be getting an LED on some hardware to light up. People who are not familiar with this field will be impressed by your new skills, and you’ll be surprised by your new skills.
Mat Ryer: Yes, I would be surprised by that.
Ron Evans: Right? That will give you the confidence to learn other things because it turns out most IoT, robotics, and drone technology is just about turning devices on or off at the right time, that’s it. If you can do that, you’ve succeeded.
Mat Ryer: You make it all sound so simple, Ron.
Ron Evans: Turn it off before the laser hits you, that’s my motto.
Mat Ryer: By the way, I know the red wire is positive because all the James Bond movies make it very clear… so we should be fine.
Ron Evans: Remember that movie “The Abyss”? They’re underwater, and there’s only one glowing stick, and they can’t tell which wire is which, which one to cut?
Mat Ryer: What a nightmare…
Ron Evans: That’s my life story… my life story. [laughs] Which wire should I cut? I don’t know; let’s cut them all! [laughs]
Mat Ryer: Yes. I always think, when they’re defusing bombs, it’s always that “oh oh oh…” tense moment. I think software basically never works, so it probably won’t work… let’s just mess around; it shouldn’t explode. That’s my advice, but I’m not in the bomb disposal business.
Ron Evans: Yes, it’s best to try it out before connecting the lasers.
Mat Ryer: Yes, exactly.
Ron Evans: That’s a good piece of advice I once received.
Mat Ryer: Very good.
Ron Evans: Make sure it’s safe… you know, ensure safety. [laughs]
Mat Ryer: Do you think that LED on the spring could turn into a laser? Or would it turn into eyes…?
Ron Evans: I think someone might very well do that, but I probably wouldn’t because it would shoot straight up and might hit someone’s eyes; I’d be that person.
Mat Ryer: Yes. But dying like that would be pretty cool, wouldn’t it?
Ron Evans: Don’t forget to point the laser at the ground.
Mat Ryer: Ron, I’m sure you’ll eventually end up getting killed by something you created; that’s for sure.
Ron Evans: Yes, there are two kinds of people in this world --- those who build robots and those who fear robots. So you have to decide which side you’re on.
Mat Ryer: Yes.
Ron Evans: But would you rather have the robot vaporize you instantly, or would you prefer it to hesitate for a few milliseconds when it recognizes you as its creator before vaporizing you? I’d prefer the latter.
Mat Ryer: Yes, so we really need the Machine Box!
Ron Evans: Exactly, exactly. You’ll need it one day.
Mat Ryer: Yes. For those building robots that may one day rule the world, do you have any advice? After all, you’re doing that, right?
Ron Evans: Well, you know, the world is big enough for a robot empire. Mars is currently the only planet in our solar system entirely inhabited by robots, so it’s a peaceful and beautiful place…
Most importantly --- well, there are two parts. The first part is that many people know very little about these things… so don’t be afraid to try and explore. You don’t need the latest and greatest hardware to do these things. In fact, any old Arduino you can find will do. If you have hardware sitting idle in a drawer, take it out and let others use it; don’t wait for it to become hazardous waste so they can learn… but don’t be afraid to try because that’s also a fun and cool way to learn.
The other side is --- don’t forget why we’re doing these things. We can build a world full of killer robots, or we can build a world full of helpful robots. It’s entirely up to us. Now, calling it “artificial intelligence” is actually not very accurate; it’s more like “intelligent applications.” They have some small range of intelligence in very specific areas, but there’s no general intelligence… and there’s no indication that we’ll get general intelligence anytime soon.
If you’ve read Roger Penrose[27] (a British mathematical physicist, philosopher, and Nobel Prize winner in Physics) book, you’ll know that we will never achieve general intelligence. But that doesn’t mean it’s not useful. It’s still very useful, but we have to be very careful because the biases we bring into these algorithms as humans can have direct impacts on the real world. We really need to think about “Should we build it?” before we build these systems.
The same technology can be used for good or bad, sometimes unintentionally, sometimes exploited by bad actors. So we must be very careful when deploying these systems into the real world because they can have unintended consequences.
Furthermore, once physical systems are installed, they often exist longer than originally planned. Anyone who has worked in factories or retail knows that once they install something, it often stays in service longer than planned. Partly because they don’t want to replace it, and partly because they forget it’s even there… So when we deploy devices to the edge of the world, we really need to consider this. At least in a server room, we can check devices rack by rack, “What’s this doing? What’s that doing?” But with devices in the physical world, we might not even know where they’re specifically installed. We’ve seen many seemingly harmless devices being exploited for bad purposes, like the Mirai botnet…
So we must apply very rigorous architecture and industrial thinking before deploying distributed devices, rather than discovering afterward, “Oh, these devices can’t be updated. That’s too bad…” That’s unacceptable. The ethical issues of device development must be considered before development.
Mat Ryer: Yes, that’s true. This is indeed a real issue. Well, that’s it for the show. A big thank you to Deadprogram, also known as Ron Evans, for introducing us to TinyGo and sharing his enthusiasm for Gopherbot.com. Be sure to check out this project. Don’t forget our giveaway. If you want to win a Gopherbot kit, including all the parts you need to write TinyGo code and create your own Go plush robot, check the details of the giveaway in the show notes. You just need to share this podcast and send an email to [email protected].
Alright, we’ll see you next week. Thanks, everyone!