Go gets audited, and Ian Lance Taylor talks about 19 years on the Go team

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Jonathan Hall (00:00):
This show is supported by you, our listener.

(00:01):
Stick around to live for thenews to hear some more about
that.
Cup and Go for 05/23/2025. Keepup to date with the important
happenings in the Go communityabout fifteen minutes per week.
I'm Jonathan Hall.

Shay Nehmad (00:22):
I'm Shay Nehmad.

Hello, Shay.

This is gonna be a difficult episode to record
because my body is rejectingCalifornia.

Oh, no.

I'm gonna try my best, but the allergies here
I've never been allergic toanything, but I don't know,
guess California, sequoia trees,I don't know what's going on.
But we're gonna try to pushthrough it.

In the meantime, we have a great episode coming
up for you today. We're talkingabout some great blog posts,
some issues that have beendeclined, and later after the
news we have an interview withIan Lance Taylor. You don't
wanna miss that one.

Yeah. Was we actually already recorded it, so
we can tell you it was it was apretty interesting conversation.

It was.

But I'm I'm gonna kick things off here with Trail
of Bits data audit on Golang'sstandard cryptographic library.
And I guess we should start withlike, why? Why would they do a
security audit for thecryptography library? What's
like, why would we even, investtime into doing that?

Are you asking me to speculate? Yeah. All right.
So I can imagine that we wouldwant to make sure that the
crypto is working correctly,that we're not leaking secrets,
have backdoor side channel typesof exploits because we're not
doing things correctly. That'spretty handwavy.
That's usually how my

security works, by the way. It's very handwavy.
Yeah. So you're not gonna passthe real reason they're doing
this, which is to pass the FIPScompliance. Oh, yes, of course.
I'm not gonna go super deep intoFIPS because we actually have an
episode about that. I don't likereferring people to past
episodes to learn about a topic,but honestly, the FIPS episode
we had with Alex Shield was soinformative about what FIPS is

(02:08):
and how it works and all that.

Alex Scheel (02:11):
Library which undergoes FIPS certification.
Before that, I was at Hashbrookworking on Malt. And before
that, I was at Red Hat where Iworked on a PKI solution called
DogTag PKI, which is.

But just in short, it is security requirements for
cryptographic modules by, like,NIST, by a standard. Right?
Which if your cryptographiclibraries work in that, work for
that like certification andfollow these requirements, you
know, it gives federalorganizations sort of

Ian Lance Taylor (02:47):
a stamp that

you have adequate security. Have you ever been on
the other side of like apenetration test or a security
audit of your code?

The other side meaning?

Other side meaning someone is doing penetration
testing on like a web serviceyou've developed or something
like that.

A couple of times.

So it's always a bit nerve wracking, right?
Because the what's the interestof the of the company who's
doing the penetration test or

the security They to prove how terrible my my code
is from a security standpoint.

And like the more severe findings they find, the
better, right, for them.

From their perspective, And

for your perspective, like because

then they get my bonus instead of me.

Yeah, basically, they get to have your lunch. The
bottom line of this report, forfour weeks they had three
security researchers likereviewing all the code, writing
Semgrep rules, etcetera,etcetera. And honestly, they
basically found nothing. Theyfound one low severity finding

(03:44):
and five like informationalones. The low severity is a
timing issue, which is alwaysfun to discuss, but isn't really
a problem to be honest.
And the bottom line is on theirTwitter, I really love that
quote, so I'm gonna just say thequote. Google Go libraries are a
model example of cryptographyimplemented the right way. The

(04:05):
code base was designed and builtwith security and testing as a
priority. I mean, come on. Sothe security audit is basically
a glowing recommendation thatthe Go, you know People always
say, leave cryptography tosomeone else, someone else did
it better.
You know, we had Filipa on theshow. So sounds like you know a
lot about Go and, cryptography.Who are you, Filippo? Why don't

(04:28):
you introduce yourself?

Filippo Alsorda (04:29):
Hi, everyone. So, I'm Filippo Alsorda. I've
been, maintaining the GoCryptography Standard Library
since 02/2018. I've done thatfirst at Google as the lead of
the Go security team, and thesedays, I'm doing it as a
independent open sourcemaintainer.

And when we had these people on the show, you
get a sense that, like, the thecrypto stuff is for real. Now
you have like external thirdparty confirmation from a
consulting company who's allthey wanted is to prove that
it's not good, that it is good.Which for me is it's like very,
you know, it's a lot of fun tojust know that, yeah, I can

(05:06):
offload worrying about crypto tosomeone else and not worry about
it too much. It's hard to figureout. Yep.
So the security audit was agood, got a good result. Good
for you if you use Go. Way to

go, Go.

Yeah, exactly.

Next up, we have a decline proposal. I wanna just
do a warm virtual hug to theproposal creator who probably
feels really rejected now thattheir proposal has been
rejected. Let's see, who was it?Oh, Russ Cox. The proposal here
was to add a package foriterators.
The proposal was XEXPXITER, anew package for experimental

(05:41):
iterators. This was proposedback when the new Range Rover
Func was proposed or when it wasadded. The idea was sort of, I
guess, a staging ground to trysome experimental iterators to
see what sticks, what's usefulto make it into the standard
library. Well, he actually lastweek sort of withdrew the
proposal. He said this was agood discussion, but I don't
think we have a consensus onreally adding any of these to

(06:03):
the standard library andencourage what in many cases is
over abstraction, although notalways.
More important, we're not goingto do X idr. If we're not going
to do X idr, we should stoptalking about it and create more
space for third party librariesthat we're sending in the way
of. Lick the cookie, but thecookie is now quite stale.
Better to toss it

and let other people bake some new ones. So
let's go bake some cookies. Butiterators are such like an
infrastructure thing. Would youimport a third library for your
iterator or would you justimplement it yourself? I would
just copy some code, like evenfrom this straight up out of
this proposal or something.

Sure. So I think it depends a lot on the specific
use case, right? So some of thetypes of iterators that were
proposed to go in this werethings like concatenating two
iterators together, reportingwhether two sequences are equal
using an iterator, which is kindof a strange thing, I guess.
Zipping iterators together. Soyou take you have two iterators,

(07:02):
you take value one from iteratorone, value one from iterator
two, value two from iteratorone, value two from iterator two
and so on.
Zip them together. So a bunch ofthings here. Some of these might
eventually make sense in thestandard library. Some of them
are fairly niche. Like, I don'tthink I've ever needed to zip
two iterators together.
If I need to, I could probablywrite that in just a few lines
of code. Like you said, copyingeven straight from the proposal.

So generally you're happy this is declined?

I suppose so, yeah. I guess I'm actually kind
of indifferent, but it seemslike this collection of
functions are the kinds ofthings I would rarely reach for.
So if I have to create themmyself, that's fine. Yeah, I'm
happy with that.

To me, all the iterator it it definitely feels
like the sort of things that ifyou need to use iterators
already, you already know allthe options and you've
definitely have something thatworks, already. And if you're
sort of a new coming to Go, youcan probably find what you're
looking for pretty easily. But Iappreciate the carefulness in

(08:00):
which the Go team introduces newfeatures more than I appreciate
having everything at the readyin the standard library. So so
generally good. Also feels niceto they have a proposal by Russ
rejected because he rejected myproposal, even though he
rejected his own proposal.
So I don't know.

Yeah. I'll bet Russ has more rejected proposals
than most people in the world.

Yeah, for sure.

If you remember, a while ago we mentioned a
conference on the show, as wedo, like if you have a cool
conference coming up or ameetup, let us know and we'll
definitely, like, it's good whengophers come together and talk
about Go, I think, for manyreasons. Like it advances the
language and people get jobs andnetwork and it's fun and free

(08:46):
pizzas, blah blah blah. But wedon't normally get follow ups on
that, but we We got a follow-up.And if you want to see, you
know, a talk from a conferencewe already mentioned, visit
gapnotes.org. I watched the talkby Gabriel Algandre.
I hope that's okay. It'sprobably not because on the blog

(09:08):
post, he was like, no, Jonathan,that's not how my name is
pronounced, but I don't blameyou. But, yeah, it it was in
Czech Republic. Very good talkabout like how linters work and
like what's the AST andspecifically about, you know,
the context wrap thing, whereyou don't wanna wrap the

(09:30):
context. If you want to add avalue to a context, you don't
wanna wrap it in a new contextbecause that can introduce
performance issues.
Mhmm. It's the sort of talk Ilike which has like demo code
and slides and like charts. Itwas very It's a very good talk,
So you should probably just gocheck it out on YouTube.

And

thanks for letting us know. It was like the
conference is happening, likewas happening. If you have a
conference or a meetup comingup, let us know. We'll
definitely shut it up. Well,definitely, maybe.
I don't want to make like anystrong promises, about what we
will and will not shut out, butwe'll try

our best.

Hey, Shai, do you remember Anton who came on the
show a while back?

Of course. The interactive code, the only way
to read the Go releases now,basically.

Yeah. I'm I'm looking forward to the
interactive 1.25 release notes.But until they are here, he has
a new, blog post about how doyou check if you're online? How
do you check if you're online?

Are you actually actually asking? Because I do
have an I go towtfismyip.com/jason.

Okay.

That's my go to. It just always works.

I usually ping. I usually ping Google.com just
because it's easy to remember.Right?

And it's probably up. Right?

It's probably up. However, it doesn't always work
because sometimes ping isfiltered. Right? Depending on if
you're behind a firewall,especially if I'm at an internet
cafe or something, I'm out of mylaptop at a hotel, maybe they
don't let things through. So hisblog post is about some
alternatives to ping Google orwhatever.
And he points out that severalservices, Google, CloudFare,

(11:06):
Ubuntu, they have URLs you canquery over HTTP that will tell
you if you're online or not. Andhe goes through some of the
details about some that return atwo zero four, which is the
equivalent of a 200, butspecifically says there's no
content here. There's no body.So it's in theory, a lighter

(11:26):
payload or some also return a200. So they probably include
some sort of minimum body thatsays something.
And then he talks about how toimplement these in this sort of
online checks in differentlanguages. He has Python,
JavaScript, Shell,

which is closest

to
what I

most

of
the time.

It

is a nice little Go snippet. It's about 10 lines
of code. So if you have aservice that needs to check, am
I online or not? This is onesimple way you

can do it. And my immediate thought when seeing
this was, a, it's a better checkthan think, right? Because it's
just for HTTP and if you useeven HTTPS for for some of them
that do work, you can check itfor like your HTTPS stack works
where you work locally.Unfortunately, the the main use
case I found when reading this,was like, oh, this is a really

(12:14):
good list. Check if I'm onlinein a malware, because I can use,
like I can random pick one ofthese or two of these every
time, and that way my behavioris not like, there isn't a very
simple heuristic of, oh, ifyou're, if you have something
running on your machine and itgoes to
cloudflare.com/generate204, it'sShy's malware.

(12:36):
Because you can use like, youknow, I've done lists a ton of
links here. So you can just likepick and choose, you know,
Apple, Debian, Gnome, Microsoft,Mozilla, Xiaomi, Ubuntu,
Cloudflare, and of course Googleto check for your connectivity,
therefore making your malwareless detectable. But now that I
said I don't know if it's thatbig of a secret anymore, so

(12:59):
maybe it's not useful. But itwas just funny to me that the
moment I saw this list, waslike, oh, this is gonna be super
useful for malware developers.This is a problem with
everything that's like useful,you know, someone puts out a
blog and like, here's the newobfuscation technique that's
really great.
And I'm like,

If you are a malware developer, we want you
on the show to talk about this.

Actually, would have someone anonymously
interview on the show if they'rea malware developer. Like, go
through a voice filter thing.Sure.

We could do that.

Yeah. For sure. We promise to protect your
anonymity and not share your IPwith with any law enforcement
agencies. We promise that. Idon't know if we legally can
promise that.
We don't promise anything, butcome on the show regardless.
Alright. And if while developingyour malware, you need to do
some resource pooling, I foundanother pretty good blog post.

(13:49):
This is you know, that type ofblog post which is technical,
but obviously was written by acompany. So, you know, it does
have value, but

Wait a minute. Does this have Em dashes in it?

You know what? You know what? That's a good
question. I don't think so, butit does have, like, bullet
points.

It has four Em dashes in it.

Filippo Alsorda (14:08):
What do you see?

I just searched for an em dash and I found oh
oh, two of the em dashes arepart of the page footer. So
there's two em dashes on thearticle.

Okay.

Pay only for usage space em dash space and
then zero optional overheadspace em dash space.

Anyway, I don't know what you think about these
blog posts. Normally, they suck,right? They're just like SEO
bait that just restates obviousthings from the Go
documentation, right, and thenslaps a company's logo on top.
This one from LeapCell is notone of these, so I wanted to
shout out LeapCell, I haven'tused their services, so, but the

(14:43):
blog post itself is pretty goodabout like, what is pooling and
like, how would you do like, Idon't know, SQL connection
pooling, which is a problem aton of people have to solve. And
mostly the like best practicesand how to handle exceptions
correctly.
And what I was mostly interestedin is anti patterns, like what

(15:05):
practices you need to avoid whenimplementing, you know, a
resource pool, which is like,you know, you leak connections
or you the pool size isincorrectly configured or, you
know, you're not handlingerrors. And finally, they have
like both a full resourcehandling pattern implementation

(15:26):
in the blog post. And one that Iwas wondering if you were using
connection prewarming. You'relike, when the service starts
up, you set up a bunch ofconnections ahead of time and
you ping the DB ahead of timeso, you know, they're ready. So
when a request comes in, youjust grab one other pool that's
already ready.
Do you ever do that?

I have done that before. I haven't recently.

Is it just cool or is it actually useful?

It's it's useful if your connection startup time
is is meaningful in yourapplication, And it can be
sometimes. So if you need reallyfast responses, you don't wanna
wait for the connection startup,you know, the TCP handshake and
all that stuff. It can save afew milliseconds.

So I guess profile first before implementing
everything in this article asgospel. But, you know, articles
that are mostly code and most ofthe code seems correct, I can't
argue with. So a pretty goodarticle. Next time you need to
implement resource pooling, justreach for this is like, I think,
useful for beginners or if youjust want to implement it
without thinking too much, it'sgood idea.

Well, I think that wraps up for the news
today. Stick around. Don't goanywhere after the break. We are
talking with Ian Lance Taylorabout the last nineteen years
ago. You will not want to missthis conversation.

All right.

I just said it was a blanket statement. I know
some people will want to miss itfor whatever reason, but you
don't want to miss it. It's ablanket statement. It's true.
You don't want to miss it.

All right. I really enjoyed our conversation, so you
should stick around. Cool.

See you there. Thank you for listening to our
amazing news segment that wehaven't recorded yet. We really
appreciate it. If this is yourfirst time listening to the
show, be sure to leave a ratingor review wherever you listen to
your podcast on, what is itcalled, iTunes or Apple Music or

(17:18):
Apple Podcasts? I don't knowwhat it's called these days.

It's Apple Podcasts.

Spotify or whatever. Apple Podcasts. Yeah.
Okay. Or Google Podcasts.
No, wait, that one's gone too. Iguess it's called YouTube
Podcast. I don't know what it'scalled. Anyway, we appreciate
it.

It's an RSS feed with m p three files. Don't let
all the apps fool you. It'sliterally an XML file behind the
That's all it is.

Also, tell your friends, your colleagues, your
coworkers, your fellow studentsabout the show because we don't
advertise. So your word-of-mouthis how the show grows and boy,
it's growing. I keep watchingthe statistics and it's fun to
watch that trend upward and tothe right. On that note, we also
have a new Patreon this week,Afari Daniel. Thank you so much
for supporting the show.

(17:59):
If you'd like to support theshow financially to help pay for
editing and hosting fees, headover to cupago.dev. There you
can find links to Patreon, toour merch store if you want to
buy a t shirt or a mug with ourlogo on it. You can find links
to email us. You can find socialmedia links for the show and
probably for us individually.Yeah.
Kind of everything about theshow lives there at cupicco.dev.

Yeah. So if you want to support the show
financially, that would begreat. Like Jonathan said, the
money goes to editing andhosting fees and definitely not
to us not optimizing our codeand just having it run on really
expensive machines in the cloudinstead. Definitely not to that.
Right?

Definitely not.

Sounds good.

And speaking of a couple of Go. Dev, we got some
feedback from one of yourcolleagues, Shai, about show
notes, and you wanted to ask ouraudience what's important in our
show notes. Why don't you take

that Like, when you open the whatever app, let's say
Spotify, it doesn't show you thewhole show notes, it doesn't
respect line breaks, and itdoesn't render links as links.
Our line break link summary ofthe show is very useful if you
click into an episode, but itdoesn't actually tell you what

(19:09):
the episode's like about. And Idon't know if most people
listening are listening like ona weekly basis, just waiting for
the episode and then listeningto it sometimes during the week.
Or if you, you know, pick andchoose episodes every now and
then. So we want your feedbackin the Slack channel, we'll also
send it as a question, like as athread.

(19:30):
What would you like to see inthe episode summaries? As long
as it's not too labor intensive,I we talked about maybe we could
summarize in one paragraph whatthe episode was about, etcetera,
etcetera, before putting all thelink. I definitely wanna keep
all the links in, but maybethat's also bad. Like, just let
us know what would you like tosee in the episode, like,
summary, which is the text inthe, like, Spotify or whatever

(19:53):
app that that accompanies everyepisode.

And then finally, next week our show is going be
different. We're going to berecording a live episode. We
won't be streaming it, but we'llbe recording it live at Shai's
meetup in San Francisco andit'll probably be released a
little bit earlier. So if you'rein the Bay Area, be sure to be
there so you can be part of therecording. If you're not in the
Bay Area, stick around tillWednesday or Thursday to listen

(20:16):
to what happened.

Yeah, and I was promoting it pretty heavily on
the show being like, pleasecome, I'm afraid there aren't
gonna be enough people. And nowI'm like, please come. I'm
afraid there are gonna be toomany people. I don't know. And
if you listen to the show, Imight have a because we have
like, I don't know, 50attendees.
Wow. Which is That's impressive.Right? It's a good event.

(20:38):
Sponsored by Elasticsearch, bythe way.
Thank you, Elastic. And it'sgonna have a talk by a friend of
the show, Josh Bleecker Snyderand Ishai Shaw. And also we'll
we'll record an episode. So it'snot just like a cup of go
meetup. It's a proper go meetup.
So yeah, that's gonna be a lotof fun. Link in the show.

I think that's it for the the break here. Stick
around. We'll be talking withIan Lance Taylor about about go,
I guess. That's kind of theYeah. Makes sense.
Yeah. Don't miss that.

Hey, Jonathan.

Hey, Shay.

You know what's been driving me nuts recently?

I do not.

Golang.

Oh.

I hope someone on the Golang Nuts mailing list,
number one active person couldhelp me figure out what's going
on with this language. Oh, hey,Ian. Hey.

How's it going?

Good. Thanks for taking the time to talk to us,
Ian.

Yeah. Thanks for having me.

Wonderful.

For our listeners who might not know you, do you
mind, like, presenting yourself?People, we we have Ian Lance
Taylor on the show. It's prettycool. I'm Starstruck. But, you
know, some people might notperuse the issues tracker often.
So how about you tell peopleabout yourself?

Yeah. Sure. I've been on the Go team since,
twenty o eight, actually, beforethe first public release. I
mean, we all know, Go wasstarted by Rob Cannon Robert in,
twenty o seven as an internal,project at Google. I heard out
heard about it maybe eight, ninemonths later and, got the good
fortune to join the team.
And I've been, working on it,really ever since. I recently

(22:15):
left Google, but and I'm takingsome time off, I hope to
continue working on Go. It's afun language and a fun project.

Awesome. So the Go team has a lot of work.
Developing a programminglanguage. This you know, that's
basically one of the topprogramming languages in the
world and so fast, you know, incomparison. Just involves a huge
mountain of work from testing todocumentation to compilers to,

(22:43):
performance work, network, likethere's a lot of different
aspects of the Go language.
Your focus, you know, over timeobviously changed and you did a
ton of things, but what wouldyou say was your, like, focus or
or or specialty in in inside theGo language? Because I know, for
example, you know, if we thinkabout, Filippo, which we had on

(23:05):
the show, he's like the, in myhead, the person who does
cryptography for Go. Right?Right. So what would you say is
your, like what were your nichesor your, like, specific focus
area?

Well, that's a great question because, my niche
was to not really have a niche,think. I have worked on

a lot of different aspects of it. I've worked on
the compiler. I've done a lot ofwork

in the library. I I worked on our
second compiler, whichunfortunately is a bit out of
date now, the GCC front end andGoel l l v and LLVM front end,
which we call Goel l v m. Theyhaven't they are unfortunately,
fallen behind. I've worked on alot of the tooling around Go.
I've worked on internal, Googlesupport for Go.

(23:48):
I've done a lot of work, morerecently. I've been trying to do
a lot more work on the, opensource side, helping,
contributors get their patchesin. I mean, ex contributors
outside of Google, I should say.Mhmm. And, participating in the
proposal review committee wherewe look at people's proposed
changes to the language andlibrary.
Also, have a language changecommittee where we look at

(24:10):
people's proposed changes to thelanguage itself. Almost all of
those get declined, but we lookat each one seriously and,
consider what it offers. So,yeah, my niche I'd say, you
know, when I joined the team,was doing a lot of work on this
other compiler, the GCC frontend, but also, you know, I just
kinda try to understand, whatproblems we were gonna run into

(24:33):
and, what, you know, what issueswe needed to, tackle, what was
gonna be coming down the line. Itried to get out of those
things, Tried to work on whereother people were not working.
So, you know, at one time I didwork on the runtime, but now
there's a great runtime team atGoogle.
I've barely touched the runtimein several years. So I've been
moving around.

Very cool. You've touched on some some highly
technical stuff like I imaginebuilding GCC Go was, you know,
you had to really get in thenuts and bolts of things and
more soft seal stuff likehelping new contributors get
involved. I can imagine a lot ofprojects or a lot of people at
least would would sort of maybenaively think, oh, we don't want
to waste a technical person'sexpertise and have them helping

(25:14):
newcomers. Let's hire an internto do that sort of stuff. But as
a technical person myself, I cansee how that probably wouldn't
work very well because there'sso much technicality involved in
helping newcomers come along.
How would you say yourtechnical, your deep technical
understanding of Go helps youwork with people trying to
contribute patches or proposalsto the language?

It's a good question. I think that, I mean,
comparing what I've done withwhat I've seen other other
people do, think, that thetechnical help comes in just
being able to more quickly workwith people. I mean, someone
will send in a patch and I youknow, a lot of patches are
great. Some patches are not sogreat. And I think that
knowledge of the library and thelanguage, me look at these not

(25:55):
so great patches and just veryquickly say, this is not
something we're interested in.
Or I can say, like, this isreally exciting and I know who
the best person on the team isto take a look at it and I'll
route it over to them. And, letme let me flip it around too.
I've been in the I mean, when Istarted as a programmer, it was
when free software started tocome about. This was back in the

(26:17):
late eighties. And so I've beena free software programmer for
most of my career.
Now people call it an opensource programmer and so I'm
sort of familiar with how theopen source ecosystem and
community works. Of course, it'schanged enormously over time and
really gotten a lot better thanit used to be. But still, you
mentioned like hiring an internand it's always tempting to say

(26:38):
like, okay, we should hiresomeone to do like a first pass
over, issues or, contributions.But if you bring in someone
who's not familiar with the opensource community, we have found
that there's a struggle a lot ofpeople have to sort of fit into
the flow of things, the give andtake, the fact that it's all

(27:01):
online where, it's very easy tocome off as much harsher than
you really intend. And so ifyou're not like, if you're not
familiar with that, it can behard to sort of, be effective, I
So

you said, you know, people it's hard to be effective
in these, like, onlinecommunications for issues, open
source stuff like that. It'shard. Do you feel like it's
gotten worse recently, becauseof like AI LLM generation? I
feel like a lot of open sourcestuff I'm seeing looks on the
surface like it was written withmore thought because it has like

(27:39):
paragraphs and em dashes andtitles. But when you look into
the details, might have likeactual hallucinations or just
things that are wrong, both inpull requests, like actual code
and in proposals and issues,just like, you know, discussion.
Have you seen that uptickrecently?

On issues, I mean, yeah. Well, I mean, yes.
I'm seeing what you're saying,what you're what you're what
you're talking about. On issues,it's not a big deal, I think,
because, yeah, there's more textyou gotta get through. That's
the worst part of it.
People are writing longerthings. But on the other hand,
in the past, people sometimeswrote too little. But you still
can, dig into the core of theproposal or the issue. I don't

(28:21):
think it's had a very, verylarge effect there. But on, pull
requests, yeah, absolutely.
There's more pull requestscoming in where people are like
and sometimes they don't evensay what they're doing. But
sometimes they at least willsay, you know, yeah, we ran this
code complete on this thing andit suggested this change and you
look at the change and you know,it's it's just churn or it's
nonsense and so you do have toit has it does take time. You do

(28:45):
have to come in and just say,know, like, no, this is is not
gonna help us and, let's justmove on. I wanna mention code
churn is a particular issue thatis, you know, both with LLMs and
without LLMs. People often lookat a piece of code, you know,
which has been in the standardlibrary at this point for like,
you know, ten, fifteen years andthey'll say, oh, I could write
this a little bit better.
And, you know, it's sometimesit's a little bit better. Often

(29:09):
it's a little bit better. Butthe fact is, with code that's
that old, you know it's workingbecause no one's reported any
bugs on it. So the only thing achange can do is make it worse,
make it break. And so unlessthere's some real clear
performance advantage or somereally dramatic readability
advantage, then those changesare are just churn and not

(29:32):
desirable.
Well, there are

there are two effects, you know. It it might
break something that alreadyworks. It might like create more
work for the languagemaintainers, but you're
forgetting the really importantpart. It's gonna help the
person, you know, bolster theirCV. Isn't that what language
maintenance really is all about?

Yeah, yeah, maybe so. Maybe so.

Well, on that point, let's suppose somebody is
trying to bolster their CV orjust make the language better
for some legitimate reason. It'snot just churn. Can you offer
any advice or tips for peoplewho are trying to contribute to
Go? How do they get started? Imean, there's the guide you
read, gives you the technicalsteps involved, but like from a
cultural standpoint, how do youget an issue looked at?

(30:20):
Because there's so manythousands of them out there and
there's not time to reallytriage every single one
thoroughly. How do you get aportal quest looked at? What
advice can you offer? What wouldmake your life easier when
you're looking at one of thosethings if I were trying to get
your attention on that?

If you were trying to get my attention on
fixing an issue or if you were

not specifically, but the the Go team. I have an I
have an issue I want looked at.What do I do to make it easy for
you so that it's it doesn't getlost in the weeds?

Well, for for a bug report, you know, try to
follow the template as much asyou can. Even though it seems
like like it's just boilerplatenonsense. A lot of people just
get rid of the template, fill inwhat they think is important.
And then, you know, the firstresponses that we have to make
are, you know, we need to knowthis, we need to know that.
Mhmm.
And the template's there for areason. And and yeah, it's it's

(31:07):
a lot of information there thatis almost certainly unimportant
for your particular bug report.But, you know, we're we're
asking for that informationbecause we've discovered over
time that we need it. And maybewe don't need it for you, but we
need it for the next person. Andwe don't know which particular
piece of information we needfrom you.
Then of course, the next,besides filling out the
template, you know, tell usexactly what you did and tell us

(31:28):
exactly what happened and tellus what you expected to happen
instead. Those are the threeissues that every bug report,
every good bug report should do.Mhmm. And, it sounds so obvious
when you put it like that. Andyet many people don't do it.
For many people, especially theproblem is, you know, they've
been looking at this bug,they've been pounding their head
over it and they're like,they're finally said, this is a

(31:50):
bug in Go. It's not a bug in mycode. And so I'm gonna report
it. But they know so much aboutit that they just put in what's
on top of mind when they, fillout the report. So, you know,
just go back to the basics, youknow, or or it's like the rubber
ducky bug report.
Like, the bug to your rubberducky so that your rubber ducky
understands it. And that's whatwe need. Even though we're, you

(32:10):
know, supposedly the experts, westill don't know what you're
thinking and we don't know thethought processes that you've
already gone through. And sohelp us help you by, explaining,
you know, explaining like to arubber ducky or explain like I'm
five.

Good advice. I'm curious. You probably don't have
statistics on this, but maybeyou do. What percentage of bug
reports are invalid? You know,they they weren't a bug and go.
They were never reproducible,things like that.

Yeah. I don't have statistics on that. I would
guess just off the top of myhead, I'd say maybe twenty five
percent are, invalid. Most bugreports, you know, even though
I'm complaining about them rightnow, most bug reports are
actually pretty good.

That's impressive. Yeah.

I would have expected the majority to be to
be invalid in some way. That'scool. I've had a few cases
where, not with Go, but with,like other software, you know, I
would start writing a supportticket or reproduction and then
suddenly I would realize likewhat I was doing wrong as I was
typing it.

Of course. Yeah.

Yes. Absolute that's it. I mean, that's that
happens a lot for me too.Absolutely. You know, you're
finally like, this is a bug, andthen you start writing down,
going back to the basics, right,and everything you did, and it's
like, a second.
Actually

Wait. Didn't I change directory? Oh. Oh, right.
But usually you end up witheither, like, it's really just a
boneheaded move on your part andthen you're like, oops.
But many times it turns like abug into like a feature request.
Like, hey, if I'm running thestreet from the wrong directory,
can you please like tell me so Irealize what I'm doing wrong?
Stuff like that.

Yeah. And I personally find those bug
reports very helpful whensomeone says, you know, I was
following down this path, thiswell lit path and, you know,
suddenly I fell into quicksand.And there's especially if you
can recommend like, if you hadsaid in the documentation here,
you know, that this was gonnahappen, that would help if you
had just had some message here.You know, not all of those are

(33:57):
helpful. Sometimes it's toomuch.
Sometimes it's like you shouldhave looked at this other
documentation. But you know,especially if you can say like,
if you had just added like onesentence right here, I would
have been better off, thenthat's a great bug report or
just send in a patch, you know,add that sentence. That was
really helpful. It's helpful forit's helpful for us. It's
helpful for the next personfollowing that path.
I'm curious, looking back overthe

last nineteen years, is there anything, that
really stand out to you as afavorite project or problem you
solved? Anything yeah. Anythingthat just stands out to you that
that's, worth mentioning?

Wow. It's a great question. Well, I mean,
it's I think I have to saygenerics

for

that because I spent a disturbing amount of
that nineteen years working ondifferent proposals for
generics. You know, some of themwere published but I had several
early proposals that were so badthat they didn't make the light
of day but I still put a lot oftime into them. So generics, as
I'm sure most people here know,did finally make it into Go in
the 01/18 release. But, youknow, we started I started

(34:59):
especially working on it Rightabout the time that we did our
first public release of Go intwenty o nine and, you know, off
and on, you know, especiallywith Robert Grisamer who did a
ton of work

Mhmm.

On it. Took us a while to really get to
something that was, good enough.

How how do you feel about the results? I think
in general, generics have beenwell embraced, but there's
always always somebody complainsabout this or that, you know,
ergonomics aren't quite whatthey want or maybe it's not as
flexible or whatever. How do youfeel about the result, with with
Ghost Generics?

Yeah. Thanks for the question. I feel good
about it, honestly. I thinkthere's still a little bit of
polishing and sanding that,could be done in the language. A
little bit of type inferencecould be better and certain
aspects of it aren't quitearen't not not that they're
wrong but that they could beimproved.
But these are really detailsthat don't notice until you

(35:48):
really get into the weeds of it.So I don't think it's completely
done, but I'm really quite happywith It's not as it's obviously
not as powerful as C plus plustemplates and, honestly that's a
good thing for me. I think itreally, it really does the job
and, it doesn't get in your way.So I'm really happy with where

(36:10):
it wound up and you know, it'sby no means is it just me who
did that. I mean, as I say,Robert Griesemer did a ton of
work on it.
He had a lot of the key ideas ofhis and Russ Cox also and
obviously the implementation Ibarely touched personally. So,
Keith Randall and Hans Gales, alot of other people working on
that. So it's been a it's beena, you know, a whole team

(36:30):
effort. Mhmm.

You think that the language evolution part of it,
of generics and other things,you know, that got into the
language in a while. I what I'mtrying to understand is how do
you decide when a languagefeature is go ish enough? You
like mentioned the C plus plustemplates and every fiber of my
being was like, oh no, pleasenot because I used to work on

(36:51):
those like with the 12. It wasjust horrible, it was so hard,
at least for me, I don't know,maybe smarter people than me can
figure it out, but it's justsuper complicated. It is, you're
right,

it is super complicated.

What's the cutoff point for a feature to be go ish
enough, you know, like simple,not introduce too many keywords,
not be complex enough, but it isthe language does evolve. It
does introduce new features.

Yeah. It's a great question, and there's no
simple answer. When, Rob and,Ken and Robert started the
project, they had a prettysimple approach, which was they
didn't add anything to thelanguage unless they all three
of them agreed that it should beadded. And so that, consensus
driven approach has been a bigpart of how Go has evolved over
time. You know, we're not gonnawe're not gonna add something to

(37:36):
the language if there are ifcore people on the team are
strongly opposed to it.
So that's just a generalguideline. And then more
specifically, yeah, how do weknow if it's simple enough? I
mean, I think that simple is aguiding feature here. Simple for
the reader, especially. We wantthe person reading the language
to know what's gonna happen.

(37:57):
We want Go to be I'm not surewhat the right word is. We want
it to sort of feel familiar toprogrammers. We don't want, you
know, we don't I mean,obviously, it's, you know, it's
it's a programming language. Youknow, the average person who is
not a programmer looking at Gois not gonna have any idea
what's going on. But we wantsomeone who is familiar with
other languages to not find itsurprising.

(38:18):
I guess that's maybe so there'sso be simple. Don't be
surprising. We don't wanna catchpeople by surprise. I know
there's aspects of the languagewhere we're not successful in
that and that's unfortunate.

So this is what makes a feature like Go ish
enough. Want it to be familiarto programmers, you want it

to be simple, and all

the core team members have to agree on it,
which I think are really goodbenchmarks because they're on
the one hand, they're softenough that, like, you know, you
could bend the rules around thespecific feature if it all,
like, makes sense. It soundslike if it introduces three
keywords in one pull request,like, we're not introducing it.
But it does seem to make a lotof sense.

Yeah. And let me mention, obviously backward
compatibility is essential too.I mean, Rob, really pushed this
in the early days. He said, youknow, we're gonna be really
strict on backward compatibilityand we've, we've really taken
that on, such that, in the wholetime since the, Go one point o
release, we've made only onechange that was not backward
compatible and that was a loopclosure change and we put we put

(39:17):
years of effort

Mhmm.

Into making that work. David Chase and, Russ
Cox in particular, but a lot ofother people too to make sure it
was the right thing to do and,do it in a way that was, safe
and, so worked for the wholeecosystem.

Yeah. When when I started with Go and someone
asked me for, like, can youexplain what backward
compatibility is? I only had oneexample, which was the Win 32
API. And in the years sincethen, now I have two. Like, I've
worked enough years and you knowwhat I mean?
Yeah. Thanks. But but it's Idon't know. It's it's super diff
it's such a disciplinedrequirement. Like, I wouldn't be

(39:52):
able to hold up an API Mhmm.
To that standard, I think.

So that reminds me of a question. This is a
question we asked, I

think in the first year of all of our interviewees,
but I wanna ask you because, I

think you have a unique perspective having been
at Google for so long, workingon Go. Aside from the loop
closure thing that was, I wouldsay, we could agree was a
mistake in the originaliteration, are there any
mistakes that you would say havemade it into Go? Something you
wish you could go back nineteenyears and remove of any sort,
whether it's something in the

standard library, a language feature, anything?

Yeah. I'll give you two. Okay. I think that
a lot of people get confusedthat when you store a nil
pointer into an interface value,the interface value is not nil.

Mhmm. Mhmm.

The interface value is instead a non nil
interface that holds a nilpointer. And I have no problem
with that, but, I mean, I thinkthat's correct for the language.
I think that's how interfacesshould work. But the fact that
we used nil for both the zerovalue of a pointer and the zero
value of an interface, I thinkI've it feels to me like that's
kind of what's led to thisongoing confusion. If for

(41:00):
example, we had had newinterfaces and null pointers,
then, you know, yeah, we'd havehad an extra word.
I don't know if that's the rightanswer. I don't I mean, I don't
know what the I don't know ifthere is an answer. At this at
this point in language, there'sprobably no answer, but I wish
that we had found you know, Ithink for us, it was always so
obvious. Yeah. Of course.
The interface can hold anyvalue. It can hold any pointer.
It can hold a nil pointer. Andthat's you know, we didn't find

(41:23):
that confusing, but it's clearthat many people do many people
new to the language find itconfusing. I wish we had found a
different way forward for thateven if I don't know what that
way is.

I love that answer.

And the second thing I will complain about is I
don't I mean, it's justpersonal. I don't like naked
returns. I think named resultparameters make a lot of sense,
but the fact that you can justsay return without listing the
values you're returning, I thinkit's just a little confusing.
It's fine in an incredibly shortfunction, but

Yeah. Jonathan is smiling because he made a video,
I think the top 10 worst thingabout Go, and I think it was
like, it was definitely upthere.

That's how I choose my friends. People who
make Naked Returns, they're inmy friend list.

And, you know, recently on a programming Slack,
I don't think it was the Go one.It definitely wasn't the Go one,
it was like some other one. Doesanybody know of a feature of a
language where I can just returnmy things without naming them at
the end because I wanna keep mythings more concise? And I
answer like, Go's naked returns,but universally people don't
really like them. Maybe don'tsave on on a keystrokes.

Yeah. Well, let let's flip that around. Is there
anything you think is importantto add? I know you've you've
written proposals. I I read oneof your more recent ones about
error handling with a questionmark.
In your opinion, as of now inMay of twenty twenty five,
what's the biggest missingfeature in Go that that if you
could snap your finger away,wave at one and make it appear,
what would it be?

Yeah. Great question. I mean, as you say,
have I have been spending timework on error handling, but none
of those none of those proposalshave flown. And and it may be, I
think that we're gonna we'rejust gonna say we're gonna live
with it even though it is one ofthe top concerns about Go in our

(43:09):
surveys. When I say top concern,it's still only about 13% of
people expressing it as a majorit's their top concern.
So there's just something abouterror handling in general that I
think could be addressed in someway even if we haven't figured
out what the right way is. It'snot just the it's not just the

(43:29):
syntax, which as we all know isa little bit, boilerplate y.

Mhmm.

I I mean, I've got no problem with, the sides
of it. It's just the fact thatit's the same thing over and
over again that I wish we coulddo better on. But then there's
also the issue of, it's a littletoo easy to forget to check for
an error. Mhmm. And, you know,you feel you fail to check for
an error, you just carry on andthen something goes wrong later
on and it's hard to understandwhat happened.

(43:55):
We don't have good tooling tosay, oh, you forgot to check for
the error here. We don't havegood mechanisms for that. And
then, of course, there's theperennial conflict between, oh,
I want stack traces for all myerrors and I want simple errors.
We use errors for multiplepurposes. We use them both to
report to the user what wentwrong and we use them to report
to the programmer what wentwrong.
We want different kinds ofinformation for both of those

(44:17):
cases. There have been severalgood ideas, like Austin had a
good one, a while back. Again,you know, we haven't quite
figured out, I think, what thewhat the best thing is. So I'm
just gonna say, I mean, just thebig ball of wax, error handling.
I don't have an answer.

Mhmm. Okay.

Although there is an error Maybe that we'll
never have an answer. We're justgonna we're just gonna go
forward with this, but that'sthat's what I'd say.

Well, although there is AirCheck, like, is that
linter program thing that Idon't know. Jonathan and I are
think pretty unanimous on this,that the one of the first things
we'll do on every Go projectthat we work on is, add Golang
cilin with some default lintersthat do a pretty good job and
error check is definitely one ofthem. Like, don't remember a
case where I forgot to handle anerror just because my that

(45:04):
linter always did it. Thatdoesn't solve for the like extra
information and stack trace andmake sure you're raise returning
the right errors, etceteraetcetera. But it does solve for
not forgetting to check ones.
Right?

There are some corner cases where it misses it.
I'll I'll say.

Yeah. That's great. And maybe we can figure
out the right way to incorporatethat into the ordinary Go flow.

Mhmm.

Make it part of Govat or something like that.

Yeah. So Ian, you've been with Go and Google
for nineteen years. Lookingback, what are your general
thoughts?

Yeah. Go has been an awesome project to work
on. I'm so I'm so pleased that,the original Go team members,
you know, welcomed me onto theteam, and gave me the
opportunity to work on this. Andit's been great. I mean, as I
think I've said in, in the past,I don't think any of us at the
time expected it to be thissuccessful.

(45:56):
I mean, sure didn't. I think ourdream, my dream, our dream was,
we have some good ideas here andother languages will pick them
up.

Oh, yeah.

And, they'll, you know, just this very simple
concurrency, you know, thesimple syntax if you know, we
just figured, you know, let'sget this out there. Let's let
people try it. Let's let thempick those ideas and add them to
other languages. And in fact,you know, some Go ideas have
been added to other languages,in, in the time that Go's been
out there. But the fact that Goitself became so successful,

(46:28):
that was just amazing.
I remember the first time I wentto, GopherCon, the first
GopherCon in Denver. And I mean,it was much smaller than it is
now but it was just amazing.There were hundreds of people
there who were happy Go users.They were so happy to use Go
that they're willing to come toa convention to talk about using

(46:50):
Go. And that was just anincredible experience.
And, yeah. So I'm reallygrateful and, happy that I've,
been able to work on this and, Iplan to continue working on it.

Great. I do have a follow-up question based on
that. It's pretty hard for, Ithink, any of us on this call to
answer objectively because weall use Go and you in
particular. But do you thinkit's a good thing from like an
ecosystem standpoint that Go wasadopted as is more or less
rather than people taking thoseideas as you had originally
intended or originally expected,would the programming ecosystem

(47:25):
at large be better if they hadjust taken good ideas from Go or
is it better because theyadopted Go as a primary
language?

Well, I'm obviously incredibly biased I
think I, you know, I think thatGo is a good language. We've
talked about some corner caseswhere it's not great. But, yeah,
overall, Go I think Go is a verygood language. I think it's the
best language that we knew howto make it. And, you know, I

(47:54):
don't wanna say we, I was apretty small part of that we,
just to be clear.
But, yeah. So I think it's eventhough I didn't expect Go to be
so successful, I think it's agood thing Mhmm. That it's so
successful. But I say that whileacknowledging my enormous bias.

Sure. Of course.

I think if they wouldn't have been that deeply
adopted, it would have been hardto invest so much time into
developing the more nuancedideas. Like, you know, you
talked about the hard skills andthe soft skills before. Right?
Just the way that Go manages itsopen source thing, and I
remember that moment, I think itwas two years ago with the opt
in versus the opt out telemetry.That was like, every programming

(48:32):
language in the future that'sgonna be like, oh, we wanna add
telemetry.
They can just look at Go and andlearn from that. And if the
language wasn't that welladopted, and widely adopted, I
should say, that wouldn't haveeven been an issue. Like, people
add telemetry to Go and it's,you know, some niche of
programmers, programminglanguage experts language, and
not just a programming language,people wouldn't even care. So,

(48:57):
you know, these contributions Ithink are way more valuable to
the programming community atlarge, other than all the great
software which was alreadywritten in Go and even the bad
software which is written in Go.

Yeah. Thanks. And in that same vein, I would
say, you know, Go's module proxyand Go's support for software
build materials. I think thosethings, I think, you know, Go's
package management in general. Alot of these ideas were
originated by Russ Cox, by theway, who's just has brilliant
insight into these, into theseecosystem issues and always has.
And, I like to think that Go isshowing a good path through

(49:31):
these complex, through thesecomplex topics. And I, you know,
maybe not perfect, but I hopethat other people will, will see
where see the good ideas that Gois using, Go has, providing and
adopting them like withtelemetry, as you said. And I
think telemetry was aninteresting example where, you
know, we originally were saying,let's do, opt out, but, then it

(49:52):
became very clear from thecommunity feedback that opt in
was the way to go. And, I thinktelemetry has been quite
successful, with, identifying,you it only helps with a certain
class of problems, but it's beenvery great on that certain class
of problems.

One, rapid fire question from me before we do
the usual stumper question. Goone dot x forever or go to
someday?

Go one dot x forever. If you look at other
successful languages, I mean,some do a major version upgrade,
many of them don't. I mean,there's no c plus plus two point
o. There's no Java two point o.And, I don't see any reason for
a Go two point o.
We are doing, as you know, we'redoing v twos on the libraries. I
mean, we've done one v two onthe libraries and we'll do more,

(50:33):
but, we don't need to I thinkwe're stuck with our bad
decisions forever.

And the good ones.

And the good ones. Alright.

Don't you want to change print? It'd be like print
with a space instead of aparens? Isn't that worth a major
a major language upgrade? Sorry.Sorry, Python.
Sorry. I didn't mean

to. Alright. Yeah. Let's let's wrap it up
here. So I'm I'm really curiousto hear your answer to this one,
Ian, because I think you couldyou could be the answer to this
question for many people whocome on the show.
The question is, who has beenmost influential to you in your
Go journey?

Yeah. It's hard to pick just one person.
That's okay. But if I did pickone person, it would be Rob
Pike. Mhmm.
He's, he's really, he was,really drove the Go project,
especially in the early years.He's not so involved these days
and, has just remarkable insightinto, based just, you know, the
problem of programming and,never really wanted to settle

(51:32):
for anything that wasn'tperfect. I've learned a lot from
him. I don't think I've everlearned how to think the way he
does, but I've always beenimpressed by him. And then I'll
also say, know, just, I mean,you know, the other people from
the start, Ken Thompson, RobertGriesemer, Russ Cox, I've
learned a lot from all of themin different ways and I hope

(51:52):
it's made me a betterprogrammer.

Great answer. Appreciate it. If people are
interested in getting in touchwith you, is you have a social
media presence or you like tolive under a rock and don't
wanna share that information?

I I basically don't have a social media
presence.

Okay.

I mean, you can always email me. I'm happy
to email you. Ent@golang.org ismy, is my go oriented email
address and, yeah, no, I've gotnothing against social media.
Just don't

You have a life probably more than I do. So

I don't know

about that. That's fair. All right. Well,
hey Ian, I wanna say once again,my my deep thanks for everything
you've done to help make Go thelanguage that I enjoy working
with every day. And thanks fortaking the time to come talk to
us about it here on the show.

Well, thanks for having me. It was fun. And,
yeah, it's a it's a it's a funpodcast and I, hope you guys
can, carry on. Great. Thanks somuch.

Well, Ian is off the call. I just, have to say
I'm really excited that we hadsomeone who contributed so much
to go on the show. I wonder howlong it'll take and how
persistent we'll have to be tojust cover like all the, you
know, all the lines of Go thathave been contributed with
people on the show. We can get a% Go coverage, But we definitely

(53:12):
bumped up our, CapoGo

It's a vanity metric, man.

But yeah, man, that was such a such an influential
character. And, you know, somany people have said it already
online, but just a a really bigcontribution to a language we
all, are interested in, to saythe least. That does it for,
this week's episode. Next week'sepisode is gonna be slightly all
over the place, like we said,because we're gonna record it
live. But for now, programexited.

Program exited. Goodbye.

All Episodes

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Go gets audited, and Ian Lance Taylor talks about 19 years on the Go team

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}Stuff You Should Know

Dateline NBC

On Purpose with Jay Shetty

All Episodes

Go gets audited, and Ian Lance Taylor talks about 19 years on the Go team

Stuff You Should Know