Go Time – Episode #250

Mat's GopherCon EU diary

with Mat Ryer & friends

All Episodes

Join Mat Ryer on his journey to Berlin for GopherCon EU 2022. Along the way he chats with Egon Elbre, Ale Kennedy, Ole Bulbuk, Christian Haas, Bill Kennedy & Ron Evans. Danke!



Sourcegraph – Transform your code into a queryable database to create customizable visual dashboards in seconds. Sourcegraph recently launched Code Insights — now you can track what really matters to you and your team in your codebase. See how other teams are using this awesome feature at about.sourcegraph.com/code-insights

Square – Develop on the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today’s business needs. Learn more at changelog.com/square to dive into the docs, APIs, SDKs and to create your Square Developer account — tell them Changelog sent you.

Retool – The low-code platform for developers to build internal tools — Some of the best teams out there trust Retool…Brex, Coinbase, Plaid, Doordash, LegalGenius, Amazon, Allbirds, Peloton, and so many more – the developers at these teams trust Retool as the platform to build their internal tools. Try it free at retool.com/changelog

Notes & Links

đź“ť Edit Notes


1 00:00 Opening "danke" 00:24
2 00:24 Sponsor: Sourcegraph 03:04
3 03:28 Intro 00:44
4 04:11 Traveling to Berlin 03:27
5 07:38 Berlin is cool 01:35
6 09:13 Egon Elbre (part 1) 00:41
7 09:59 Ale Kennedy 02:43
8 12:49 Ole Bulbuk 02:39
9 15:47 Sponsor: Square 00:52
10 16:47 Christian Haas 04:22
11 21:15 Bill Kennedy 31:04
12 52:39 Sponsor: Retool 00:42
13 53:21 Egon Elbre (part 2) 03:23
14 56:44 Ron Evans 06:33
15 1:03:22 Closing "danke" 01:13


đź“ť Edit Transcript


Play the audio to listen along while you enjoy the transcript. 🎧

Hello, and welcome to my Go Time diary. I’m on my way to GopherCon EU. I’ll be co-hosting there, with a group of great people. I’m gonna be looking forward to the talks, and the hacking days, there’s conference contributor chats that are gonna be, we’re gonna play Gophers Say… We’re going to do a panel with the Go team… So it’s a packed few days. I’m very excited. It’s gonna be hard work, but I thought what I’d do is record my thoughts along the way, and sort of bring you with me on the journey and give you a little peek behind the scenes. So let’s go!

Okay, I’ve just arrived at the airport… Yeah, the drive was okay. I wouldn’t say the driver had good breath… But he more than made up for it with his erratic driving. And he did suggest to – instead of bringing me to the actual airport, just dropping me off at a nearby roundabout… But we both agreed in the end that that was absolutely insane. He wanted to avoid the charges, but… I decided to cover them for him. So here we go, I’m gonna now head into the airport. I’m on my way.

Okay, through security… Didn’t even get checked, didn’t even pat me down, or anything, so going to the gym was a waste of time again… And now I’m gonna find my gate. Ah, I think I’m on time. I might just make this.

[06:06] Somebody was just a little bit lax on the old escalator etiquette there, leaving her bag way behind her as she stalled at the top… And it was inevitable I was gonna run into it, because you know, the stairs are moving… So I did fell a little bit. Being British, I apologized, even though we both know it’s 100% her fault…

All boarded now, ready for take-off.

[flight attendant making an announcement] [07:03]

A bit bumpy landing, but I wasn’t even scared. My tummy went funny a bit on the way down, but I didn’t even cry. I definitely didn’t cry.

I just love the vibes here in Berlin. It’s very cool; there’s graffiti everywhere. Everyone’s got this sort of punk kind of – almost like a dystopian vibe, which I just think is great. Someone told me the motto of Berlin is “Poor, but sexy”, and that resonates with me. I grew up poor, and I was a sexy kid… No, don’t say that last bit. But I don’t know, everyone just seems very nice and welcoming. Someone just gave me free olives. Do you know what I mean? Just as an example… Free olives. I can’t complain – oh… Yeah? Oh, okay. Oh no, I do – I’ve gotta pay for the olives. But still…

An old lady just dropped her shopping bag, and I helped her pick it up, and she just went “Wanker!” Which is absolutely – I can’t believe it.

Here I am at the Go Contributors Summit, and there’s a lot of gophers assembling now, as we speak. I’m gonna talk to a few of them. I’m here with Egon. Hello, Egon.

Hello, Mat.

How are you doing?

I’m doing well.

Is this the first time in Berlin

Yeah, it’s the first time.

And how do you find it so far?

It’s nice. The street art is amazing.

Yeah, isn’t it? It’s like the whole city is tattooed.

Yeah, exactly.

And what are you gonna be speaking about?

I’m not sure which table I’m going to attend. The static analysis one seems enticing, and yeah, the Factory Automation I’m like, wondering what it’s about.

Yeah, I don’t think it’s got anything to do with Java factories. I don’t think you need to worry about that.

I really hope so…

[laughs] Okay. We’ll catch up with you later then. Thank you.

Yeah, okay.

Alejandra is here… Aren’t you?

Of course I am!

[laughs] How was the tour? You went on a walking tour of Berlin this morning, right?

Yes, it was a lengthy tour… But I’m gonna tell you, being from Miami, the weather was perfect for a walk.

Oh, really?

I wasn’t hot at all, I didn’t get tired… It was wonderful. We saw so many places… Victoria was the one leading the tour; it was amazing. She knew so much about it. It was really like the insiders’ tour, or something like that.

Oh, nice.

I didn’t feel like a tourist. I felt like I was walking with a friend, and she just was showing me around. It was very nice.

That sounds great, yeah. So what was your favorite place you’ve visited?

Um, I would have to say that – I don’t know if it’s my favorite, but the most impressive one for me was the Holocaust Memorial that was created for Peter Eisenman. It’s very impressive, it’s overwhelming, beautiful… So many feelings at the same time that one place can bring.


There’s nothing I can tell you that would reflect the same thing, because you would be standing in the same place and you would tell me a whole different story. I think that’s the beauty of that place.

Wow. And the city is so beautiful as well, isn’t it?

The city is really beautiful. Today I was talking to my daughter, she’s somewhere in Cambridge and whatnot, and I was telling her, if Berlin was a person, it would be a cool, old, tattooed dude. That would be Berlin, if he was a man.

It’s like tattooed, isn’t it? The whole city.

Yeah, it’s like the whole city is wearing whole sleeves of tattoos, and it gives it character. I guess the mom in me gets annoyed, because I see beautiful buildings with writings, and then I have to get over that, and then see it for what it really is. There’s a lot of people voicing things, and that’s amazing.

One of the nice things about GopherCon EU is that it moves around as well. So we had one in Iceland, we had one in Tenerife, and now Berlin… So it’s great, you get to visit these places that you would otherwise maybe not go to.

That is amazing. You have a different take on it, because usually the organizers give you a little bit of an insight of wherever it is that you are. They kind of like curate the experience for anybody that goes.

Yeah. Great. Well, I hope you enjoy the rest of the time, and I look forward to hosting with you.

Will do, thank you so much.

It’s gonna be fun.

Alright! I’ll see you on Saturday. Thank you.

Yeah, see you then. Thank you.

I’ve just tracked down Ole Bulbuk. Ole, hello.

Hi, Mat. Nice to meet you.

Nice to see you again. You’re doing a table at the Contributors Summit on long-term maintenance. What is that? I only do quick projects and then leave it for someone else to worry about… What is long-term maintenance?

Yeah… [laughs] That’s when you come like three years after a few guys have been working on it, and then find a total mess, and think “Oh dang, now I have to take care of it…”

[laughs] Yeah. Do you think Go has a kind of particular advantage when it comes to long-term maintenance and legacy code

I think it has quite some advantages. There is often only one way to do something in Go, so there’s only one way to mess it up usually, too. That’s great. And it has been done with scalability in mind; that’s absolutely fantastic.


For example, no circular dependencies between packages, which in the long run is really great, even if it hurts sometimes in the short run… And yeah, I think it’s a rather pragmatic and simplistic way to work with code, that you say “Simple is better”, and so on. This is really great and helpful.

[14:15] Yeah. It pays dividends over time especially, doesn’t it? I know what you mean. And what about the backwards-compatibility promise? That must be a big part of this, too.

Yeah, of course. If you have a language that evolves really quickly, every year an incompatible version - well, then you either stick with a very old version, that has security problems after a while, or you are constantly evolving the whole thing, and always – or you are still doing it like two weeks before, and you should really catch up now, and so on.

Yeah… We’re not naming any names. Swift *cough-cough*

Yeah… Or JavaScript, or so… But yeah. And this is really nice, of course, for Go, that you can count on it and build something solid, and maintain it without a whole team working on a rather little codebase all the time… And you can do it just as a side project when there is not much functionality to be added, but you can really maintain it easily.

Yeah, that’s a really good point. Well, enjoy the conference, and I’ll catch up with you later.

Thank you!

I’m here with Christen – Christian… Oh, okay, let me say that again…

Can I say who I am?

Yeah, yeah… Can you pronounce it okay?

Yes, I hope so…


So Mat is here with Christian Haas…

Thank you. [laughter] Christian, you’re doing a table discussion about – it’s called “How to assert”, right?

Yeah. It’s called “How to assert”, because I was given to have it a name with only three words. And I also realized it should have been better called “How to assert in tests.”

Ah, right.

So [unintelligible 00:17:12.07] It came out of a Twitter discussion.

Oh, yeah. You could have also had “Assert yourself, baby.”

It could have been, yes, and a totally different discussion would have come out of it.

Yeah. That would be a very different Terminator. I don’t think Terminator was written using test-driven development… Otherwise it may be a little more out there

Well, he shoots first, and I know he asked first “Have you seen John Conner” and then shoots

That’s true, yeah.

So there’s still a question before it. Yet it’s way beyond what we are discussing here on our table here…

You’re talking about then testing in Go, and specifically about the assertions; are you talking about the code structure, and things like that?

Essentially, the code structure, almost… The question was “Do we manually assert?” Like, in an if my got values equals the want value compared to do it right in assert library, whatever is A B and or Testify, or any other of the assertion libraries that are out there.

[18:09] Yeah, that’s interesting. I mean, at one time Testify as a cert package was the most imported package in Go… And when we made it, we kind of were used to writing tests like that, and we just found the three lines to be verbose and repetitive, because you still wanna print out what the values are, and things. But it has, of course, the benefit of – you know, it’s very readable, and you don’t have to learn anything new. So that’s kind of the trade-off, isn’t it?

That’s the trade-off. And the question, or at least the curiosity that came now to this question was “What are the reasons that people would still choose such an assertion library?” Because it can go back and forth. Yes, you have just laid out the reasons - you want to have it readable, some say they don’t want to learn a new library… Yet my question is “Okay, what kind of reasons do the people have that do use an assertion library?” And I would also like to bring in the four rules of simple design - are we breaking them, or are we actually adhering them if we use either or the other?

Yeah. And Testify has, of course, the Require sister package, which is where it aborts early…

That’s right.

That’s also a choice that people make. Some people prefer assert where you can just keep going and make lots of other assertions…


…and other people like to just have one failing thing at a time.

Right. So this is then the question “Do you want a checker on properties as a whole, as a group we have the property that I’m going to test consists of several smaller things that I would not expect, or do we want to require this particular thing not to be nil because if I would continue then it would be lost anyway

Yeah, right. Exactly. And when we designed is, it actually returns booleans, so that you can write them inside if statements. You can say like “If this is not nil, basically, then…” And then that will fail if it is, but otherwise it returns true and you carry on into that block, and stuff. But yeah, I quite like the abort early style myself, because I love the fact that you get like a to-do list from your tests, and you just get the next thing that you have to fix.

Right, right. This helps in test-driven development as it is. Then again, the question is “Do we want to immediately break up because you want to stop?” And I’ve heard people saying “Well, if this one fails already, we will be pretty sure anyway what the problem is”, and then you can skip the next requires or the next expectations, because if the first one is already broken, you have to look at it anyway.

Yeah. Very cool. Well, I’ll come back and chat here after you’ve had the conversation and get your sense of what people think. I’d be interested.

Yeah, more and more people are coming in for this - not roundtable, but rather rectangular table discussion… But yeah, all good here.

Yeah. Good. I like the pedantry.

Thank you. Thank you, Mat.

Thank you!

This was Mat Ryer, with Christian… [laughter] See you around.

Christian Haas, thank you.

Alright, thank you.

Oh no, I can’t believe it… Bill Kennedy is here. Hi, Bill…

What?! I can’t believe it. Mat Ryer is here.

[laughs] So you’re doing a roundtable on educating gophers… And you’ve been doing that for a long time now, haven’t you?

On the Go side, since 2014… Yeah…

Yeah, wow. That’s the first GopherCon.

Yes. I got to even speak at the first GopherCon, which was pretty cool.

Yeah, I remember it.

That’s because nobody knew me yet, and they needed speakers, and I was dumb enough to say “Sure…” Which was actually the first conference I ever talked at.

Was it?

Oh, wow.

800 people. It was with the Go team, if you remember, all sitting there.

Yeah, yeah.

Yeah, that was a little nerve-wracking.

Is it on YouTube still?

I imagine Brian and Erik still have that website… That’s interesting, because I’ve never looked at the – I did a cool little video with the Gopher in Walmar– shopping stuff, and I’ve played that first, and everybody laughed…

[22:12] Yes, I remember it.

I’ve gotta find that video. I don’t think I have the video itself anymore, but it will be part of the talk somewhere.

I must have that somewhere. Yeah, because I just randomly lived in Denver, and was getting into Go, and then the conference was just down the street from where I lived, just completely randomly. So I was at the first GopherCon in 2014.

You were living in Denver?

Yeah, yeah, I lived in Denver.

I didn’t even know that.

Yeah, yeah.

But you were coding in Go before you walked in there, or you were just like –

No, we’d built Testify before that conference.


Yeah, because I started doing it when it was 0.56; before it even got to 1.0. I remember oserror type, and stuff like that.

Yeah. I started in 1.2. 1.2 just got (I think) released, and that’s when I started. See, what’s interesting is you started before 1.0 release, right?


Which had to be – what made you do that? Because that’s a big risk, right? Like, I just heard Google announced another potential programming language to replace C++, and now my brain can’t remember what the name of this thing is. It’s a weird name… They’re announcing it. And my brain’s going “I don’t wanna go anywhere near that right now…” So you’re like that person that saw an announcement…

Yeah, well, I was building something for App Engine, and it just supported Java, Python, or this new Go thing with an experimental badge. And that was before it was proper – I think it was before 1.0 that it supported that. And I just wanted to do some really simple database stuff, and I’ve found it very easy to do in Go, because it was very clear – I don’t know why; it was just easy to pick up. But do you think teaching Go is easier than it would be teaching other languages?

I’ve taught C++ before. I taught at a vocational level. So when I was maybe in my mid-20’s and my wife at the time go pregnant, she couldn’t work, I had to pick up a second job. So I picked up a job teaching vocational at night. I was able to make an extra thousand dollars a month teaching these classes, three hours Monday through Thursday.

So I was teaching C++ at the time, because that’s what I was coding in. And when I look back on that, I don’t think teaching Go was necessarily any easier than C++. I think it’s about understanding what your student needs in order to be productive. If you’re doing training, I believe it needs to be practical. They need to be able to walk out of that room maybe at the end of the week and go back to work and feel more empowered…


And sometimes I have to tell people “Don’t go crazy refactoring right now. Just moving forward, and if you have this opportunity…” But I think any training, I don’t care what it is that you’re teaching, if the student walks out of that and doesn’t have the ability to use it – and maybe not on Monday, but… Then what are you doing in there, right?


And I think the same thing – I say this all the time for the stage talks. If you’re giving a talk about tech X, and I’m using tech X, and I don’t walk away from that talk knowing something that I can practically use… People like academic talks.

[25:57] Yeah, I know, they do. I know, they do. And there’s value in it. I quite like the academic ones, but there’s nothing like that being able to actually do something with what you’ve learned. For me, learning in the context of some real problem that you have is the way I learn… And I did my book – the Blueprints book was about building real little projects. And some people complained “Oh, it didn’t go into all the depth of all the concepts and stuff first”, and it’s like, “Yeah, I didn’t.” I deliberately didn’t.

No, but that would be a 10-volume book too, which people don’t understand. You have maybe 20 pages, 25 pages to explain something in a book, and you have to really decide what level… Or you go off to tangents. But how cool is it in a conference – I’ve been in really good talks, when the person in front of me opens up their laptop, brings up the code and they start… Like, for me –

That’s a win.

That’s the win, right? Or somebody coming up and asking you questions about their job. “Hey, I’m doing…” To me, that’s what I wanna see, at least for me, in trainings at talks; that’s what I wanna see.

No, that makes a lot of sense. So do you have to figure out the level of your audience before you’re teaching? It’s difficult at a conference because you’re gonna have people at all levels. How do you deal with that?

If I’m doing the 20 to 30-minute talk, then no, because at that point you’ve already described hopefully what it is you’re gonna explain and show, and if it’s one of these multi-track, you’ve labeled “This is for intermediate. This is what I’m gonna do. Either it’s for you or not”, whatever.

If you’re in a workshop, then I think it’s really important to try to gauge who your audience is. Now, if you’re super-lucky, 80% are gonna be at the same level. Regardless of what it is, they’ll be at the same level. If you’re super-unlucky, there’s an even distribution of beginners, intermediate, and advanced, which is what’s gonna happen to me tomorrow…

Yeah… [laughs]

Right? Because there’s so many new – everybody I’m meeting here, it’s their first conference, they’re mostly new to Go… So you’re gonna have the mix. That’s the challenge. But I always say this to everybody - it is better to overwhelm someone, than underwhelm. Always.

So I’m always gonna try to – again, if it’s blended, I’m gonna target the intermediate; I’m gonna throw inside advanced stuff. I might just say, “Okay, now for all of you that are – listen to this. It’s not gonna make any sense to you, but…” And I pull them back in.

And then the other thing which is critical, if you’re in a room – it’s a long day conference and you have this mix. What I’ll tell the more advanced students is “There’s material here for you, but there are gonna be moments where you’re gonna say “I know this.” So what you need to do is understand that you’re gonna be a teacher at work. At some point you’re wearing two hats: you’re a student, and you’re a teacher. So what I want you to do on those moments where you know this, I want you to focus on how I’m teaching it.”


And whether you like the way I’m doing it, then use it. If not, then how would you do it different?

Hm… Either way, there’s something there, yeah.

But focus your brain on what I’m saying and why I’m saying it; not for you to learn, but to learn how to teach.

Yeah. That’s a really good point. Are there enough people teaching Go? Do you think we need more?

There are a ton of new books coming out from new people… And I only know that because – and you may get the emails, too… “Will you review, review, review…?” Right?


[29:48] And I think that’s good. The interesting thing though is Go has not really changed in ten years. Okay, we added generics, and there’s been mass improvements in some internal runtimes. But when people say “Bill, your ultimate Go is on video. It’s like two years old, it’s gotta be outdated”, I laugh. It’s not. The semantics haven’t changed, we’ve got backwards compatibility, promises… And I threw generics in the book, and I’m not gonna teach it, because 1) I don’t have time, and 2) I don’t want you to really use it, unless… Right?


So we’ve got a new book coming out. I don’t know – I try to push people away from the general books. I go “We already have them.” We’re lacking - and I say this all the time, and nobody wants to… We’re lacking standard library package books. If somebody’s listening to this and they’re thinking about a book, do not write another Go in Action, and Go PL. It’s been done, we don’t need another one of those. You’re – I don’t wanna say wasting time, but you’re wasting time. What we need is a catalog of standard library books. How do you use a strings package, bytes package, time package? That would be – and these are nice books; these are 40, 50-page book, and you can sell them individually, and you could have this whole collection.


And every day, I would pick up one of them - because I have to google time, and bytes, all the time, because I don’t retain that stuff… Right? I just need to look at something.

Yeah. And it’s still protected by the backwards-compatibility promise, so you’ve got longevity in the material as well

That’s right. You’ve got it. So on the new book, what I did is I self-published, so I can update it when it’s absolutely necessary. Because once you go to print, you’re kind of locked in.

What do you do - go around to people’s houses and give them new pages to sell a tape in

Well, they can always download the PDF new, which is good…

Oh, so they get that for the life of it.

For the life of it. You just grab all the new PDF. If you wanna get another print - that I can’t do anything about, because that’s Amazon cost… So we have that. We haven’t had conferences, really… I mean, we’ve had conferences, but for some reason me personally - I don’t watch conference talks. Maybe I’ve watched a handful of them over the years, but I watch it for entertainment. I rarely watch it because I’m… I don’t know why. That’s interesting.

Yeah. You don’t do that to learn, you mean…

No. Somebody I know is giving this talk, and I wanted to see it… Or maybe a handful of times… But I don’t have patience for video. I love reading, because I can read very, very fast… The video, I have to put on 2x, and try to parse it.

So video for conference talks for me are not where I go. And I’ve been asking people where they’ve been getting, and mostly it’s been books, and then searching online. So you’ve got the books, I think they’re valuable, I’d love to see a whole other set. Video - I do video, because– And I think that stuff is in. But I’ve never looked at Udemy, I’ve never looked at Pluralsight, I’ve never seen anything negative about them, so then it ends up becoming a cost, I think.

My big problem with video is I’m gonna be more expensive than you going to Udemy. Even though I give away a ton of video for free on scholarships… People don’t really know that they can just ask me, and I will give them discounts. I do it all day.

I hear stories all the time though, that they saved – “Oh yeah, Bill just gave me this thing, because I’m a student, I couldn’t afford it”, and they got in touch, and…

I didn’t do this for you not to see it, or read it. Right? But at the same time, I’d like to believe that the quality of material I’m providing is going to be better than anything else out there.

That’s why you do it, right?

At least I have that belief system. So I don’t mind the sales team trying to sell three or four sets of videos for – I don’t even know what they sell it for. Maybe $800. But I don’t honestly know how many times we actually sell that free [laughter] I’m constantly being told that “Bill, this isn’t a charity. This is a business.”

[34:14] [laughs] Yeah. That’s why you need those businesspeople, isn’t it?

Yeah, that’s why I need Ed, and Miguel, and all those guys. But I also didn’t do it for it sit on a shelf… So if you want material that I have, all you ever have to do is reach out and we’ll figure it out.

Yeah, that’s great.

So I think that stuff is really good. And then what else is there? The books, video… And then I guess googling everything.

Yeah. What’s the big challenge educating? What’s the thing that people struggle with the most, in your experience, when they’re learning Go?

I break up my training in two parts. I call it a micro-level understanding and a macro-level understanding. So the micro-level understanding is when we get down to lines of code. That’s the readability, the simplicity, the syntax, the idioms. And you need that. If you really wanna engineer – there’s programming and there’s engineering. And I tell people that are working with me, “Do some programming right now. Just give me code that works. I couldn’t care less if I didn’t see a single error, if. I’m not looking for that right now. Once we’ve got code that works, now we’ll talk about engineering. We’ll engineer.”

So at a micro-level, it’s critically important to have those idioms and understand what it means for something to be readable. And then learn how to refactor for simplicity. But after a week of Ultimate Go, I don’t think you have the ability to go back and be as productive as you could. It’s not necessarily a practical – I almost call it an academic-level class… But you need it, because it sets the stage for the next Ultimate service which I’m teaching here, which is your macro-level.


Now we’re gonna talk about architecture, now we’re gonna talk about project structure. Now we’re gonna talk about macro-level idioms, and practical things like building and logging and configuration. And I don’t wanna have to have the micro-level conversation when I’m doing that.

Yeah, yeah.

But I think you need both. So the hardest thing is if I get somebody in my macro-level class, that hasn’t taken my micro-level class, I have to fight to not take tangents, and just say “You know what - I’ll get you the video. Let’s do that.” And on the micro-level class, I have to remind myself that - I know that there are gonna be people here feeling like this was a great class, but it wasn’t a lot that I could do, other than maybe change the way I wrote some functions here and there.


I don’t think people understand how much they get out of the micro-level class until their product’s in production, and now they start hitting the tooling a little bit, and now all the little things I said… Because I’ve gotten that fever. You know, data class and then we started having problems in production, and like your voice just started flying all over my head.

So I think as a teacher there, it’s – I don’t know, I’m always fighting to make sure I’m giving the person what they need… And the struggles are just different. Everybody’s struggling with different…

Yeah. But can people learn – I feel like you’d be able to learn the macro stuff. You have to sort of be okay with not having the complete picture down to that detail, but you can still learn concepts, and retrofit that. Or do you find that you do need that foundation to build on? Is it more that way around?

[37:56] I think with Go we’ve already learned that within three weeks you can build just about anything you want, and it will run, and it will run pretty dang good. And if you wanna leave it like that, you can. We’ve learned that already. So what comes down to you is what level engineer do you wanna be? You just wanna be somebody who’s programming, and does the bare minimum? And that’s fair…

Yeah, sometimes that’s appropriate. Like, if you just have to solve a problem that just you have right now, you wanna process these files and change them, or… And that’s great.

That’s it. And it’s fair. And you’re the only one who’s gonna worry about this… It’s totally fair. We got it to – remember back in the day when the community got crazy, like if you weren’t writing idiomatic Go, you were evil?


Like, what the hell, guys? So I’m glad I don’t see that as much as we were in the beginning, where maybe there were more academics than there were people just saying “Tell me what to do.”


So I think that’s fair. But if you wanna be a better engineer, and really think about readability, and maintainability, then –

Yeah. You’ve got a big team, or multiple teams working on a codebase that’s gonna have a long life, then it’s a different game.

Yeah. And you don’t wanna know… On all of my teams, when I start a new project, I tell everybody “I don’t wanna know who wrote any line of code when I’m looking at it. If I know who wrote this, we’ve got a problem.”

That’s interesting, yeah. That’s funny, because with go fmt and the fact that there isn’t lots of different ways to do things in Go - there tends not to be - you do get sometimes this effect where you look at some code and it feels like you’ve written it. And that’s such a –

It is. But let’s talk about where that can go wrong. Variable declarations.

Okay, yeah.

Right? So I’m teaching all the time, var for zero value construction. I don’t wanna see short variable declaration operators, I don’t wanna see empty literals unless we’re on returns, right? So there I can pick out that “This is it.”

Yeah. Because there’s multiple ways to do it, that’s why… Isn’t it?

To me, it was a necessary war to keep the compiler simple, but there’s a war there. It’s one of the first things I teach in the micro - I don’t care what you do here, but have a plan.

The other thing is I hate the else clause. I hate it. Use a switch. Use the naked switch. It’s much more readable. So the moment I see an else clause in a piece of code, I freeze, actually. It’s horrible. I get stressed out… Like, “This has gotta go.”

Have you ever considered making like a Bill linter, where you put your opinions into this tooling?

No, because the static check linter is really good, and everybody should be supporting Dominic on that project. We do at Ardan with the GitHub contributions.

Ah yeah, sponsors.

Yeah. Everybody who’s using that tool should be giving them something every month, because what he’s doing is amazing. Now, I did start writing what we were calling the Ardan Playbook…

Okay, yeah…

…which was all of this – and I got about ten pages in, and it was so tedious to write…


Because this wasn’t kind of conversational things that I did. This was literally–

Complaining. [laughs]

Not even complaining. It was just very dry. It was “Do this, and not this. Then this, and not this”, and after about like a day, my brain just started to shut down, and I couldn’t – and I have a little bit of it out there, but… I did put a lot of it in the Ultimate Go Notebook, but it’s not like formally listed, like I was trying to do with the Playbook… I don’t know.

Yeah, I did a talk at Gotham Go in New York City called “Things in Go I don’t use”, or “Things in Go I never use”, or something. Else is one of them, and I make that same point, of like – you know, you sort of hide the happy path in this indentation, and things like this…

[42:02] So yeah, I agree. Anything we can do… It’s really thinking about the usability, the user experience of your code. Because that’s why you get away with a lot when you’re the only one that’s going to be working on it. As soon as you’ve got more people that are gonna be maintaining this code, then you’ve gotta think about them.

But it’s bigger than that… Because look, here’s the reality - I’ve been in this industry for 30-something years. To date, that I know of, I’ve got three projects still in production. One that’s over 20 years old, one that’s over 10 years old, and one that’s a couple of years old. So what I don’t want for people is when they finally finish and they retire – their legacy is that nothing they’ve done over the last 30 years is still adding value on the planet. This is not what you want. At least that’s not what I want.


So if you’re not writing code for the next person… If the code you’re writing, you’re not thinking about the next person, two things happen when you leave - either the next person says “This is shit, and we’re throwing it away and rewriting it”, which could also now mean it ain’t in Go anymore… Right?


Or the other thing that’s gonna happen is it just gets completely abandoned… And now it’s almost like it never existed. So what keeps you up at night - finishing in this industry and not having anything to show for it. This isn’t like we’re building a house that’s gonna be here a thousand years from now…

That’s true, that’s true. It can be so transient, can’t it?

Yeah. So for me, that’s like the nightmare situation. How many late nights did you have at the office at a previous job because you had to finish this code? And guess what [unintelligible 00:43:54.02] today? You realize how insignificant that was, because it’s not even running anymore, and you ruined your day…

Yeah, absolutely. I’ve experienced that. And I have to remember it when I’m now working late to do this. It is worth remembering, in a few years this won’t be important. I do have to keep – I completely agree. But with education people though, a legacy - that’s a multiplier of what contribution you’re making. And I don’t know that you get visibility into it. You probably have no idea the impact you’ve had by all the people you’ve taught… But that’s gonna be big, if you think about it…

There are times when somebody comes up to me and they say – so here’s the most recent… Just to have this conversation. And I know everybody hates blockchain, but Ethereum is moving now to their new proof of stake blockchain, right? They’re very close to putting it in production. I met one of the developers on that team, and he was like “Bill, we’ve all watched your videos when we were beginning to build all this code…” And my brain went “Whoa…” That’s kind of surreal, right? Because I’m not directly coding, let’s say Ethereum blockchain proof of stake, but there is some aspect of what –

Yeah, your contribution. That’s the thing, there’s gonna be loads more that you’ll never even hear about. There’s gonna be loads of that, and you won’t hear about most of it. So you should be happy, I think, that that’s the difference you’re making when you educate gophers.

And that’s for anybody, because again, everybody’s an educator at the end of the day, whether you’re doing in front of people or you’re just doing it at work. You’re constantly educating.

[45:46] I think one of the big jobs that are missing in the industry, and we can’t have it because there’s no way to measure it, is that every company should have the tech lead who’s a floater. This is what I want; if I ever sold Ardan, I wanna work at different companies for like a month to three months. I have no responsibility for product, but I would – let’s say I went to Grafana, I sat down with you and your team, and every day I pair-programmed with somebody different, for a couple of days, to help them learn how to refactor, look at the code, think about it, and make everybody a better - at least based on my design philosophies and guidelines… But try to make everybody better on that team, and get everybody rowing the boat in the same direction. And then move on to the next team, without having any responsibility for it. But the problem with that role is after you do that for a year, you don’t have a single commit, right?


You have no record of your existence.

That’s right. But maybe that problem needs to be solved then. Maybe there ought to be a credit system or some way of recording that this was influenced… I mean, Mark Bates does it in his projects. He has a shoulders.txt, and he’s basically listing the people that otherwise you would know, that have helped to make –

I didn’t know that. I love the idea of the shoulders.txt.

Yeah, standing on the shoulders of these giants.

Yeah, because then at least at review time you could see your name across – even if you put the number of hours that you provided, that would be… It’s a role that’s missing. I think you could get your teams up to speed within a couple of months, while being productive. You’re not losing a week to training.

Yeah, and it’s relevant. They’re learning in the context of the problems that they’re really solving, and that to me is always the most valuable of learning anyway.

On the projects that I’m in at Ardan my mornings are usually a couple hours of pair programming with whoever I’m working with, and then in the afternoon I set them off to go back and do usually more programming than engineering, and then we do the engineering in the morning.

Right. I see.

So “Go code this. Just make this work.”

That’s nice, because it gives people permission to just crack on and do something, which is what often – we need that permission to do anything, especially if you’re learning it and you feel like you don’t know how to structure this, or whatever. Like, stick everything in Main, get going; get something working, and then we’ll iterate on it. I really like that approach.

But here’s the cool part – and I might take questions during the day on little things, but here’s the cool part. The cool part is after usually about four weeks, they’re engineering while they’re doing the pro–

Yes, that’s right.

So there’s less and less refactoring. That’s what I’m looking for. If I’m four weeks in and I’m still doing the same level of refactoring I was, this ain’t working out. And usually, by week eight it’s almost like my life is really good now. “This is good, this is good, this is good. Go.” And that’s what I think this role should be. It’s an educational role in the company.

And then – okay, we didn’t document the handbook, but I’ve taught the handbook to everybody over a couple months. So the next person that comes on, now you do the same thing and your code is consistent.

It’s like an up-leveler. You’re being an up-leveler as a role.

But it is something that’s important and really valuable. But you’re right, if you can’t really measure the impact of it, what’s the incentive for people to be doing that? Maybe it’s not there.

Well, the bean counters who don’t see it, just look on spreadsheets and go “We’re paying this person X amount a year, and…”

Where’s the code…?

Yeah, they didn’t add anything to the bottom line. Let’s get rid of them.

Right. Yeah, well, that’s a mistake…

Yeah… So to me, that would be the role I would want after I’m done with Ardan. I think that would be so much fun.

Yeah, I think that would be fun as well. It sounds great.

And you have no responsibilities, so you go home and your phone’s never gonna ring.

Yeah. [laughs]

That’s the key.

Living the dream.

You’re living the dream, yeah.

Bill, thank you so much. It was so great to talk to you, and I’m excited for your talk. You’re actually gonna be speaking now, unexpectedly, at this conference, right?

[50:11] Yeah, it tends to happen most of the time when a speaker can’t make it to the conference.

Yeah. [unintelligible 00:50:15.14] unfortunately is not able to make it here… But you’ve stepped in. What are you gonna be talking about?

So I only have half an hour, which if you know me…

Not enough.

…I just get going in about 30 minutes.

Yeah. Just start 30 minutes before backstage.

Yeah, it’s gonna be bad… And I feel like when you’re on-stage, which - I really don’t like talking on-stage.

Yeah, that surprises me.

I think it’s a different experience. It’s more stressful… I’m not a good speaker on-stage; I’m good in the workshop, because I can be really fluid and flexible.

Do you rely on that interaction more then with people? Because often you don’t get so much of that when you’re delivering to an audience.

I think a good speaker talk is always really well prepared. The slide deck - it’s well prepared; you know your message, you practice it a hundred times.


That’s not me. I’m more like “What’s going on in the room? Let’s feed the room.”


And I only have 30 minutes here. So what I decided is to take a small bit of Ultimate Go that I’ve done and just show in a practical way how you can use benchmarking for profiling, in some compiler switches, to find non-productive allocations, and fix them, and do all live coding, and…

Ah, again very practical stuff that people will be able to use immediately.

Practical stuff. And because everybody here is so new - because I’ve been sheltered for the last 2,5 years - it’s probably gonna be a lot of new material. It’s new to them.


I mean, I’ve been doing this particular exercise for half a decade… So I always have to worry, like, how many people have seen this? And my guess is it’s gonna be very, very little. So at that point, it should be a good talk. And you can see my style; I can’t do slide decks.

Well, I can’t wait to see it. Thanks so much for talking to me today.

Alright… Thanks, Mat.

Thanks, Bill.

Well, that beautiful sound there was just created by Egon. How have you done that?

Well, I came here and did a TinyGo workshop, and I took some buttons and mapped them to a trumpet [unintelligible 00:53:44.26] then control it with Ableton

Yeah. So you had to assemble this yourself on the breadboard.

Yeah, exactly.

It’s got three switches. Can you explain what these components are here?

[54:00] Yeah, it’s an Arduino Nano RP-something… And then it’s got three buttons connected to it. And yeah, then there’s some magic to map the three buttons to some midi note.

Ah, so you’ve got Go code that’s running on there…

Yeah, exactly.

…and that is translating into the midi notes, which is then played out through Ableton

Yes, exactly.

So it’s not too many pieces you have to put together to make that work.

No, not really. It’s 90 lines of code, and I have different scales and stuff here already…

That is so cool! And how was your – this roundtable discussion yesterday; remind us what you talked about.

Oh, it was excellent. There was a static analysis discussion. We went through what linters everybody is using, and how do you build them, and what could be made easier to make linking easier to write. And of course, what’s the other thing to do? A debugger. Pun not intended… But why are debuggers so powerful, but nobody is using them properly?


So… Lots of interesting topics.

Well, yeah, the interesting thing – because I’ve written some linter tools myself, and it’s not easy, is it?

Yeah. But there are packages, like tools analysis, and the rule card, rules that do help you make it easier. But there’s probably – we could do something where we do like a structural pattern detection on bad examples and good examples, and then figure out how to convert it into a linter.

Oh, that’s interesting then. So almost like using good code as training data for…

Exactly, yeah. And if it’s wrong, then you just add an example to one or the other, and it will get better.

Oh, that’s kind of like GitHub Copilot, but without the machine learning and the SaaS.

I guess so, yeah. [laughter]

And we mean SaaS in both ways. GitHub Copilot is quite sassy sometimes… I asked GitHub Copilot, just in the comments, “Are you alive?” and it said “Yes.”

So… What else do you need?

Exactly. I’m sold… But thanks, Egon… Enjoy. Maybe you can play a bit more for us…

Sure. [56:32] Okay?


Oh, I can’t believe it. @deadprogram, Ron Evans, in real life, and in this timeline.

Here in Berlin, of course. I wouldn’t miss GopherCon EU. I mean, I don’t get out much…

Yeah. And what are you doing here?

Well, we have our TinyGo Hardware Hack Session today…


We brought all sorts of hardware from our secret lair, for people to check out lending library style And then using that, they can hack on hardware, fly drones, program gopherbots, program IoT controllers, and even our TinyGo music jam.

Oh, that I can’t wait for. I was talking to BuBu earlier He was making a drone fly around, before someone nearly squashed it.

Well, he’s actually been consuming the batteries for the drones at a very rapid pace, and… He’s definitely getting his drone pilot license after this, I’m telling you.

Yeah. [laughs] So let’s have a quick look at some of the stuff you’ve got here then. I mean, obviously, it’s a podcast, so people can’t see it. We’re gonna have to describe it… But there’s these cool pins, and stuff.

Oh, these are really awesome TinyGo pins made by ConejoNinja my awesome collaborator and colleague. He makes wonderful toys of all different kinds… So he 3D-printed these cool, little, tiny gophers, which - you’ve gotta take one, in your appropriate color…

Adorable… Yes…

We have these awesome pins, TinyGo stickers… But the thing he made that is the most amazing is these life-size gopherbot helmets.

I know… I can’t believe this.

[58:05] We’ve got those photos that we took a few minutes ago, that you’ll have to share… Because honestly, we look better in those helmets than we’ve ever looked.

I know… To be fair - yeah, I feel like it’s sort of like Daft Punk, but imagine Daft Punk was struck by lightning.

Daft Gopher.



Yeah. Yeah, they’re just so great. And then there’s lots of components and things for people to build…

Yes, we have fully assembled gopherbots for the people who want to explore the software side of hardware… And then we have all these IoT sensor kits, with individual sensors for people who actually want to touch metal. They want to plug in cables that control individual LEDs. We’ve got that for you as well.

Yeah. As I’m talking, the robot’s ears are flapping.

Yes, the ears move, they’re on servos… That was one of the things people asked about the original tiny gopherbots, is “Do they move?” I’m like, “No, they don’t move. It’s an emotional support robot.” You hold it close to you and you tell it what you need to tell it, and it just listens. It doesn’t respond. It’s just a perfect listener.

[laughs] Yeah, nice.

But you know, for conejoninja, he really had to go to the next level… He had to go larger, first of all; full life-size. If you want to become one of the gopherbots, then… You know, it’s got the cyberman style…

You could get away with wearing them around Berlin, I think.

I think – I saw someone wearing something very similar last night…


But he’s got these awesome TinyGo-controlled ears that have small servos… So eventually, we’ll hook up a brain-computer interface and then they’ll move based on your mood.

Amazing. So how does it work in code then? Is there an API for these particular things? Do you send messages? What’s the actual interface like for the programmer?

Well, it’s all just Go code. And we do have APIs… We have a low-level API called the Machine Package, which in TinyGo lets you actually control the different individual LEDs at the very low level…


And then we also have a drivers package, which has got somewhat higher-level, for things like displays, and sensors… If you wanna read the temperature of a particular known sensor, you don’t wanna have to figure out the low-level protocol details. You just wanna read the temperature and then do something with that information.

I see. But that’s cool that you still have the option of that really low-level stuff. That is very appealing, especially if you spend a lot of time in higher-level software. The fact that this also reaches out into the real world I think is really – it gets really exciting.

And we have another layer on top of that, with some packages… There’s a couple of packages specifically for displays, the TinyDraw and TinyFont packages. This is actually treating these LEDs on the helmet as if it was a kind of small display…

Yeah, it’s scrolling text, right?

…and it’s compatible with the same exact APIs as those little, tiny… These very, very small displays that are about the size of a postage stamp, and then you have these large displays and you could use the same types of software, and the same drivers, and the same TinyDraw and TinyFont package, regardless of the size of the display.

So how is the text scrolling then? Is that part of the driver tech, or is someone actually redrawing each time, and then coming up with the logic to toggle the LEDs individually, and stuff?

I don’t know. But the programmer himself, conejoninja is right next to me and knows all the answers to these wonderful things.

Well, that sounds like a great segue. Hey, how’s it going?

conejoninja: Fine, thank you.

Yeah, so how does the text scroll on this display? Do you have to calculate what it’s gonna be and then update things individually?

conejoninja: No, we just have these fantastic libraries, TinyFont and TinyDraw. With TinyFont, you just say “I want to print this text, in this position.” So we just move the X position…

Ah, I see. Okay, so you have some kind of loop that you manage then, with a sleep in there, I assume, for the delay. So you’re drawing it and offsetting it. That is very cool, because it looks very familiar. It just looks like a – we’re used to seeing this kind of scrolling text display, but you’re controlling that yourself, which is really cool. And how long did it take to build these helmets?

conejoninja: A couple of months… But I’ve been busy.

Yeah. Well, I can see you’ve been busy. Are you worried about them coming to life? Have you thought about that?

conejoninja: Yes.

Yeah, a little bit…

conejoninja: [unintelligible 01:02:44.10]

Yeah, that’s the plan, isn’t it? [laughs] Well, this is it. I look forward to these. Because this is gonna be like The Terminator, but they’re adorable… Yeah, so… In a way, be nice.

We’re all gopherbots now.

[laughs] Thank you very much. Great stuff. And if anyone’s interested, check this out online, because the TinyGo project is really great.


Okay, there you go.

Well, that’s a wrap from GopherCon EU, and… I’m a little bit exhausted, but it was such a good – I’ve met some amazing people, had some great conversations… I hosted with Ale, Natalie, Jessica and Vee. Co-hosting there was great fun. The Gophers Say podcast that we recorded live was great fun, and it went better than I had hoped… And yeah, the talks were so good, the conference, all the staff… Natalie and Donna and the team that put this together… I don’t know how they do it; it’s just so much work, and they’re just so much fun. So if you get the opportunity in the future to go to GopherCon EU, I really recommend it. And they do a diversity sponsorship/scholarship thing, too. So if you feel like there’s no chance of you getting there, reach out on Twitter to them, because they make it available to everybody.

Great. Okay. Well, that’s it from me, from Berlin, and from GopherCon EU. I had a great time. I’m off back to London now… [wanker!] You’re welcome!


Our transcripts are open source on GitHub. Improvements are welcome. đź’š

Player art
  0:00 / 0:00