The Changelog: Software Development, Open Source - Go is eating the world of software (Interview)

Episode Date: July 25, 2019

We're joined by Ron Evans at OSCON on the expo hall floor talking about Go and how it's eating the world of software. Specifically we're talking about TinyGo and what they're doing to bring the Go programming language to micro-controllers and modern web browsers. According to Ron Evans, "embedded systems and Go are the most exciting things happening right now."

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean, the simplest cloud platform out there. And we're excited to share they now offer dedicated virtual droplets.

And unlike standard droplets, which use shared virtual CPU threads, their two performance plans, general purpose and CPU optimized, they have dedicated virtual CPU threads. This translates to higher performance and increased consistency during CPU intensive processes. So if you have build boxes, CI, CD, video encoding, machine learning, ad serving, game servers, databases, batch processing, data mining, application servers, or active front-end web servers that need to be full-duty CPU all day, every day, then check out DigitalOcean's dedicated virtual CPU droplets. Pricing is very competitive, starting at $40 a month. Learn more.

Get started for free with a $50 credit at do.co slash changelog. Again, do.co slash changelog. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're at the Expo Hall floor of OzCon talking with Ron Evans. We're talking with Ron about Go and how it's eating the world of software. Specifically, we talk about TinyGo and what they're doing to bring the Go programming

language to microcontrollers and modern web browsers. It's been more than a five-year mission, actually, to seek out new life and new civilizations. I don't know if we're boldly going. We're more like creeping up timidly. You're getting close to boldness. Yeah. You're getting more bold. You come out from underneath your bunker.

Yeah, this is my first time out in a while from the workshop. I ensconced myself after Embedded World in March in Nuremberg, Germany. Great conference for Embedded. That was the first public appearance of GopherBot. And so I went around the whole appearance of GopherBot. And so I went around the whole conference with GopherBot. And it's amazing how a conference full of blinking LEDs and robots and stuff will literally stop in its tracks when they see a cute robotic gopher plushie. So it was a pretty big hit, huh? It really was, surprisingly.

I mean, I thought it was cool, but I thought it was weird. Yeah. It's like an intention-getting device, you know, but in the form of a robot. I didn't even realize my battery died, but these things get so much attention. And they're just marquees. That's got to be even more so. Well, also, this is actually very programmable. So all the software is also open source.

I just put the GitHub repo public, so it has all the tiny Go code, which is fairly high level. I mean, we were trying to create an API that people who are not really Go programmers could still decipher and use to program this device. You know, basically, you know, antenna.blink. And so you could say go antenna.blink, and it just launches a Go routine with the blinking antenna, and so it just keeps blinking while you do your other things. I mean, that's the big benefit of using Go, is its concurrency.

So if your Go is not concurrent, you know, why use Go? I mean, it's still nice, but this is a big part of Go's... Appeal. Well, the brevity of the language, the fact that there's very little to it as far as number of keywords. Right. That's really great when you're writing a compiler because it means there's less things that could go wrong, less misinterpretations, less ways to compile code.

And TinyGo has a lot of work to do in order to take the Go SSA code. Well, the way TinyGo works, just TinyGo takes your text code, your regular Go, and it uses the Go standard libraries, which themselves are written in Go, to take and convert that to single static assignment form, or SSA form. So normal Go at that point takes the SSA and compiles it to the binary code. This is where TinyGo kicks in and says, let's convert that SSA form instead to LLVM's intermediate representation. So LLVM is a framework for writing compilers. It's being used by a few languages people might have heard of, like Swift, or another

little language that is getting a lot of attention called Rust, and a bunch of other cool languages, a new one called Zig, which looks pretty interesting for WebAssembly, and many other languages in TinyGo as well. So we take and we can then target whatever one of the LLVM backends, of which there are many, of which many of them are very, very small chips,

microcontrollers, like the ARM Cortex M0 or M4, which are types of chips that Go could never run on. They only have maybe 256K of memory total. And the Go program is, Hello World is 1.1 megabyte. So there's a gigantic disconnect about what you could even fit on the chip let alone that it's not designed for that processor architecture and there's no operating system

on most microcontrollers. They just run bare metal. Right. So there was literally no possible way Go could run in this environment until my colleague IK Van Lattem he's actually the creator of TinyGo I'm like the first follower.

Never mind those 10K lines of code I wrote. I'm a good follower. I'm a good follower. But he's the creator of TinyGo originally, and I discovered it through, I don't even remember. It may have been through Golang Weekly, or just somehow it popped up through the internets into my attention.

I took one look, and I got very excited. I mean, I've been wanting to do this for five years. I could never convince anyone to help me. And here this single individual has already done substantial amount of the heavy lifting. So we have a team of four official members. We have 25 other contributors, I believe, now. But IK handles the compiler heavy lifting. I'm sort of responsible for the hardware peripheral interfaces, and I'm spokesmodel for the group. So I do a lot of the talks and promotion and just generally, you just generally yell for attention.

Then Johan Brandhurst does a lot of amazing work with TinyGo and WebAssembly. Justin Clift is also doing amazing work, even though he's not an official member of the organization yet. If you're listening to this, I just haven't gotten around to sending you an email because I know you've been busy. And then Conejo Ninja, a.k.a. Daniel Esteban, who is also Spanish, who has basically been doing all of the amazing work with all of the displays.

And then we have a lot of other contributors who have been, I mean, we have over 200 people on our Slack channel now. It's sort of taking off by leaps and bounds and that really segued nicely to the big announcements we made yesterday here at OSCON. So we had big three huge things that came out yesterday. We thought OSCON was a great place for us to launch these things just sort of it's the center of of the legitimate open-source world if you will, in the U.S. So the first one is TinyGo powered by Arduino.

So we've been developing a very special relationship with Arduino. I mean, they're the pioneers of open source hardware. They're a really cool company. You know, Arduino is love, they say, and they really mean it. I mean, they've been incredibly helpful to us. So we have TinyGo running on the new Arduino Nano 33 IoT chip. So that particular board is really interesting because it has both a microcontroller as well as a separate Wi-Fi chip.

So it's really geared up for the Internet of Things. If you don't have Internet, it's just a thing. It's not an Internet of Things. Internet thing? something like that. Right. So people ask, that means you can run the net package on TinyGo? No, not yet. However, since all of the net package is implemented in the form of interfaces, we can implement our own version of those interfaces designed

specifically to communicate with the serial interface with this Wi-Fi chip. So it's the same code. You just say, you know, package net. In this case, it's the net package that's part of our driver for the Wi-Fi chip. And then you can do, you know, net.dialTC, or net.dial. You know, we support both TCP and UDP connections. And because of this, we were able to implement the same interfaces as the Paho MQTT client. That's the official MQTT client from the Eclipse Foundation, which is used whenever you want to talk to an MQTT

machine-to-machine messaging broker from Go. Okay. So it's the same interface. So you take your regular Go code that you've been using on your embedded Linux, and you copy and paste it into your new code that you're writing for your microcontroller, you know, change a few things, you know, based on your authentication, and it just works. So it's a secure connection from your chip, from your Arduino Nano 33 IoT chip, to your secure messaging broker

and whatever cloud service you're using. That is table stakes for the Internet of Things. If you don't have that, you're not ready. So that was sort of our, here we are. So you're ready for IoT. We're ready for our close-up, Mr. DeMille. So the other two announcements were the future, the future's future. So the second one is the TinyGo Playground.

Okay. So the TinyGo Playground is like the Go Playground. It's a website. You can find it at play.tinygo.org. And if you look at it, it looks very much like the Go Playground. It's a web page that you can enter in the left pane your Go code, and in the right pane you see the console output. But it's using TinyGo.

The interesting part is we also support using our hardware boards simulated within this web browser. So you write your TinyGo code on the left pane, and it actually is compiling to WebAssembly, which is then executing against the simulator in the browser itself. So when you see the little JavaScript LEDs blinking, it's because your WebAssembly code is talking to this simulator in the browser to make them blink. That's cool.

And you can click on the flash button, and it downloads the hex file that you can flash right onto the real hardware. It's the actual binary for your code. Wow. That's cool. So then the third thing, which is related to the second thing.

So a lot of people have been getting very excited about RISC-V. So for anyone who hasn't heard about RISC-V or doesn't know what it is, just because in the flurry of buzzwords that I tend to pontificate, it's hard to keep track of the acronyms, especially when there's like four-letter acronym

plus a number. So RISC-V does for processors what open-source software has done for the rest of the open source world. It actually provides open source instruction set and hardware reference platforms. So if you want to build a processor, you don't have to ask Intel, please build a processor that you'll sell me or go to ARM and say, please let me license this for a lot of money so I can build them.

You know, those are both really good options, and they've worked quite well. But there's a new, you know, third option, which is very exciting to me because, you know, we're really at the first steps of a Cambrian explosion of unique silicon that does very efficient things for, you know for processing deep learning models or other types of parallel processing where doing some silicon optimization can result in a substantially better amount of computation per watt. So the reason why I care about that is for two reasons. The first one is battery life. You know, if we're talking about

edge devices, you know, we need to save on batteries. And the other one is we need to start using so much electricity in the world. Like we need to reduce our power consumption just so that we can preserve resources, right? Like the external costs of burning carbon for a data center are not measured in your cost. I saw Searles the other day. He posted one of his provocative tweets, as he tends to do. Great guy. It was, has anyone done a calculation of the carbon cost of your continuous integration servers? And like dead silence on the Internet.

It's like, oh, you just pulled the covers back and we don't like how we look right now. Don't answer that question. Right. I think about that a lot, just because I think, you can't leave the lights on all the time where I come from, the electrical bills

are a lot more expensive. Anyway, RISC-V is a really important new technology and we just announced experimental support Electrical bills are a lot more expensive. Anyway, RISC-V is a really important new technology. And we just announced experimental support for RISC-V in TinyGo. So you can compile for the Sci-5. It's one of the companies that's manufacturing silicon based on this. They have a reference board called the Hi-5-1. It's super hard to come by because the crowdfunding just finished. And you didn't order from that. You have to wait for their first production run, I think. But it's actually a

microcontroller board based on RISC-V. So we have experimental support in TinyGo for this board, and it's also in the TinyGo Playground. So if you go to the TinyGo Playground and you click on the dropdown to choose the Hi5.1, it's simulating that. And if you go to the TinyGo Playground and you click on the drop-down to choose the Hi5-1, it's simulating that, and if you click on the flash button, you download the hex file with the RISC-V code you can flash on your board. So it's basically next year's demonstration,

but it's today, and it's all in our public repos right now. You're welcome. Thank you very much, Ron. We haven't left the lab that much over the last few months. We've been kind of busy. You guys have been busy. This is the first you've really gotten out, and you've been in the cave working hard.

For how long now? The last conference I went to was in March. And, well, it's not just me. I mean, there's a lot of contributors, you know, all the members I mentioned, and a bunch of other contributors as well. This is very much a collective effort. There's no way any one person can do anything really important. It's a room full of geniuses, and I'm just really excited to be a part of the jam session.

I have my role. I do my part. I try. I try. But yeah, it's very much a collective effort, and it's been growing by leaps and bounds. The number of people that want to do WebAssembly is fairly substantial. It's a very exciting new technology. But the ways to actually go about doing it right now are very, very difficult. You can write C++

code and then compile it using something like mscripten. If you already know C++, that's perfect I guess for you. You can use Rust. A lot of people are learning Rust and discovering it's a very hard language to learn and to use. It does a lot of things for you, but it's non-trivial. You're not going to just knock off a quick little WebAssembly app in Rust without knowing what you're doing. You actually have to learn the language to use it. True with many languages. You can only fake your way around so far.

So Go, the main Go implementation, the MGI, if you will, you can compile to WebAssembly. The MGI. And there's a couple of issues. One of them is that the actual executable file is quite large. Just because Go is big. You know, I mean, hello world in Go. This is how I open my talk. Hello world in Go is about 1.1 megabytes.

And Hello World and Tiny Go is 12K. Yeah. 1.1 megabytes versus 12K. Does the crowd erupt in cheer? At this point, people are like stunned. Silence. They're not really sure. Does he speak English properly?

Is he dyslexic? Both of those things, but I did not make an error in that number. It is two orders of magnitude smaller in terms of size of executable. In fact, there was a really great blog post written by not one of our team members, but a very cool collaborator. I'm sorry I forgot this person's name, but the title of the blog post was using Go for WebAssembly and then compressing it down to a 16K file using TinyGo. He had me at that point. A 16K file using TinyGo.

I'm in awe. But they were able to, using our code that's on the public internets, take an application that they had written using Web Assembly, compile it down to this ridiculously small size. Well, it gets better. It actually gets better. So someone else then did some WebGL experiments. I think it was Justin Clift. And using the WebGL interface from the JavaScript bridge from WebAssembly, they discovered that TinyGo is actually 80% faster than the main Go implementation as well. Probably because we're using the LLVM compiler tool chain, and between Clang and LDD, which is the LLVM linker,

it's getting rid of a lot of stuff. I mean, it's an unfair comparison just because we're a speedboat and they're a battleship. Of course we're going to win. If you want a cigarette boat race and you you know, an oil tanker is not the way you win. Or a canoe. Or a canoe. You need a boat with a motor. You know, a good motor. Okay, canoes

have no motors. Not often at least. Canoe is good for stealth, but not really for speed. I did a lot of canoeing as a kid in Wisconsin. Of course. It's also good for relaxation and enjoyment. Some would say that. Some would say. At least one. It's good for relaxation like the first few miles

and then it's like my arms hurt. How many more miles down river? 15? Got it. Can we stop here? This is my last summer canoeing with my son. If you have a good enough current, you don't have to work that hard, right? You do if you ever want to get there in time for the water.

Okay. I didn't know we had scheduled events. This episode is brought to you by GoCD. With native integrations for Kubernetes and a Helm chart to quickly get started, GoCD is an easy choice for cloud-native teams. With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly for you. GoCD installs as a Kubernetes native application, which allows for ease of operations, easily upgrade and maintain GoCD using Helm, scale your build infrastructure elastically with a new Elastic agent that uses Kubernetes conventions to dynamically scale GoCD agents. GoCD also has

first-class integration with Docker registries, easily compose, track, and visualize deployments on Kubernetes. Learn more and get started at gocd.org slash Kubernetes. Again, gocd.org slash Kubernetes. So you had next year's demo today. Dream with us a little bit. I think you're pretty good looking down a few years and dreaming, Ron. Five years from now, whatever the time frame you pick, let's just assume TinyGo does all the things that it set out to do

in terms of IoT and whatever you think is success. Like what's happened five years from now, or three, whatever makes sense, in the tiny Go world or in the embedded space or in IoT? What does success look like if it just continues apace? Well, I think it was Chris Dixon who said, no, no, it was Mark Anderson who said, software's eating the world.

Yeah. And so I'll add to that. who said software is eating the world. Yeah. And so I'll add to that. So if software is eating the world, then Go is eating the world of software. You know, there was a blog post that came out saying Go was the new Java. What they meant by that was Go is the industrial strength technology that large mission-critical organizations can rely upon to, you know, keep service levels up, try not to kill anybody by accident,

by failing at the wrong times, you know, for things that really, really matter. Yeah. You know, I think a lot of people tend to poo-poo Java, and that's a real mistake. You know, the JVM is either the number one or the number two most engineered piece of software in human history. You know, the other one being Beam, the Erlang VM. So, I mean, you really have to give incredible respect to the number of human hours devoted to taking seriously making this piece of software.

Yeah. seriously making this piece of software. So to say that Go is even in this very small, refined circle of reliability to me is extraordinary. I did a lot of work for AT&T a number of years ago, and carrier grade, carrier grade is what is above enterprise grade, right? Enterprise grade, yeah that's nice, that's like for consumer products. Carrier grade, what is above enterprise grade. Right? Enterprise grade, yeah, that's nice. You know, that's like for consumer products. Carrier grade, that's like for maintaining the infrastructure of our entire continent.

Right. Right. So the fact that we can say that Go is in this circle, very small circle, is very exciting. So big companies would like, or small companies, any company, you want to reduce the number of programming languages you have in use just to reduce the cognitive friction of your ability to maintain all these systems. I mean, any interesting system, the half-life is going to be like five years long. Yeah. Especially when physical plants, you know, you install something at a physical plant in a factory or a retail store, and you say, yeah, it has to be replaced in three years. You go back there in 10 years, it's still there working.

Like, oh, yeah, it was still working. We didn't fix it. We didn't replace it. And they're like, oh, we said it only had a three-year lifespan. Like, oh, wow, really? We didn't know. It's still working. This is just very common in these type of physical locations

because replacement is not easy. Really, software upgrades are even hard enough. So you say we need something that's going to be reliable enough and solid enough, and Go as a language is making the cut. The problem is Go as a runtime has certain assumptions about the environments in which it runs. You know, embedded Linux Go is pretty great. But we're talking about systems even smaller that require substantial reliability.

It's your braking system. It's the airbag system. It's the system that controls the thermal rods in your nuclear power plants. These are mission-critical applications where there are many microcontrollers in use. And no one ever got fired for using C for an embedded system. But why aren't we using C for all our mission-critical web systems? Well,

we know why, because it's very, very hard to use C in a safe way. So all the cool kids, they're not just trying to be cool and new. They're saying, hey, maybe we could use a language that prevents us from doing things that are very bad ideas. You know, that's what Rust does. Yeah. But Rust puts all of the onus on the programmer. It's like the opposite of Ruby, right? Where Ruby says, we will forgive you your small errors and try to do the best we can to interpret your meaning. Right. Rust just says

no. Failure. And tries to give you some meaningful error messages if it can, but if you don't know what any of it means, then that's not helpful. You know, Go also will not compile. It's still got a certain rigor of requiring

like Fumpt. You know, Go Fumpt says, here's how Go code should be formatted. You know, and for the rebel hippie programmer, they're like, whoa, man, you know, like, don't quash my creativity. You know, for the corporate coder, you're like, what idiot wrote this code? It was you, sir. It was you, sir. No way it was me. Git blame. Oh, well, sir. No way it was me. Git blame.

Ah, well, somebody obviously modified the Git logs. Somebody rewrote the history. It could never have been me. So there's something to be said for a certain amount of discipline. Discipline leads to freedom. If you're disciplined about going to the gym, then you'll have the freedom to maybe eat some pizza because you've already worked out. In five years, I think Go will be much bigger than it is.

I think all of these organizations will realize they need to do edge computing, not just cloud computing. TinyGo will have completely conquered the world of the ultra-small. I like to think that is what's going to happen. That's what happens if we all work together to make it happen. An alternate history would be that something else fills the needs that TinyGo is filling. Is there other projects? Is there competition? I like to think of it as more cooperative.

Sure. I mean, it's competition only in the sense of like you can only eat at one restaurant tonight. Right. So is it the competition between the Szechuan place and the Thai place? Only in the sense that you're going to eat at one tonight and another tomorrow night.

In the micro sense, but you can like both places. Big picture. You can like both restaurants. Big picture, you can like both restaurants. And also, I mean, every programming language exists because it does something well. I really dislike when people are talking badly about some other programming language without having really used it. Because every single language does something well. That's what it was created for.

Now, you maybe are using it for the wrong thing or the thing that it does well is not something you care about doing. You know, I'll give you a great example. This language called Fortran. A very ancient language. Never heard of it. Used for mathematics. Still being used by NASA in order to figure out

the orbits of things in outer space. Fortran. If you want to work at NASA, you should learn Fortran. What does Fortran do well? Fortran does mathematics. It stands for Formula Translator. And it's probably the, besides COBOL, it's one of the oldest languages still being used actively today. Because it does this thing really, really well of mathematical calculations.

So it's worth learning Fortran if you really, really care about mathematical accuracy and being able to do substantial amount of processing quickly, you know, because doing these, you know, orbital plan calculations is quite difficult. So every language does something really well. That's why it was created. But everybody wants to use their preferred language for everything. True. That's hard to do.

So I think that there are other languages that are approaching the space of the extremely small. Yeah. You know, again, Rust. There's interesting things happening with Elixir. You know, people running Beam on microcontrollers. You know, that to me is extremely interesting. You know, C++ is not your father's C++ now. It has absorbed a lot of interesting syntax from dynamic languages,

like the auto keyword, you know, and defer things that are very, very interesting in dynamic languages being applied to static languages. Yeah. So, I mean, I think there's a lot of action, you know, happening in the small space. But, and a lot of us are running on top of LLVM. So when we run into a problem, like most programmers,

we assume it's our code and then only gradually come to the sinking realization that it's in the thing we're using and we have to either figure out how to fix that or provide a coherent bug report so that the maintainers can do so. Well, I've had the magnificently wonderful experience over the last months of running into a problem, figuring that perhaps it's LLVM, going to the LLVM mailing list and discovering that a week ago, somebody on the Rust Embedded team reported this. Or a week ago, someone on the Zig team reported this other thing.

Or in their case, going and finding that a week ago, our team reported it. So it's a really great collaborative effort. I mean, I consider open source the shared infrastructure of the 21st century, the roads and bridges of how we all perform our necessary daily functions of life and commerce. And so we're just trying to do our part within that. You know, there doesn't have to be a single winner. No. Right. In fact, we lose by that kind of monoculture because we, you know, any given technology platform or group needs a foil to bounce off of. If nothing else, healthy competition is a kind of sportspersonship.

It means we operate from a place of respect, and when the match is over, we celebrate the fact that we were able to compete together, and then we go on. But open source is nothing like that at all. There is no winner and loser. the fact that we were able to compete together and then we go on. Right. Right? But open source is nothing like that at all. There is no winner and loser. You know, it's more like a... I like to call our hack sessions that we have at GopherCon and other places jam sessions.

Because it's like a musical jam session. There's no winner. Right. There's no loser. You don't even have to participate. You could just show up and go wow this is really cool look what they're doing or you can jam as well

you win just by participating I think it was Albert King the late great blues guitarist said there's only three reasons to play music have fun make some money or learn something

so if you're playing music for some other reason, you should stop. If you're trying to impress somebody or gunslinging, look good, make them feel bad, you should just stop and go home because that's not a good reason to do it. So I try to take that same sensibility and apply it to the things we're doing in open source. And so the winners are all of us if we collaborate and cooperate. The losers are all of us if we don't invite people. I mean, I'll go back to the musical thing.

There have been plenty of cases where a person is sort of shyly standing on the side of a musical jam session that I've been at. And they don't they're not participating but they're there and there's like a glint in their eye that they really want to so if you do it well you pull them up to a mic and then this person who doesn't look anything out of the ordinary opens their mouth and your jaw drops to the ground because this voice comes out and you're like,

wow, thank you for getting past whatever it was and singing for us because I'm just in awe at how great this is. And, you know, I think this is a great lesson for inclusion in tech. There's people with a great voice who are just like, they're not going to sing unless you almost make them sing right so if it's sort of intimidating they're definitely not gonna they're gonna like stand on the side and like well this person's come to three jam sessions and never sung or play guitar i wonder why let's see what we can get them you know many cases they've got incredible hidden talents that if we could just allow them to flourish by giving them an opportunity, and it doesn't have to be forever, it's just one song. Then someone else steps up.

You know, that's about sharing the space. So I try to apply these same principles because, you know, we think tech is about utility. It's not. Tech is about aesthetics. If tech was about utility, we'd all use one programming language. It's about aesthetics. If tech was about utility, we'd all use one programming language. It's about aesthetics. Like, I prefer fuchsia and you prefer green. Why?

No actual reason. We don't have free will, my friend the neuroscientist says. What do you mean? We only think we have free will. Here, this is my same friend who said I needed sleep when I didn't need sleep. He's like, okay, let me prove to you, you actually need sleep. So I know better than to mess with this scientist. Okay, so he proved it to you.

We don't have free will. All right, all right. Go ahead, blow my mind. So basically, by doing functional MRI, this is probably something for your brain show, right? So by doing functional MRI and some experiments with choosing options and button pushing, they were able to determine that the choice of pushing the button occurred before the cognitive part of the brain responsible for the decision making, that it was just a little tiny bit afterwards. So the current best interpretation is we make a

random choice and then we explain to ourselves we made a conscious choice in order to maintain a consistent view of reality. But in fact, we have no free will. It's all completely random. Not to, you know, ruin your belief in self-determination. We better ruin things, Ron. But so it's about aesthetics. And that's what technology is about.

Fashion. It's about fads as much as it is about utility. But it's still about utility. Like, you're still going to need a pocket to put your cell phone in. Right? So if you're making pants without pockets, you know, you're not doing a favor to cell phone users, right?

You're making a purely aesthetic choice with no utility that's the difference between art and design art is just to get an evoke an emotional response and design is about doing something functional right like a glass hammer is beautiful to look at but it's totally useless if you want to do some framing you know of wood knocking down nails. Right. So. I'd probably suck at that job. We think we're purely utility based, but we're not. So, you know, Go is aesthetically pleasing to many people.

So if we can bring Go, you know, again, to like a good politician, bring it back around to my message. If we can bring Go to the smallest of platforms, then we are helping satisfy people's aesthetic desire to use Go and at the same time fulfilling the utility that they need to actually perform an important function that, generally speaking, is not taken very seriously by, like, oh, it's just the sensors, you know, it'll be fine. It's like, yeah, those are the sensors that say, you know, turn off the heat because, you know, the people are about to be cooked or, you know, turn off the elevator because it appears

that the automatic braking system of the elevator is not functional. It might plummet and, you know, hurt people. Right. That's a scary story right there too. Just to change the world, nothing important. That's why we started with toys. Chris Dixon, the investor, he said something like, any sufficiently advanced technology starts out in the form of a toy. I'm paraphrasing a little bit.

So we started with time to go with a toy. People said it was a toy language, so I said I'll build a toy with it just because I have a great sense of irony. Like, oh yeah, it's just a toy. I'll just build a toy. Nothing to see here. Anyone who's ever saw the old 80s or 90s movie Small Soldiers. We're talking Tina, child's play. Like, oh yeah, it's just a toy. Nothing to be afraid of. Just a toy. Friendly toys. This episode is brought to you by roll bar, move fast and fix things,

resolve errors and minutes and deploy with confidence. Head to rollbar.com slash change log, request a demo, get started today. It's loved by developers, trusted by enterprises, and most of all, we use it here at Changelog. Move fast and fix things with Rollbar. Once again, rollbar.com slash changelog.

A toy and a playground. So you have play.tinygo.org. Is tinygo.org the one-stop shop to get involved? Yes. We have a documentation website that's pretty good. There's been some great in-depth pages and also articles written especially by IK who as I mentioned IK Van Lattem is the IK VL on Twitter and GitHub and all that he's really the original project founder even though it's more than him it's all of us now but without IK that none of this could exist so

I really I always have to thank IK because yeah made my dream come true. I wanted to do this for years. And for me, this is truly a labor of love. But it also has tremendous value because this is something that needs to be done. If it didn't really need to exist, I'd probably be working on something else because, I mean, it's fun, but unless it's also important, then it's a hobby. Whereas this is a full-time thing. Let's play that game then. If you couldn't do what you're doing now, what would you do? If for some reason you had to stop doing this mission, what would be another alternative mission that's just, that would be exciting,

like the runner-up, let's say? Well, I think embedded systems and Go is the most exciting thing happening right now. But there's a lot of other exciting things happening in the world. Biotechnology, especially in genomics, is really interesting to me. What do you know about that? I think there's a huge opportunity for bioinformatics. Bioinformatics and cloud computing hasn't really, it's not a problem that's been solved at all.

Material science, I think, is incredibly interesting. Things like shape memory alloys, which are plastic. They're polymers that have the property which is opposite of normal metals. It's like normal metals, when you heat them, they expand, and when you cool them, they contract. So SMAs have the opposite. When you heat them, they expand, and when you cool them, they expand and when, sorry, when you heat them, they contract. And when you cool them, they expand. So they are very, very strong and could be used for kind of artificial muscles. You know, new kinds of solar cells, other kinds of conductive materials,

flexible electronics. That's the kind of stuff I'd like to be working on if I wasn't doing what I'm doing now. Where are you going with this? Where are you going with this? Reel it in. That's cool stuff. The future is already here. Oh, boy.

Right? It's just like William Gibson said, it's just not equally distributed. What about genome sequencing and stuff like that, like programming our cells and CRISPR and that kind of stuff? What are your thoughts? That's really in the bioinformatics and genomics. I think it's very exciting. What are the thoughts? That's really in the bioinformatics and genomics. I think it's very exciting.

What are the ethical boundaries there? Well, I think that ethics in technology is an under-touched subject. My oldest son is a student at the University of Portsmouth in the United Kingdom studying computer science. And last year when he finished his A-levels, which are the English equivalent of the last year of high school, they had to take a class in ethics and computer science. And it was all the IEEE ethics content. And I was really excited that this was part of their required curriculum. He, on the other hand, was sort of like, why do we have to study this?

I'm like, aha, son, you have just opened Pandora's box. Allow me to explain. Sit down, young man. Allow me to explain the need for ethics in technology. So I think there's a lot of biohacking going on right now that is completely unregulated. It's been going on for years. Describe biohacking. Describe biohacking. Describe biohacking.

So biohacking is when you decide to do some genetic engineering on your own using equipment you bought yourself through eBay or the internets. So in 2009, there was a really amazing conference that took place in Canada called Future Ruby. Future Ruby was was a really amazing conference that took place in Canada called Future Ruby. Future Ruby was really a seminal conference. One of the speakers was the team of Nitobe, the creators of PhoneGap, that ended up selling their company to Adobe. There was a lot of really amazing people at this conference.

I was there with my brother Damon flying Ruby Howard blimps. And one of the talks was a professor from MIT who gave a workshop the day before on biohacking. So what everybody did was they grew phosphorescent algae in a Petri dish. So this is 2009. And he's talking about how you can buy a genome sequencer for, at the time, I think it was about $5,000 US on eBay. And needless to say, it has not gotten more expensive or harder to get this kind of equipment. So I think that it's one of the big differences. What was the name of the guy who created the first internet virus? His dad worked for the NSA.

I don't know. Me either. It's not Mitnick. Anyway, it was the first internet worm. So it was not created maliciously. It was created originally because he wanted to map all the IP addresses within this space. And he wrote this code that would automatically download itself onto any computer

and then do the same thing. Made an error in the code, which caused it to escape the subnet, and it took down the entire internet at the time. Got in a bit of trouble, and if it hadn't been for Dad's NSA connections, we'd probably still be in an undisclosed location. Actually, back in those days, they still hired teenagers who were hackers to work for them as security people. Yeah. Not like now.

But take that idea, but apply it to biohacking. Well-meaning person doesn't think they're doing anything bad in a basement, not fully understanding the implications of their work and making an error. No bad intentions. I'm ignoring the bad intentions people just because I think that it's very hard to do anything that works at all in this space yet. So the odds of you making a mistake and having something happen are much greater than bad people doing awful things.

But that's also a possibility. But if all we do is restrict it completely, like, you know, no man's land, you can't go there, then it's going to be done elsewhere. It's the same as saying you can't do computing on the Internet because you might transfer an intranet virus right right so one extreme means we remain in ignorance and then it's like the demon haunted world of carl sagan we don't understand what's going on and it's affecting us the other is every human for themselves with no control and no care over the implications, which I think has been a very common attitude in tech, which is poorly interpreting Grace Hopper's ask forgiveness, not permission. So first of all, many people don't know that Admiral Grace Hopper said that, the attribution.

But also they don't realize what she was talking about, which was she was a military officer in a large organization. And if you've ever worked at a company or an organization that operates at that kind of global scale, it's very, very hard to get permission to do anything because, you know, you need to go up three or four levels in the hierarchy above your boss to get permission, especially if there's no cost to the organization and substantial benefit. So ask forgiveness, not permission meant do the right thing within the organization, whether or not they know it.

That way you can help the people that you work for, not move the extrinsic cost to the public domain so that we can profit. That is not the same thing at all. No, that's true. So I don't want to pick on any particular company, but I think we could rattle off a list of companies whose primary business model is to take public goods and to turn them into private profits. And, you know, to me, that's sort of antithetical to this whole idea of, you know, what is technology for? Well, it's to improve human well-being. There is no other reason.

Right. You know, have fun, make some money, or learn something. And it keeps going back to that. So to wrap it around then, where are the TinyGo jam sessions? Is it the Slack community, like if you wanted to jam with you guys? Or just be a wallflower and maybe get talked into coming and singing? Is it on GitHub? Is it in your Slack? Where does the actual community hang out?

A lot of us are on Slack. Total disclosure, I would have preferred IRQ because I like open source. It's really hard to use IRC and IRQ. Free node is great, but it requires too much knowledge. That's right. And so I kind of gave up that fight. I can't fight everything all at once. I was the one saying we should be using Git

as a distributed version system and not as a hub and spoke system, but that didn't go anywhere either. Not because of pointing fingers and saying you're bad, but more, can we have other possible options? So anyway, we're all on Slack. There's a lot of people joining. You know, Slack is certainly a good platform for this because you're relatively easy.

We have a really active community. There's a bunch of us in Europe. There's a bunch of people in Asia. There's a bunch of U.S. people. So pretty much 24 hours a day, there's somebody around to help. We're really active on our GitHub repositories. This is why we have a few members of the organization, so that we can respond quickly to people's requests for assistance.

Sometimes GitHub issues are support requests and not issues. But we're there to help. I mean, we're trying to, you know, get this technology out there and make it easier for people to use. So, you know, part of our responsibility as maintainers is to do that. You know, we've had a few people come into our Slack and say, why don't you use language X, not X, another language that has a single letter. And we were like, oh, that's a totally cool language,

but we're not really thinking of moving to that, no. We're doing TinyGo. Cool language too, though. Nothing wrong with it, and it should be done. We're not telling people rewrite in TinyGo either. We're saying, check out TinyGo, it's cool, and maybe it will help you. If you like Go, you'll like this. But we're not saying, you need to do this because we're so much better.

I mean, we think it's better or we wouldn't be doing it, but we don't expect it to be better for everyone all the time. But yeah, Slack is great. Twitter, we're tinygolang on Twitter because there already was a tinygo. On GitHub, it's tinygo-org, and that's where we have all our repositories. We have the main tinygo repo with the compiler. We have a drivers repository that's got hardware drivers for a bunch of sensors and displays. We've got the tinygo playground code, which I think needs an update since we moved to the serverless processing of the compilation jobs.

Yeah, we're doing WebAssembly, RISC-V, and serverless all in one app. It's definitely buzzword compliant. Yeah, that's a bingo right there. If you don't find us because we hit all three of those, it's because you're just not buzzword compliant investors.

Cool, Ron. Well, thanks so much for talking to us today, man. Hey, thank you so much for talking to us today, man. Hey, thank you so much for having me. I really appreciate what you guys do. It's a great podcast. You have lots of really interesting, wonderful people, and me, occasionally. So thanks a lot, and check it out, tinygo.org.

Yes. Thanks, Ron. All right. Thank you for tuning in to this episode of The Change Log. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts. If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner,

Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo, and our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for changelog master. You'll find it. Thank you for tuning in this week.

We'll see you again soon. Well, hello there, listeners. How are you? This is Adam Stachowiak. If you haven't heard yet, we're launching a new show called Brain Science. It's a podcast for the curious. Are you curious? Because if so, we're exploring the inner workings of the human brain

to understand things like behavior change, habit formation, mental health, and what it means to be human. It's brain science applied, not just how does the brain work, but how do we apply what we know about the brain that can transform our lives? Learn more about the show and subscribe at changelog.com slash brain science. Until then, here's a preview of episode one, where we talk about

the fundamentals of being human. We're also all designed to be in relationship. We are fundamentally hardwired to have social groups and this sense of attachment. And because I'm sort of a geek when it comes to research, what researchers have found is that attachment, which that's what we label how we relate and connect with others, attachment is 100% learned, which means our genetics don't actually contribute to how we learn to stay in proximity with other people. And with that, that we all develop ways to manage the threat of the loss of a relationship. But nobody gets to opt out of going, I need to be in relationship with others. I mean, think about it within the context of the

prison system. Like, why is it that the punishment for prisoners when they don't fall in line is isolation? Yeah, that's true. Right? That wouldn't be significant if in some way that doesn't actually harm our brain. It's almost like we need to have that echo from another human being to let us know that we were there or we're alive or just some sort of feedback loop. I'm not really sure how to describe that. Well, it really is this sense of being with, right? Like I can't fight battles on my friend's behalf or on my kid's behalf, right? But the simple fact that I know of what's going on makes the difference because I would contend it sort of like I help them hold that weight emotionally.

And so that actually leads me into the third thing. And the third thing that I would say in regards to the fundamentals of being human is that we all struggle. Oh, yes. Right? Big time. And that, you know, we don't always get to pick the way in which we struggle, but we all struggle. Well, if you like what you hear, you should go to changelog.com slash brain science. The show is not out yet, so don't get too excited.

But you can subscribe and be notified as soon as the show launches. Once again, changelog.com slash brain science.