From TinyGo to Takeoff

Hello and welcome to Fall Through, your source for deep conversations about technology, software, and computing. I'm your host, Chris Brando, also known as Scriptable. Today we're talking with Paido Wittingslow. an Argentinian engineer who uses Go in the tiniest of places. We talk about how he got started with the TinyGo project, including how he uses Go for things like trajectory simulations, fueling rockets, and modeling 3D graphics. And, as so many of our guests do,

He's come equipped with a couple of spicy unpopular opinions. This episode has some great bonus content, including a whole extra unpopular opinion that Pato brought with him. So if you want to hear that and so much more, head on over to fallthrough.fm slash subscribe.

And sign up today. As always, if you're not already, please give us a follow on social media. And if you haven't already, give us a reply. We love chatting with you guys. And if you want to see our lovely faces instead of just hearing our lovely voices, head on over to YouTube and smash our subscribe button. ring that notification bell so you can get notified right when we drop those video episodes. And with that, let's get into the show.

First is Patricia Whitting-Slow, who is going to be chit-chatting us through his journey into tech. with a few stop-offs along the way to dive into different problems that he's encountered, technical roadblocks. interesting ways that he's fallen into Go, Aerospace, TinyGo, Pharma. This is a person who has been all over the shop in terms of industries and technologies and has a lot of great learnings and experiences to share with us.

We're also joined by one of your wonderful hosts from Fall Through, Dylan, who has a background in mechanical engineering. So it's very uniquely placed to be digging in today because that's the world in which, like, Pato, you've been digging into. So let's start right at the beginning. It's a very good place to start. I hope that some people got that. So Pato, let's start right at the beginning. How did you start this journey that you're going to be taking on?

Well, somewhere along the line, I graduated from high school. And my grades were very bad. I wanted to be a writer, you know, I didn't, I didn't want to do engineering. Um, my grades set otherwise. So I had to settle on something to do. Um, cause I. You know, uh, and I did, I started on an industrial engineering somewhere along the lines. I realized that wasn't my thing as well. I didn't want to do spreadsheet math.

And then I looked at, hey, bioengineering, mechanical engineering, and I went that way. I guess the next big... relevant thing that happened was programming. I started programming first in MATLAB as my first programming language. If you don't count access SQL as a language. Actually, forgive me. I actually, my first programming language, I forgot about this is, was visual, visual basic. I don't remember any of it, but yeah, that was my first for loop.

And then next year after Visual Basic, I learned MATLAB. That's when I started like solving cool stuff, I'd say. And there was this one problem that always bugged me. So remember I said... I didn't do exactly well in university. Well... I had to redo lots of classes. And when you get out of like, you know, the usual scheduling and you have to like.

do classes again that's when your scheduling gets really haywire you had to like find specific schedules that were not you know the standard and there's 20 000 combinations from time to time you you had like 20,000 ways of like making a schedule that works for you. And that's when I was like,

I want to find the best schedule for me from these 20,000 combinations. I want to build the schedule combinator for my university. There was one, one did exist. It was running in C and it was kind of buggy. It did its job well. But I wanted more. I wanted like to be able to like find free days. I want to like be able to like have Friday off.

That was a thing you could do if you, if you went through all the combinations output by the, by the original, uh, existing schedule combinator, but it was very tedious work and it didn't. Actually, you know, it's buggy. It didn't give you all the combinations. It skipped some. So I set out to do that in Python. I learned Python in my spare time. And it was hard and time consuming for me. I just. Language never clicked with me. I spent months on the problem.

And I just, you know, put it in the freezer. Didn't really work on it for some time. I knew I wanted something different because I wanted to be able to compile my project and distribute it. C program that already existed was a distributable executable, you know, everyone had like a copy of it. You could just run it on your computer, no dependencies. And I loved that. That was so- I don't know what you mean. It's not like there's a hundred different Python distributions on everyone's machine.

Yes. So that was frustrating for me. I like, I went into like some deep corners of the Python ecosystem. I think iron Python was something I looked up at one point, but it was. I just couldn't get it to work. Wasn't that the .NET? Yes. The dot net thingy. Um, with, yeah. So I didn't get that to work and I was like looking for another way out and I can't.

You know, I was the periphery, the periphery, my vision showed C and C plus plus. I, I didn't want to learn that. It just seems so complicated. And then I read it like I'm, I'm on Reddit, you know, program R programming. And I see Go is the next Python, just a random comment. It just said that, you know? And I just was like, what's this guy trying to tell me? He's like, there's another Python coming?

And I recently had gone through like the pain of the Python two to Python three, um, migration. And I was like, oh, it's going to be like a lot of migration or something. I started reading up on go and I started learning it like. And it was just hard. I was like, what is this thing? It's just static types. Ew. And I got out of there. I stopped learning Go for some time.

And it just, you know, I forgot about it for like a year or two. And, but, but the static, the build, like, you know, the fact that you build something and it's an executable, it just stuck with me. And it's just, it's just biting at the back of my head. And then two years later, I see a book at a bookstore, Barnes and Nobles in Colorado, having a vacation with my family. And I see this book and I go, go in 24 hours.

I can learn Go in 24 hours. That's a very attractive, like kind of thing you're proposing, Mr. I think it was George Ornbo is the author. So I buy the book because, you know, like this is going to force me to learn it. And it actually does. It gives me the motivation needed, like actually spending money on go. And I read the book. And I'm like, oh, well, that was okay. And then I start like tackling the scheduler combinator problem with Go. And it just clicks with me.

and i'm just you know i'm just you know michael jordan on the keyboard you know code's coming left and right like closures i discover closures and it's like whoa whoa dude what is this and like I'm writing stuff that I don't really understand, but it's like working, but somehow it's like intuitive. Like the closures are hard to understand. Right. So. I don't think closures are in the book, but it just, at one point I do it.

I'm like, and if you look at my commit messages during that period of time, one of them reads like, Go is effing magic. to not say the actual word i swear so comma i swear uh it was just It's just, it changed everything for me. You know, programming became something that before was kind of like, you know, okay, this is hard. I want to solve this problem. I got used.

this hard tool and that's just the way it is and it went from being that to being something you know that was accessible like oh wow i can i can get stuff working you know i went from writing a command line tool in Python to writing a full-blown like command line interface. So it's like a graphical interface, but with, you know, inside the command line. And that wasn't even the original plan. Right. But like, I found this tool, this library and I was like,

Let's just try it and it just worked. I could do stuff I could never have thought possible. So, shall we move on to what happens after I found Go? Um, so I actually like, I get the within a couple of days after like, writing the schedule combinator in Go, I start, yeah, it just works. So sometimes it took me like two months and I couldn't even get it working in Python, just came to me in a couple of days.

And, uh, after that, it was just like, you know, this is something I want to spend more time on, you know, spend, um, invest in, uh, go seems like it just. Just solves problems I'm having. And yeah, a few years later, you know, I'm using go for hobby stuff. I joined Leah Atospace, start working there full time. There's this simulation. It's written in Python.

As luck would have it. It's a language I'm so familiar with. And my job is to improve it and add features. And I do that for a while, you know? yeah let's do this let's work on on this python You know, I'm actually motivated to, to, to work on this simulation. And over time I'm like, think I keep thinking like, wow, this.

This would be much more easier to do and go. It's just something that keeps thinking and thinking and thinking. And then one day I'm like, I get back home and I'm like, after a day of programming in Python, I'm like. What happens? What if, what if this wasn't go? I'm just like, you know, just spitballing here. I'm like. And at home, I rewrite the entire simulation in Go. And it ends up being so much more readable to me and faster. It's notably faster.

Um, we're using numpy and vectorizing as much as we could, but there were some, there were still some for loops in there. Uh, and so I, I, I come back to work. I'm like, guys. Here. It'll be great. And my coworker who was working with me on this simulation, like. He was already like having a tough time, like following some, some stuff I was contributing. Like I rewrote like this integration engine, um, using Runja Koda instead of like Euler's method.

And he's just, he just looks at what I've done and he's like, you know what? And he just just nopes out and and gives me full. full like ownership over the simulation and I just continue the development of the simulation over next year or year and a half. And it's, it ends up being like a state of the art rocket trajectory simulator written and go that.

Um, I'm not sure if it's still being used, but it's, it's there. Um, we, at one point we're gonna like commercialize it. And there was a, there was a company that was interested, uh, in actually like acquiring because. It was really like state-of-the-art. It used like a... Runjakoda Nystrom 12th order integrator for orbits. And you just don't see that kind of like technology in. commercial integrators. When I say integrator, I'm referring to this math function, I guess.

Solves the equations that calculates integrals. Yeah, it basically from your derivatives of your system. it calculates like the, the future evolution of those, of those functions. Um, so yeah. And. And that's when it was clear to me that Go was like, you know, Go can be used for this easy. I remember just enough from 25 years ago to actually know what you're talking about. Couldn't do it today. Couldn't talk intelligently about it. But I do understand what you're saying. So if I had like.

I'll say my unpopular opinions for then. Um, but yeah, I was going to say, I was going to have a spicy take there. Uh, but yeah, go, go is just. Amazing for, for simulation. And I ended up using it for embedded systems as well. We were writing control software in Arduino. running on an arduino uno at the aerospace to control The loading of fuel. that was to be launched. And that was like one of my first projects that they just gave me. It was like, hey, who here knows Arduino? Oh, you?

you're in charge of loading all the fuel to the rocket it's got the equivalent of 22 kilos of TNT That's in your hands. Low stakes. No pressure, but you touched it. It's yours now. Oh, lots of pressure. I think the fuel was at 22 bars or something like that, or 40 bars. so that that's that's a lot of pressure actually um Pun intended? In all senses. You said Go was great, but I'd love to dig in a little bit more. I know you said it was faster.

more easily readable, but I kind of want to dig in a little more what you mean by that, like specifically why you felt Go was so great. Well, at the time, I wasn't able to tell anyone why it was so good. I was like, this is... Like, look at this. All I could say was like, look at this, man. Look at it. It's somewhat more readable. But over the, over time, like I started teaching Python at university. Um, and I started like.

noticing stuff, um, that happens when you teach Python. Like there's a lot of context that's lost when people write Python and they do it without types, for example. um the way data structures are defined as well is um you don't the data structures isn't clear in python i mean i'm talking about your run-of-the-mill Python, right? The Python you teach with dicts and lists, the day instructions are not clear. They're not. aesthetically available to the programmer as is the case in Go.

where the data structure is in the function signature. You can hover over it and it shows you, hey, this is your data. And that lack of context I've written in some documents that is... that go over this i've written it's it's just very noxious for the learning process for the the cognitive processes in your brain there are people that you know they don't need that context but a lot of people i've worked with

when teaching Python have needed that extra context. And you can really tell like when, when you're teaching someone and you're like, oh, this, this is what the function receives. It's a, it's a schedule. And they're like. Okay, but, and they don't know what to do with that information because. And you can't really tell them you can't really like get in there and teach them because you're like, just trust me. There's, there's a key in schedule that.

Start time. And there's a key, but just trust me. That's the best way of teaching with Python. Sometimes if you don't have type. I think it makes sense. I think I'd love to understand. And other than like readability, ease of understanding, like brass tacks, like functionality of the language. If you take that away.

and if python was as easy to understand as go was like just purely like what the language can do are there reasons why like looking back on the problems you were solving go was the right choice or Is it really, like, the understandability, which is very valid as a point? I'm kind of interested to understand, like, truly just brass tacks, what you can do with the language. Like, if there are reasons.

Why you would go versus Python or any other language. There's loads of reasons. This is one of the main reasons. I mean, the fact that it's so inclusive for developers that don't have that. that working memory because that's that's what cognitive psychologists call it it's like extra slots in your working memory it's like it's like you're

You have hardware you can work with. You can't exceed the hardware limitations of your brain. And besides that, besides the ease of, you know, the context types provide. There's also things like try catch. Try catch is, is just, you'll hear people like arguing, oh, but try catch is so good. But man, it's having like not being able to tell which function throws.

And you're basically giving the library you're using, the calling function, power over your control flow. And that is... that is a terrifying thing and And if you think it's not terrifying, well, I'll let you know NASA thinks it's terrifying because they disable exceptions in their C++ code, which runs on the Curiosity rover. Exceptions are disabled. They don't want errors if they are exceptions. I've had those debates over the years a lot of times. I started off writing C.

So you call a function, it returns null, and then you have to check error node to go see what went wrong, which is not a great system. But you know that the thing that you just called. had an issue, and this is where you go to find out what that issue was. Errors are values. Errors as values are one of the, it's just such a change in paradigm. And I think I was thinking about errors as values before I got into Go. That's really how I've always thought about errors because I would...

All projects I started with Python, I'd make a big dictionary with all the errors I can have.

and like number them like this is area one it's this message i was already like doing that because i like it's just That's just so much better than... working with exceptions but to yeah to contrast that with the exception model like you said when you catch an exception there's no way to know if it came from the thing you called or something that you don't even know exists 37 levels down this call stack.

And people will say like, oh, but go has exceptions. Yeah. Yeah. But it's not the same. Hold on there because this like Python's ecosystem is just, it's just meshed intimately with the exception. You call any function, you call index. You call index in Python and you pass in, uh, you, instead of, you know, index, if it, if index doesn't find the, the position of the byte of the character or string you're looking for, it's going to throw an exception.

it's not gonna it's not gonna like let you know hey look i didn't find it um here's uh here's a little flag then you know it's gonna be like whoa dude we didn't find the string you're looking for end it all just kill the process bam red button and that's that just blows my mind that people think you know this is this is the way you're meant to program every time you can't find a string inside of another string just crash your entire program

Yeah, it's crazy. I spent a lot of years writing C Sharp and it has a similar philosophy where every error is an exception. And the argument is exceptions can't be ignored. Which is valid, but kind of like you said, there is no need for an end of file exception to exist. Like when you read a file and you hit the end of it, that should not throw an exception. You're going to catch an end of file exception to detect that you're done reading data.

And TypeScript's TypeScript developers... are starting to realize this right like you you you look at big youtube streamers like theo gg the guy made a library which um basically wraps your exception throwing code and makes it so it returns just like go And he like explicitly says, yeah, this is like Go. It's better. Just shut up. And the guy's a big TypeScript fan, but he recognizes like, hey, Go is...

It goes really good for some stuff and people are starting to realize that this is a better way of working with errors. So yeah, it's just. In my younger days, I had a tendency to make that argument, to go, exceptions suck and this is better. As I've gotten older and... wiser air quotes, finger quotes. I've actually kind of shifted to what you were talking about with the cognitive complexity.

Like I find and a lot of other people find it's easier to understand what may happen in code that returns errors as values compared to code that uses exceptions for control flow. What I usually tell people is Go is a language that has engineering as a core central principle. You know, it's meant to be easy to learn.

You've got like error handling as like, like a core central concept of it. And it's, um, it's implemented very well. You got like a very small set of features, a very opinionated language, you know, and I think that's a core. core thing about engineering. It's like, Hey, these are our requirements and we're going to, we're not going to stray far away from these requirements. You know, we're going to implement what we really need.

That's just how engineering works. Like you define, hey, this is my problem. set my problem scope. I'm going to solve this. And that's what the goal. devil like the go team is doing they're like solving that problem set they're not implementing you know what epito wants in the language you know oh i want i want to be able to call try on my errors they might do that There's a new proposal that just came out this week. I saw it. Yet another error handling proposal. Yes.

And I mean, if we all agree that's a good way to go, then we'll have try as a keyword and it will be. As someone who's ridden the wave of several go-to-esque proposals, Anything that introduces a new keyword has a very low probability of being accepted. Ah, but the Go team assures that thanks to how GoMod works with the versioning, It's not such a big problem now. Yes, so it's a solvable problem.

It doesn't mean it's not going to be awful for everyone who has a symbol in their code somewhere called try. Look, I'm playing devil's advocate. I don't want that to happen, honestly. Like I said, I spent a long time writing try, catch, finally, in a ton of code. And I'm very much a fan of returning errors as values. I'm not, I will not get behind anything that effectively introduces exceptions to go. I'll be open. I'll be able to hear the other person out.

So Pado actually came with two unpopular opinions for this episode. One of them is at the end of the show, which you can catch by listening all the way through to the end. But the other one is actually right here in the show. Well, it's right here in the show if you're listening to the supporter edition.

So if you want to hear that and so much more, head on over to fallthrough.fm slash subscribe and sign up today. It's really great content. But for now, let's get back to the show and hear about Tiny Go. Okay, Pato, the time has come. Let's talk about how Tiny Go came into your life. Oh, yes. I remember it like it was yesterday. Me too. I was about to mention, so working at the aerospace, I was doing the simulator, writing the...

multi-physics rocket trajectory calculator thingy. And I'm also working on an Arduino loading fuel into a highly explosive rocket with an Arduino. running an HTTP server on 32 kilobytes of RAM. That was very hard. And I started thinking, could I do this in Go? And I Google Go, Arduino, Golang, Arduino, and something pops up. And I read it. I'm like, what was this? It's a tiny Go, go, go.

Tiny goat, what's this? And I joined the Slack. I'm like, I think I joined the Slack. I started like asking questions maybe. Don't remember exactly how it happened, but I tried it out. It was kind of unstable at the time. Couldn't really write programs that would not explode after some time. Uh, so it was, it just stayed in the back of my mind for some, some time as like, oh, this would be nice. Um, I can't use that work yet.

At one point, I think I did write a networking stack in Go so that it could run on 32 kilobytes of RAM. And I managed to get an HTTP server working on the Arduino Uno. i think it was like the world first uh go server go http server running on a microcontroller that has a networking stack in go because it was the nano 33 iot implements all the TCP stuff for you. But I implemented TCP in Go, and that was hard. And it just showed me, okay, this can happen. It works half of the time.

Because, oh man, that code base is just awful. It's out there somewhere. We can leave in the show notes. I think it's called Ether Switch. And it was just terrible. I have some of that code out there. And so after showing the TinyGo Slack channel, Hey, um, I got a LED to blink through HTTP on the Arduino Uno, you know, I got a couple of thumbs up there. And I showed them the video and it kind of, I left it in the freezer. And I was just like, it's kind of a toy project.

I can't get this working reliably. I could, if I invested so much time, but I can't right now. And then the Raspberry Pi Pico comes out. I think it's 2021. And I'm like. It was like a general purpose compute microcontroller. It had tens of times more memory than the Raspberry Pi Pico. It ran, I think. i think like 10 times faster as well had like 10 times the the clock from 12 or 16 megahertz to 125 megahertz. And it's, and you looked at the hardware specifications of this thing and it was just.

out there. Like there's nothing like it for that price. It costs the same thing as Arduino Uno. I got really excited at that point because this thing was going to be available all around the world. And I suspect it was going to be available in Argentina. I live in Argentina, by the way. This got me really excited and hopeful for the future of Go on microcontrollers.

Because I knew if we could get go to run on this thing, it was going to perform so much better than on the Arduino. And that's going to like be able to maybe use this thing at work. and not just toy projects. And so once it came out... I think Ron Evans got, you know, he sat down, got to work, implemented all the stuff that needed to be implemented so that we could get our first hello world compiled on this thing.

And after that, I was like, thank you, Ron. You're the man. And I just started like chipping away at all the things, all the other things that needed to be implemented so that I could use it. Like the SBI drivers, the PWM. I implemented all those stuff on the Raspberry Pi Pico. It's funny you mention Ron, because you're talking about, I made an LED blink. That reminds me of his GopherCon talks.

From around the same time where he does the whole spiel and he goes in and shows the code and this and that. And then he's on the stage and look. And it's like, bleak, bleak, bleak. It's brilliant. It's almost anticlimactic, but it's like, look, I made an LED bleak. like watching the first time I saw him present anything and like...

Don't get annoyed at me now, Ron. We're great. You're great. Love it. And the end of the story is going to be positive. I remember turning to the person next to me and being like... like a light blink like i could do that followed up afterwards i think even like i think you were even there i like went up to the table where he was like teaching people how to do it after i was like let's take like two seconds i'll just do it

so now when he makes that light blink you have a real deep-rooted appreciation because of the complexity that comes in not negative complexity but just like it takes a lot to make that happen So the fact that you can use TinyGo, which Pato, I hope we'll talk about a little bit in like the real world to power real life scenarios that are important to go right.

really important and impressive because I feel like I've heard over the years Chimiki people be like oh Tiny Go is just like a little fun toy language that just makes things blink and makes like a fan spin or maybe you can do a little drone um but it's like in the world operating things that like probably people would be very surprised to hear about That little blinking LED is the first step to real things.

Yeah, absolutely. It's so, it's so important that I went ahead and made a talk where I made the led blink again last year. So we, we tiny gophers love making led blinks and then showing people. It's a way to make it feel accessible. And it is a starting point. and once you know how to make a light blink you can then make two lights blink and maybe make them do different colours like it really is

Don't even get me started, the colors. I know, the colors. You can figure a bunch of lights in the right layout. You can make numbers and words. It's wild. And yeah, like blinking the LED is like first step because it shows you, you have control. You know, it's like, this is a powerful concept. You can like shine a light on something or maybe like enable something outside of the, of your microcontroller. And that's what I've been using TinyGo for.

Lately, you know, Ash solving real problems at real companies. And yeah, but before that, I had to get the Raspberry Pi Pico working, which eventually, you know, we got all those interfaces implemented. And I guess after, after I implemented all that, boom, the Raspberry Pi Pico W comes out. So, and that's the next version of the Raspberry Pi Pico with the wifi chip. And I just went, I was just like.

oh my god yes like this it brought like it brought back flashbacks of when i had gone go running on the on the arduino uno with the hdv server to blink the led and i was like We gotta, we gotta get this, this thing working. So, um, as soon as I got ahold of one, I started working on that driver, which was one of the, definitely the hardest thing I've ever done in my life. That was.

And it was so painful because I started porting the C driver from C to go. Uh, and it was, it was just so unreadable. So unreadable. So, uh, just. And at the time I had programmed in C, I had started doing C at. Stam by the time. So I left the outer space, not before leaving a Raspberry Pi Pico controlling, acquiring sensor data from the rocket engine. So Cool use of Raspberry Pi Pico there at Lea Aerospace.

After I left the aerospace, I joined STEM biotech biotech company, where I started using go to like control, uh, stepper motors and acquire sensor data on CO2 humidity. and pressure to control biological processes. So basically cell cultures growing inside of controlled environments. And this was all like using, um, a bit of embedded go, like not tiny go, but, uh, upstream as we call it go using the parif library, really, really good library.

for running on Raspberry Pis. Then the Raspberry Pi Pico W comes out and like, I gotta get this thing working. And it takes me like, it takes me, I guess, six months to realize I couldn't finish it as I was doing it. Like this is, this is. My life's going right past me. And I find a rust driver. So a driver of this wifi chip written in rust.

I have it working. I have the go version working because I poured it. I ended up porting it from rust to go instead of from C to go. It just goes, I mean, that goes to show like.

Not my thing for readability. I prefer rust. And yeah, I had a. i had the wi-fi chip working on this on the pico w i start work i in parallel start working on a on a new rewrite of the networking stack halfway through i rewrite it again And on version three of the networking stack, I finally get the Raspberry Pi Pico W with the wifi working and I, yeah, and I start, I used it to solve some problems at work with MQTT messages.

to control uh to like uh observe a process uh pressure sensors and co2 so yeah that was it's quite a trip hardest thing i've done uh implement the driver for the CYW 43439 and write the networking stack version three, which is called seeks. And I'm working on the fourth version. Now it's called El Neto. We were just saying version zero is throwaway code anyway. Yep. Exactly. No, that's really cool stuff.

Because kind of like we were saying earlier, there's been this sentiment that TinyGo and Go in embedded systems is just... for the nerds to go play where it's uh it's real world it's concrete you're doing real things and affecting actual IRL processes, not just imaginary playing around with it stuff. It's very cool. You can grow cells with TinyGo. I'm living proof. Take that, Rustations. They probably got something there going on, I think. We can make life. We can make life.

Yes! Play God with TinyGo. There's the GopherCon top for next year. Play God. And my work eventually got featured in a book. So sometime... last year, um, Ricardo Girardi reaches out to me and he's like, Hey, is your library going to be available? Is it going to, it's going to stay under this link, uh, this GitHub repo. And I'm like, yeah, why? And he's like, oh, we're writing a book using your library. And that was. That was huge for me. Like I felt like, wow.

You know, getting your work in a book is like, I feel like it's a milestone that, wow, you know, you're doing things not so bad if, if, you know, people are like writing books about your stuff. But what's more prestigious, being in a book or being on a full? I think we know, you know, this, this has got to be the, the, the, the biggest thing I was actually extremely nervous before going in. I'm still, I'm still kind of nervous. I'm still like, Ooh, and.

Well, and I, I will, I hope it has the same effect as being in the book because after, after the book was published and I got my copy, um, it's right over there. You need a bookshelf placed right behind your head in the camera. Automate your home with Go. After it was published people's love people started using it much more like God whole influx of people who are like filing issues, you know, being super annoying. No, no. I love, I love people who, who file issues. Please.

Yes, please continue fighting those issues. They are extremely helpful to me. And yeah, it just showed me, hey, okay, people are using this. They're finding it useful. It's got... Lots of issues, which we fixed a lot of them, but a lot of them I was like. You know what, this is unsustainable. I can't keep working on this. in the state that is in, and I had to rewrite it so that the library, the networking library was more testable because it was not.

It's not very testable. I learned a lot of things. And yeah, that's one of the projects I'm currently working on. El Neto, User Space Networking Library in Pure Go. putting your stuff out there in the world you'll get plenty of comments plenty of issues okay so we've talked a little bit about go talked about tiny go i now want to talk a little bit about go tiny go and 3d design

Ooh, yes. Because that is an area that I'm very interested in. I know you're interested in. I know a load of gophers are delving in, trying it out. I'd love to hear a little bit about... how that came into your life but also some cool stuff because i know you've done some cool and done some good thinking about 3D design. Like most of the interesting stories we've delved into, this one also starts in LIA Aerospace.

when I was a full-time developer there. The gift that keeps on giving. Yeah, a lot of cool stuff came out of there. One of the things we were doing there was... Designing piping fittings, you know, for connecting tubes so that we could load fuel into... One into the into the rocket or the testing stand and pipe fittings like have a special threading on them

And if you want to design a threading so that you could 3d print it, you got like parametrize that thread. It's called an MPT thread and it's not exactly trivial. Like I just mix draw squiggly lines and like there's There's a bit of geometry involved. There's a lot of complicated math that goes into it. Yeah, in particular, so the MPT threads are designed so that they don't leak when, uh, liquid goes through them and if they're correctly tightened. And so I started like.

We started like designing them in our software we use for design. And it was kind of hard to design. And actually, I don't think we were able to design any. It's just they didn't come out right. And so I started looking at like. software that generated 3d objects. And I learned about, uh, SDF, um, because the first thing I did was go 3d CAD. And the first thing that pops up, if you search that, not sure now, but back then it was SDFX. It was a library that lets you program.

And in, inside of this read me, it says like better than open SCAD that's because open SCAD, uh, is this is like the industry standard way of doing this, of like programming your shapes, your 3d shapes so that you can 3d print in. OpenSCAD is kind of like a pain to use. I didn't, I think I might've, I tried OpenSCAD and then I went over to SDFX and it was just wonderful. And I even contributed the NPT thread using their existing threading stuff. And I was able to 3D print.

um the the pipe fitting and uh that really got me thinking like could I do more hey more you know I always want more yeah I want a 3d print and then I want 3d print the entire engine from go Uh, that, that was the sort of thinking I was going through. I was like, Oh wow. We could like automate not only the design, but also the simulation. So be able to like. design, code, parametrize, and then boom, generate a 3D mesh and like simulate it in...

Uh, using like, you know, solid mechanics solvers, they're called finite element analyzers. Uh, and that would like simplify a lot of the automate a lot of what the work we do. It turns out it's. extremely hard like the whole world isn't there yet like not even um that's why it's not there because it's hard

Yeah. People still like, you know, do most of the stuff like manually, you know, the design, the meshing, you know, correcting the mesh because you still, still got fine tuned. Some things, um, still need some human hands in there. And so I added the NPT thread, printed all that stuff. And I also could like, I did suggest changes to SD effects. Um, and they weren't exactly accepted and they were stuff like I considered important.

So I did what anyone would do. I just wrote my own library, SDF library. You know, just, why not? Obviously, because everyone writes their own 3D rendering library. So I was convinced I could make it easier to use faster. And I, it didn't take me that long. Like I think it must've been like a month or two months on my own time. And I, that's when I came up with SDF. That's my, uh, as the first, the first one is always throw away the first, um, 3d design library I wrote.

So I started experimenting with API, different API designs, which I had wanted in the, to try out in SDFX. And yeah, I'm not sure if lots of people are using it. It's currently, I've archived it because I... somewhat because last two years ago at gopher con i told i told um I told someone, Kaylin Gibraltara. I was like talking to Kaylin. She's got this amazing like... startup that designs, um, 3d printed stuff and it's really cool.

And I told her like, she told me she used OpenSCAD and that it was a pain and it took minutes. It looked like five minutes to render some constellation pieces. And I told her like, Hey, have you seen this library I built SDF? Not to brag on myself, but have you tried this library that I wrote? I was curious, that should not take five minutes to render. That would take at most 10 seconds to render with my library. And so I told her about SDF and she was like, for the love of God.

why haven't you told me this before I'm gonna kill you and she was like very mad very mad she didn't tell I didn't tell her last year when we talked she gave a talk she had given a talk the year before about Um, using open SCAD to like do these cool designs and hand told her because, you know, I just, I didn't, I didn't want to shill, but now I show all the time, right? Like this whole episode has been me, me shilling my stuff.

Um, because, you know, I think people can find it useful and Kaylin had to, would have, it would have been so useful for her. It would have saved her so many, uh, so much time rendering those, uh, constellations because. SDF is really fast compared to like OpenSCAD, the industry standard. I can picture Kalen right now. Like, can I use this? And you know, the Tara is her company. It's amazing.

They've got really cool stuff. The first time I met Kalen was I was walking off stage when I did a talk at GopherCon on a project that we built to... essentially build a graph database of Go module dependencies. And we're backstage and they're taking the microphone off. And she's like, is that a real thing? Like, can I use it? Because it would totally solve a problem that I have right now.

And, and so after I let her know about this and I, after I saw it would have solved a real problem, someone that was having, I got like, I got thinking like, Hey, this could be better. I could actually make it much faster with what I've learned. And I did what anyone would do. I just rewrote it from scratch. Because, you know, that's what you do. Because why not? I rewrote it from scratch, leveraging the GPU.

So go using GPU for 3D design. I think it's quite a novel sort of proposal and it ended up being so much faster. Like it runs orders of magnitude faster. You have no idea. And... Yeah. Hopefully it'll like, if you, if you have to design a part and it's to be, you want to write and go, you don't want to use open SCAD. Um, I strongly suggest you take a look at GSDF. That's the new library I wrote.

It's fast. It's API is very comfy to use. It's got like, I ended up consolidating the API between an error-free. and an error returning API. I know we just talked about how returning errors is so good well in this case i made an exception to the rule i i didn't i don't return errors on my unintended and exception to the rule exactly But you can also configure it so that you don't panic. You can configure like obtaining the error after you generate your parts.

Or like throwing a panic during the generation. It's an interesting approach, I think. It was suggested to me by Axel Wagner during last GoverCon. And I think it just makes so much sense for my application. That reminds me years ago reading about, this was back in my Windows days, when they were redesigning the C Sharp compiler. It was called Project Roslyn.

And the whole idea was don't throw errors because you actually don't want an error in the middle of this thing because the default state of the world is that things are broken. But it was they had a very. pervasive philosophy of keep going and hold on to the errors until the end or stuff them off to the side and do all the work that you can do because that's more productive for the situation.

And yeah, I think it works. It works pretty well for my, my use case where you, you sometimes have like people who don't want to be. working with errors because they're just designing a part and they want to like compose, uh, the interfaces nicely. And yeah, I think try it out. I mean, people seem to love it. Um, for the audio listeners. That was totally a salesman face. So, Wink Wink, try it out. Maybe got the double fingers. It was great. Yeah, it's all good in the moment.

You should go try it out. I'm just saying. There's even a talk I gave at GopherCon Australia, a lightning talk. which I had like one day to prepare where I showed the project and also did some salesman stuff there. No shame in it. If it works and it's good and you, you know.

If you're not going to sell yourself, who else is going to do it for you? Well, I think it's a good segue to what I've been doing now. I'm currently so after stem biotech last year i i left stem biotech stopped working with those stopped playing god basically and i went over to aerospace back into aerospace And right now, I'm currently working on... uh, you know, simulating the boards, um, in specifically, uh, doing solder joint fatigue analysis. on the PCBs and to do that

I write the simulation in Go as maybe some of you may have guessed. Yeah. And it go still great simulation language, great modeling language for physical phenomena. And the reason I said Segway is because maybe... I'm using GSDF for the work I do because one has to be able to, um, study the computer and computers have multiple layers of copper stack. So it's kind of like a, you call it a laminate your motherboard inside your computer. Boom. It's a laminate. No, it's got.

layer of fiberglass stacked up on the layer of copper and copper pathways. GSTF can be used to like render 2D shapes. So draw out like pathways. And once you draw the pathways, you can study them like, oh, okay. This is the shape of my copper. What are the mechanical properties? and whatnot. So interesting use case for Go right there. Yeah, definitely not typical. The reality is most of us are out here writing web services or CLIs.

yeah i feel like i got lucky you know i'm being able to like push the boundaries on what go can do wherever i go Or at least that's how I, you know, I feel it's probably been done before. I know go is being used at NASA JPL for like, uh, riding drivers. So, you know, it's also being used at SpaceX for their telemetry, rocket telemetry acquisition. A lot of interesting things for sure. What has been the most like interesting way that you've used? It can be girl or tiny girl.

when i say interesting i don't mean like the easiest it could be like you it was the most interesting because it was the most challenging i'm really interested to hear because we've had all the different spaces or different problems that you've needed to use and wanted to use go for like and i'm going to ask Dylan you the same um because i'm very interested from your perspective as well um like what is the most interesting problem you've solved

Most interesting problem I've solved with Go. Oh, wow. What a question. Well, I think... One I haven't talked about, which I find is very interesting is using Go. to control the rocket engine test setup. So, back in... we always go back to the aerospace back at the aerospace um we needed to we made rocket engines and then we would test them to see how well they do measure the force with what they push and also the pressure within the chamber. Before I got there, we used a C sharp.

Um, program written by a third party, which we would hire on a per hour basis. And we would like changes requested would take weeks to like be written out and delivered to us. And they were always delivered on an SD card. They would come to us with an SD card and be like. This is a software here. And we'd like plug into the Raspberry Pi, uh, four or three, and it would just run. So I proposed, Hey, we, we gotta be owners of this stuff. Cause this is our core business.

And we, so I went ahead and rewrote it, uh, in, in go cause we had the source code and it's, it had like a, a backend, a web HTTP backend. which controlled like the the actual backend, which was like the Raspberry Pi pins to like send, uh, commands to the, to the actuators. Uh, we, it also control like the rocket engine test engine, uh, set up. had valves to open like It had like six or eight valves to open different parts of the... of the fluid flow to outgas if we ended the experiment.

to open the valves leading to the rocket engine. And there was a very specific way which you had to open it because if you, if you open them, if you fully open both, both valves leading to the rocket engine and you got a blow down, uh, uh, tank. The engine explodes because you fill it with, you might fill it up with a full of hydrogen peroxide or full of.

Uh, the, uh, the fuel and then whichever gets one there first fills it up. And then the other one comes in and boom, you got like explosive reaction. So you had to like time them very specifically. You had to like, uh, we had to do some measuring of. of the pressures to like get the timings on those valve openings correctly and reflect them in the go code. So things don't blow up. How lightly he said that. So the edges didn't blow up. Just in passing, very hand-wavy. So we don't blow things up.

And I find that very interesting, like use like writing code, which, you know, has. as dire consequences if you get it wrong uh if hey if this routine because these are go routines we use go routines for each each actuator uh just so that you know we didn't block by accident and you had to get them If you don't get it right, boom! It's a critical failure and this is called a safety critical system in systems engineering because your machinery is at risk of hardware damage.

And it's not often like, you know, you hear Go is used for safety critical environments. It's also real time to an extent because you do have like. um, timed constraints on those valves opening. Um, they are in the millisecond range because it's a mechanical system. You got fluid, it's not electrons. So you got some leeway compared to like telecommunications.

but still it's like you gotta open within a period of time or else I guess my most interesting Go project that I did, kind of because it speaks to the strengths of Go, it was essentially a report that was generating an email report that was a tarball. It would run, I think it was five different queries. against a database and take all those and write them to files and take those files and write them to a tar and then take that tar and gzip it and send it.

over an email. But it was interesting because it was the entire thing ended up being just a pipeline of IO readers and IO writers. And Maine was essentially one call, but all of the different parts. were read and write the you had a reader it ran a query it took a writer and it wrote and it didn't care whether that was a file an OS file or a netcon or whatever the case may be. It was just writing bytes and kind of composing those layers.

In what turned out to be very simple code after I got it all working and kind of like, you know what? Like, self pat on the back. This is actually really nice code. And it works. It's still running to this day. sending tarball gzip tarballs over email clients generating a report all the time but it turned out to be extremely simple code very easy to follow kind of to circle back to what you were saying earlier

I know that like if you go look at it today, you can tell what it's doing. Oh, that's running a query. And then that feeds into this stage that. writes it to an in-memory file and then that writes it to a tar and that tar gets fed into a gzip and that gets sent to the endpoint that's uploading it. And it was maybe 2,500, 3,000 lines of code total. And it turned out to be very simple, easy to follow code. I feel like the whole chaining IO readers and writers together in Go is just...

Everything, everything can be an IO writer and there's so many standard library implementations. You can just, oh, here's a, here's a tar ball. Here's a jzip tar ball. Here's a thingy that also implements the right people. It's just like so nice. Oh, sorry. You also brought something that I feel like. how you wrote the code and it still works to this day. I feel like

Go code is just so resilient to like bit rot. I've found like projects that are 10, 10 years old, 11 years old that maybe render up. The, a PCB board, like the copper layer of PC board. And I'm like, dude, this is 11 years old. There's no way this is working. My Python programs don't work after a year.

And it's just like me. Oh, I have to generate a go mod file. It works like back then there was no go mod files and it just it just works how how what is this black magic co-programs just work after years and years of abandon i attribute that to a And you mentioned it earlier, kind of a conscious... mindset of keep it simple like

The Go team and the Go community kind of at large has taken this stance of Go doesn't do everything. We don't have to have every feature in every language pulled into Go in order to be productive. And in case y'all wondering what I'm talking about, there's this, I can't find it right now. This RS274X Gerber format Golan. Let's see if it pops up here.

I can't find it right now, but there's this one go library. That's there's, there's not been a commit in 10 years. It's called like go RS 274 X renders images of PCBs. And examples, like, I think you have to like edit the go mod file. Like you have to add the go mod file and maybe change one or two lines and it just works. Find it and send it to us. We'll link it in the show notes. The magic of

Post-production editing. We found it right away. It was there. I think the most amazing thing, though, is it works without a GoMod file. GoMod files make your code indestructible. But even if you don't have a goat mod file, like just have to like edit one or two lines. Boom. Amazing. So with that, you've been teasing us for like an hour. Yeah. About your other unpopular opinion. Oh, yes. Let me find it here. I mean, clearly it wasn't all that spicy, if you have to remember.

If it was super spicy, it'd be burning a hole in your brain. It's not spicy, to be honest. It's not spicy. If there was one thing I would change about Go. I would add generic parameterization of constant array lengths. So I'm referring to issue 44253. Of course. Y'all know the number. If you follow the Govish tracker. And this issue kind of proposes that we add the ability to not only like define generic type. but also let users specify with a constant the size of the arrays within a type.

And so this is important to me because I work on embedded systems a lot. And you want your memory to be like very constrained, you know, have, you know, be know how, how big your memory you're using is. And a way of doing that is embedding your. the slices instead of having slices, allocating slices at initialization is just having your array of the memory you know you're going to use in your type.

And you're like big type, which does all your logic. And this would change the way we program in TinyGo. It would not only allow a lot of. memory-constrained usage, it would also open the door to compile time calculation of things. So when I say things, I mean, things like hardware parameters, like, Hey, we want to compile this program and have it run at. 125 megahertz on the Raspberry Pi Pico. Today, if you want to do that, that's got to be a constant in your program.

because something that's known when you compile a program before you run it. And the one way of doing this is Having yeah, a constant, which you define somewhere. The user can pass in and it sets the CPU frequency, for example, in the example I gave. Given the raging debates we had on whether Go should have generics at all, I could see that turning out to be unpopular.

There's going to be a camp. It's too complicated. It's too fancy. You're trying to make Go like Java or Rust. I liken it a lot to getting closer to Zig's comp time. If you've never used Zig, CompTime is just, I've heard it's amazing. All I've seen is it being used as generic types. Now Chris and Matt are going to invite you back for another episode to talk about Zig.

Ah, yeah, Zig. I find Zig to be fascinating, honestly. I'm very hopeful where it's going to lead the world of software because it's got some great things going for it. Yeah. Still, I do go. We did an episode, I guess, about a month ago now. where they did an interview with Mitchell Hashimoto. Oh, yes. And they both came out of that episode. Very big proponents of Zig. Like, Zig is cool. We should maybe even consider not doing Go anymore and going right Zig instead.

I think Zig is amazing. I think it's going to be big. Uh, I don't think I'll ever stop doing go because. Zig is just, it doesn't, it doesn't really fill some of the niches go is good at. So yeah, sorry, Zig. You're amazing. I donate to you. I I'll give you money so that you, you grow, but. no it's not you it's me like i'm i mean i'll watch you from a distance and i'll be like yes good good good yes continue yes excellent

Well, this has been an absolute pleasure, genuinely. Is there any final thoughts, either Dylan or Fata, you want to add before we wrap this baby up? Um, I'm, I'm just happy to be here. Happy. It went, I feel like it went, you know, pretty good. I'm leaving with a good feeling. So I'll leave it at that. I'll kind of wrap it up as you might think Go is not for that, but maybe think about it. Oh, yeah. That's a good tag. Dive in and give it a shot. It may work out. I agree. I like it.

I like it. Go in strange places or go that's out of this world. this world yes or we should just name it after that company for an aerospace it's always been aerospace playing god with go i like i like that i like that there there is one person that does More God playing than me, though. That does go. And that's Timothy Stiles. Timothy Stiles plays Go hardcore. So may get him on. And he's actually, he's actually God.

I think it's called Timothy Stiles. I'm intrigued now. What does he do? Tim, Timothy Stiles. He has a genetic engineering library in Go. So he literally plays God. He genetically engineers organisms. Is he part of the team that created Dire Wolves this week? As a random parting thought, did you see that story? They have de-extincted, air quotes, direwolves by editing DNA of wolves and dogs.

I was not aware of that. Yeah. And they're going to try and bring back the woolly mammoth, the dodo. I mean, have you seen Jurassic Park? Because that's where we're going. No, exactly. I'm like, also, do you know how big the dire walls get? Like... They're going to be running away. It's going to take one person being like, I fancy a dire wolf pet. And then they're going to be running rampant through the streets eating people. I've always been fascinated by wolves. I had a wolf hybrid.

Years ago and random person on the street probably doesn't understand how big wolves actually are. Like. A random wolf is probably twice as big as the biggest dog you've ever seen. And direwolves are bigger than that. Yeah, direwolves are just... Inconceivably large.

biologically engineering direwolves or other animals using go let us know and if there's any listeners who are doing work in that space we'd be very intrigued to hear about it so please do reach out to us that would be a very interesting episode Yes. If you have any comments, anything to add, hit us on the socials. We're on all the places. Thanks everyone. Thank you.

Thank you once again to Pato for joining us for this episode. This episode of Fall Through was hosted by Dylan Burke and Angelica Hill, and our guest was Pato Wittigslah. Fall Through is produced by Chris Brando and Angelica. It's the sun. Y'all need to go to therapy. Wow, I can't English today. Somebody that I used to go. People don't like to go anywhere, right? Everybody's going back to Java. That's what I'm saying. Hashtag.

Yeah, fair shot, slot, shot, slot. Both, both work. Fair slot at the table. Nope, that doesn't sound right. Thank you. Oh my God, my brain. I'm so sorry. I'm so sorry, my brain. And then we can make it live. Yes.