Don't skip the gym! 🏋️ And interview Alice Merrick, UX researcher on the Go team

Jonathan Hall:

Show is sponsored by you. Stick around till later to learn more about that. This is Cup of Go for Friday, July 26th, 2024. Stay up to date with the happenings in the Go community in about 15 minutes per week. A little bit longer this time because we actually have to interview again.

Jonathan Hall:

Woo hoo. I'm Jonathan Hall.

Shay Nehmad:

And I'm Shay Nehmad. Everybody's been talking about the interactive release notes. We just have to get into it. We just have to get into it and start clicking on them. Right?

Jonathan Hall:

Pull out your interactive podcast player and interact along with us.

Shay Nehmad:

No. So so we're gonna try to make it, an interactive media experience somehow and and sort of communicate it what's the experience of of using this, blog post. Right? Mhmm. But even on the channel, Chris was like, this would be such a loss if this guy ever stops writing these for Go releases one day.

Shay Nehmad:

Yes. I totally agree. But what are these release notes? So Go 123 came out. We talked about it at length.

Shay Nehmad:

Now it's in the phase of, like, release candidate, another release candidate, another release candidate. Right? It's coming soon. It hasn't been, like, fully fully released yet. It has a lot of things.

Shay Nehmad:

Right? Iterators, there's new things with timers, their garbage collection. We talked about all these things a lot, like, in previous episodes. But if you wanna try them out, like, I don't know about you, Jonathan, but let's say you open a blog post. Right?

Shay Nehmad:

You talked about how you use the demystify the iterators blog post last week. Right? Yep. As a developer, what happens when you open a tech blog post? I scroll to the code and then

Jonathan Hall:

I copy it into my editor and

Shay Nehmad:

run it. So, yeah. This this interactive release note page uses, a project maintained by the same person, by, Anton called Codapi, where you can just run the thing on the web, and see the results. And you can edit it as well, like, interactively and play around with it. So, you know, the entire loop, feedback loop is a lot shorter, which is great.

Shay Nehmad:

Works really well, And you can just look at all the different features like range, iteration, all the iterator types. And also it's also well written. It's not just like, oh, there are examples, so it's nice. It's also very well written. Like, the the explanation about pull iterators versus push iterators is the first time I understood push versus pull iterators.

Jonathan Hall:

Uh-huh. Yeah. You know what? My new favorite feature about this whole thing and maybe this was already there, for the we talked about this interactive release notes for 1.22, 6 months ago. Maybe this feature already existed, I didn't notice.

Jonathan Hall:

But he has links to the proposals for each of these and the CLs where they were implemented. So if you really wanna nerd out and go, like, oh, how is this implemented? The links are right there. You don't have to go do your own homework. You can just click to the the cl, and and see how it was done or click to the proposal and see what the intention was behind this new feature.

Jonathan Hall:

I think that's pretty cool.

Shay Nehmad:

The best explanation for me, I think, is the, HTTP cookies one. Just shows the the problem with parse cookie, then shows parse set cookie and, you know, just shows exactly how it works, and you can run it and it's super super easy to understand, which is great. And cookie named and whatever because that's the exact kind of thing where I you don't need to read any documentation. You just need the examples and and it it's the best way to learn. So really good work, Anton.

Shay Nehmad:

We basically, if you're planning to upgrade to 123, take, I don't know, 15 minutes and just run through this, I don't know, maybe 30 minutes. Iterators are are a bit confusing. And, run through this blog post. And by the way, if you're hosting like a a similar thing to ours in your Go meetups. Right?

Shay Nehmad:

Oh, what's new in Go? In in your cities, in Atlantis, say go, you know, go gopher con. This could be a real good basis for just a talk. Right? Let's just, like, read Anton's blog together and and send him a selfie saying thank you, dude.

Shay Nehmad:

It's a great resource. Because it it really is. It really is. Like, I plan doing that at my company with the Golang

Jonathan Hall:

guild. Mhmm.

Shay Nehmad:

So so really cool. The link, obviously, is in the show notes. So if you didn't know, you can open your podcast player or whatever it is. There's a little thing called, the show notes where it says maybe summary or show notes or description. All the links of all the stuff we're talking about are are there.

Shay Nehmad:

People have, told me they didn't, they didn't wanna open our web page every time, capago.dev, and scroll to the relevant episode or whatever. You can just do it in your podcast player. I tested it in Spotify and it works there. So I know. Awesome.

Shay Nehmad:

So release notes, 123 is coming soon. Yes. What are some new things that aren't in 123? Yeah. I I have a question for

Jonathan Hall:

you, Shai. What do you need to do after the show is over? Write the show notes? And and

Shay Nehmad:

Are they with you about who's writing the show notes?

Jonathan Hall:

Is Is that the only thing you need to do after we, finish the show?

Shay Nehmad:

Finish uploading? Oh, I'm sorry. You can

Jonathan Hall:

only do one thing after the show's over.

Shay Nehmad:

What do you mean?

Jonathan Hall:

Yeah. That's how set finalizer works. You can only set 1. Ah. So if you need to set 2, what do you do?

Shay Nehmad:

Well, define the function.

Jonathan Hall:

Set finalizer is a a pain in the in the rear. Anybody who's who's read about it probably has decided not to use it because it's so confusing.

Shay Nehmad:

What is run time set finalizer?

Jonathan Hall:

Yeah. It doesn't guarantee to be run. So first of all, let's back up a little bit. What is it? What is it?

Jonathan Hall:

Right? So you can set use run time dot set finalizer to set a function that will run when you're when a particular thing, object or whatever, is garbage collected. There's no guarantee that a thing will be garbage collected, because maybe your program will exit before the garbage collector runs, or maybe you're not using much memory, so there's no reason for the garbage collector to run even for a long running program. And you can only set one as we as we discussed. There's a number of limitations with the set finalizer thing.

Jonathan Hall:

And I remember when I was learning Go, I read through this. I'm like, man, this is so confusing. I'm gonna make sure I never ever have to use that thing. Mhmm. There's a new proposal out to definitely do that.

Shay Nehmad:

Is it like a destructor in the sense that I know. When I don't need the object anymore, it's gonna get cold? Or does it have to

Jonathan Hall:

wait until the garbage collection? It waits till garbage collector. So it's kind of like a destructor, except that it doesn't run when the thing goes out of scope. It runs when the garbage collector runs. And so, therefore, it's not guaranteed to run.

Jonathan Hall:

So you can't really use it to, like, close file handles and stuff like that.

Shay Nehmad:

I just imagine I'd use defer. Right? Because that's the that's the that does what I would have used set finalizer for. Instead of setting a finalizer on on an object, so I would just defer the close or or the cleanup or whatever. And I think that's kind of the the reason there's

Jonathan Hall:

not another way to do it, because defer should handle the the majority of those cases. But there are still cases where set finalizer is useful. I don't know what they are, but they exist. But anyway, there's a new proposal to deprecate it and replace it with something called ad cleanup.

Shay Nehmad:

Deprecate it? It's part of the run time.

Jonathan Hall:

Yeah. So it it would I mean, it would still be there. Go one compatibility promise. It would still be there. It would just be, like, no users anymore.

Shay Nehmad:

Oh, like, not deleted. Just like market as deprecated. Please use the other thing.

Jonathan Hall:

Right. Right. And the other thing takes advantage of generics, which of course did not exist once that final is there was invented. And it allows you to to add more than one cleanup function, which is really cool. So you can all you can not only argue about show show notes, but you can also take your kids swimming or whatever you have to do after the show's over.

Jonathan Hall:

You don't have to just be stuck on 1. So it's an interesting, proposal. It's gotten a positive reaction so far, 14 thumbs ups, 2 Rockets, and a couple, you know, pair of eyes, whatever those votes mean. That's surely gonna win.

Shay Nehmad:

Big eyes are like, I'm abstaining. Yeah. I'm voting this right now so you can change breaking news. It's now 15. It looks good but I don't like I really hope to never use it.

Shay Nehmad:

Right? I never use set set finalizer and I've been programming in Go for for a while now. Maybe just because I'm usually doing, like, back end stuff and not super low level stuff in Go. Yeah. I'm definitely not writing, like, compilers or profilers or things, you know, deep serializers or things like that.

Shay Nehmad:

I don't know. Overall, it's nice. It's a nice design.

Jonathan Hall:

Yeah. I like it.

Shay Nehmad:

The the struct is just called cleanup, and the function is just, called stop, which cancels the cleanup function. And the cleanup and the you know, you have add cleanup. You're just adding a cleanup function. Like, that seems pretty nice. It's also a usage of 2 generics, which I the moment I see that, I'm like, do you really need it?

Shay Nehmad:

You have, like you know how in generics have t, whatever? Now it's t and s. Uh-huh. And I'm like, maybe I'll never use it because it's complicated. But it's actually not that complicated.

Jonathan Hall:

I'll probably never use it, but I'll I'll definitely be more likely to use this than set finalizer.

Shay Nehmad:

Alright. So if you need to clean up stuff like us after the show, after our kids, you can upvote, add cleanup. I think, actually, what would be the hardest part if this ever goes to production, which, you know, I'm not sure. It's a it's a big thing to deprecate something in the run time, especially if it's not super used and you have defer. But if it does, writing the tests for this, proposal should be like a master class in quality assurance.

Shay Nehmad:

The all the race conditions, all the data races, all the edge cases, you know, how do you make sure that it works with, different optimizations and with future garbage collection versions and with different garbage collection algorithms? I'm like, oh, woah. Very complicated in my opinion.

Jonathan Hall:

Who who's gonna be clicking that CL link and then go 1.24 release interactive release notes now?

Shay Nehmad:

124? Not not before Or

Jonathan Hall:

128 or whatever this is. Anyway, so this proposal was from Michael Knezic. I think he's on the Go team. He works at Google anyway. He had another proposal this week also, which I I think I'm much more likely to actually use.

Jonathan Hall:

It's a little bit of a corner case, but he had a has a proposal to add a new package to provide weak pointers. You You know what weak pointers are?

Shay Nehmad:

They haven't gone to the gym in a while?

Jonathan Hall:

Pretty much. Yeah. Yeah. It's like when you're you're trying to solve a crime and you're like, this is kind of a clue, like, at least the the guy ran that way. We don't know which of those 6,000 people in that crowd he was, but it's a we see footprints running towards the crowd.

Jonathan Hall:

So, yeah, it's a weak pointer. Right? Mhmm. Oh, not really. So a weak pointer is basically a pointer.

Jonathan Hall:

We know we know what pointers are. You know, a a memory address that says the thing is actually over there. The thing is that it the thing it points to could be garbage collected at any time.

Shay Nehmad:

Oh. How do I, use, weak pointers in Go today?

Jonathan Hall:

Right now, I don't really know how you do that in Go today. I don't know if you can. I think it's a language feature. Maybe there's a way to make that happen. I I suppose with some unsafe magic, you could probably make it work.

Shay Nehmad:

I I can imagine, like, reading the pointer value, you know, out to bytes and then, you know, using it someplace else, like, unsafe, whatever. Yeah. But why like, it's hard for a reason. I don't want 2.2 potentially garbage collected memory because then I'll get a nil dereference. No?

Shay Nehmad:

Right. So why are they useful?

Jonathan Hall:

They're they're useful in a number of situations. The the first one that pops to my mind is if you want some sort of cash for something that's relatively easy to to recalculate. So, like, if if it hasn't been garbage collected, we might as well use the pre calculated version. If it has been, that's fine too. We'll go ahead and, you know, recalculate or refetch the thing or whatever.

Jonathan Hall:

Mhmm. So if you want some sort of, like, lazy caching, you know, where where, you know, if it's still there, I wanna use the thing. Otherwise, I don't. So it could be useful for that. And the proposal talks about a few other, use cases.

Jonathan Hall:

But that's the one that jumps out to me and resonated most with me.

Shay Nehmad:

Okay. I think we talked about something related here, you know, in the, in the proposal in the past. We talked about the unique package, right Mhmm. Being added. And that sort of really conflicts.

Shay Nehmad:

Right? If you remember, the unique package was all about reusing the same strings. Right? Mhmm. With 2 different pointers.

Shay Nehmad:

So making it into a unique pointer into the same string to, like, save on memory. And if you turn one of these, pointers into a weak pointer, now the other one's gonna get invalidated. And in general, I think the abstraction of the garbage collector is, if I'm still using a thing, don't touch it.

Jonathan Hall:

Mhmm.

Shay Nehmad:

Weak sort of, weak pointers sort of make that promise fuzzier, I think.

Jonathan Hall:

Definitely. Yeah. It it it's no longer a promise. It's like, I might be using this to clean it up if

Shay Nehmad:

you want to. Mhmm.

Jonathan Hall:

Like, when you tell your wife, like, I I I'm not done with the model rocket on the on the kitchen table, but if you need to clean the table for for dinner, that's okay. You can launch it. I'm wondering, like,

Shay Nehmad:

again, similar to the, previous proposal, which makes sense because it's by the same person, what's the context of this being added? Right? Like, I I just can't imagine myself worrying about weak pointers or worrying about, runtime cleanup set finalizers, thing like that. But I have to assume there's, like, some context of, Michal here, Michael here, work like, thinking about, oh, I need to do something and therefore I need a weak pointer. So so I'm I'm, like, I'm wondering what what's it all about?

Shay Nehmad:

Maybe we should

Jonathan Hall:

get him on the show, and he can he can answer this for us.

Shay Nehmad:

Hey, Michael. We have a channel on Slack. It's called cup dasho dasho go on your gopher Slack, so contact us if you want to come on the show. Cool. 2, awesome proposals from, Michael this week.

Jonathan Hall:

Yeah. Yeah. So we talked about weak proposals. Like, and and your your first thought was that we said don't go to the gym. So if you do go to the gym, it probably makes you buff.

Jonathan Hall:

Right? Cute cheesy joke music now.

Shay Nehmad:

Alright. Buff. Yes. That was the segue. Now I will start talking about Buff.

Shay Nehmad:

So, I have a, an opinion. I think Buff is should be the de facto way of working with protobuf, right now. In the same way that, you know, you should only use rough for Python linting, linting, and poetry for package management in Python, and going ci lint as your linter, and like, you know, I have a few opinions on, okay, for now, right now, this is the best in class tooling for this tech stack. Right? Mhmm.

Shay Nehmad:

I am certain that buff is that for protobuff. If you remember, we talked about a blog post called gRPC, the good parts. Yeah. Yeah. Good metaphor.

Shay Nehmad:

This is stuff ago for June 28, 2024. GRPC is sort of a high performance RPC remote process called framework, which uses protobuf under the hood. This blog post is about why gRPC is bad, like, the bad parts. So Buff has been, like, building sort of an ecosystem around protobuf. Right?

Shay Nehmad:

The main thing I love about their thing is the CLI. When I say the main thing I love about them, I immediately realize it sounds like a sponsorship. It's not. They don't they don't know I do this. I'm just a happy user.

Shay Nehmad:

And their CLI is open source and it does all the things you'd want a, a CLI to do. Right? It's opinionated, it comes with linting, it comes with the breaking changes, etcetera, etcetera. And they've been trying to build a business around it with, their own protobuf schema registry where you can store your protobuf and share them and, like, do the building on the cloud so you don't have to install all the, proto generators, which is always a huge pain. Then you have to containerize it.

Shay Nehmad:

Blah blah blah. Publish it. So they're taking care of that, which I I think it's a good idea, but I'm I haven't used. Like, I'm not a paying user of this. I'm just using the open source CLI.

Shay Nehmad:

And they've released, actually a couple of weeks ago, but we sort of slept on it, a buff stream, which is an interesting concept. So let me tell you the concept and you tell me what you think. Right? When you hear when you hear it. They are introducing buff stream, which is a drop in replacement for Apache Kafka.

Shay Nehmad:

Right? Mhmm. Which is a huge like, millions of companies use. And they're claiming it's, 10 x less expensive to operate and has protobuf first data governance. It's then, x less expensive because it's using, object storage instead of, like a DB in the back end.

Shay Nehmad:

Okay. So it's just saving stuff to s 3, AWS s 3 buckets. And when you pair it with protobuf, it basically validates data for the topics when you, publish a message into the topic and make sure it it's protobuf compatible. Right? And you save the descriptor on the, like, entry point to that topic so it could, like, can serialize, deserialize, validate all this stuff really really fast.

Shay Nehmad:

Basically, send pre compiled versions of your, protobuf schemas to the topics. And Alright. They're planning to add, field level, access control as well. So, you know, you could have, like, oh, only if this message contains the in the field, the the word admin, then you can publish to that topic, etcetera, etcetera. But it's not there yet.

Shay Nehmad:

Alright. How does that sound?

Jonathan Hall:

So I I've never used Kafka heavily. I've had it on a couple of projects. I've never done much with it. But it sounds good. I like protobuf.

Jonathan Hall:

I like saving money. I think I have questions about, like, performance with regard to s 3. That doesn't sound like a high performance sort of thing, but I'm sure they have a a reason that that works just fine. So, yeah. It sounds really good.

Shay Nehmad:

So what they what they're basically saying is you can get rid of, networking between zones, and you can get rid of, expensive disks. And it doesn't necessarily increase the latency as much as you'd expect. They say that the, p 99 latency is 500 milliseconds and the median legacy is 260 milliseconds. So if you do an analytics workload where it's not, like, real time, you should be fine. Right?

Shay Nehmad:

Yeah. So here's one opinion. Right? This is a really good step forward for Buff and if you're already a full on, like, Buff shop, you're already using the schema registry, this might be a no brainer. Right?

Shay Nehmad:

You probably already developed this for yourself. However, if you're not it's like there's a lot of Kafka with s s three solutions out there. This is not super innovative. And the niche of the like schema and and like enforcement in protobuf protobuf already enforces itself like if you run deserialize in your application, or you know, you try to serialize it before publishing it to the topic, and the message isn't adherent to the schema. It's just not gonna work.

Shay Nehmad:

Right? So Right. Not like if your application knows, what it's publishing towards, it should be okay. So enforcing schemas at the producer level might be a bit stupid because you can already do it with protobuf and with protobuf validate. Like you already have to do it in your application level because otherwise you can't read the data.

Shay Nehmad:

And it's kind of immature only they began designing a year ago. They don't have, like, oh, we use this at Disney. It's not, like, proven at scale or whatever.

Jonathan Hall:

Okay. Yeah.

Shay Nehmad:

And you don't have the community behind it. Right? Like Apache. It's a huge community. Tons of people use it, which support it.

Shay Nehmad:

And because it's it's not Kafka, it's a replacement. A lot of features that Kafka has and and best practices guides, whatever, extensions, etcetera etcetera. Kafka connect. I don't know. They won't, like, work.

Shay Nehmad:

Right? So I'm not sure. And with the main thing being protobuf, if you're not a protobuf shop already, this is not the thing that's gonna convert you and the price, it's better but nothing when you compare it to self managed. I don't know. I I really wanna love it because I love their stuff and I I I would love being a developer that's working in a full buff shop.

Jonathan Hall:

Okay.

Shay Nehmad:

That it's very hard to justify for me this this, product. So I don't know. It's very interesting. I I like it a lot. They have a Slack channel.

Shay Nehmad:

They have a demo. Like, you can contact them to join the beta. This is very early but I found it very interesting. In in a topic that's probably relevant to a lot of, people who are who listen. Right?

Shay Nehmad:

People who do all this data intensive application shit.

Jonathan Hall:

Let us let us know on this on the Slack channel, dashodashgo on the Go for Slack, If you've used it, if you would use it. If you wouldn't use it, why not? We'd love to hear what you think about it.

Shay Nehmad:

Yeah. But but just to circle back to the beginning, if you do do protobuf and you have your own script instead of setting up buff, you need to set up buff already, man. It's really good. Really really really good.

Jonathan Hall:

Sounds like somebody needs to do some, sort of user research, maybe do some sort of survey about about, you know, usage of tools like this. I wonder if we could get somebody on the show who would talk about that sort of stuff. Oh, wait. I just forgot. I just interviewed Alice Merrick from, from the Go team who does that for Go.

Jonathan Hall:

Nice.

Shay Nehmad:

So we're let's just do a super quick lighting round and get back to that.

Jonathan Hall:

Yeah. So stick around, Shay, for, to listen to the interview you missed.

Shay Nehmad:

I missed it. I missed it. I had an emergency. I'm sorry. Alright.

Shay Nehmad:

Lightning round time.

Jonathan Hall:

Let's go. Lightning

Shay Nehmad:

round. First up, Naomi Adgar released a really great intro practical guide called profiling in Go a practical guide. If you've been meaning to get into profiling, you've heard us talk about it and you don't know exactly how to do it. Just open that blog post, read it from top to bottom, and you should be super good.

Jonathan Hall:

Next up, we have, wait for it. Wait for it. Oh, here it is. It's finally loaded. Cogent Core.

Jonathan Hall:

Today, we're announcing the initial public release of Cogent Core GUI framework. Cogent Core allows you to build powerful, fast, arguable, elegant apps that run on all platforms in a single go code base. So it's a GUI framework for, for go to write apps that, at least in my case, took about 60 seconds to load, in my browser. So that wasn't cool. I don't know if 60 seconds is exaggeration, but it took a while.

Jonathan Hall:

It was it was long enough. I definitely would have clicked away if Shai had told me

Shay Nehmad:

to look at the link. So if you're one of the fine fine people on the audience, go check out your new competitor. And finally Page fight. What what? Page fight.

Shay Nehmad:

Like box, fight, but both fighters can't fight each other because they can't figure out how to centralize themselves. I'm GUI developers. Alright. Let's tap into, lightning round. Unit 42 released a new, like cyber research about a new variant of a Golang based ransom hubs ransomware.

Shay Nehmad:

So, yay. More Go development. Woo hoo. I think after the latest crowd strike incident, which we haven't talked about because they haven't doesn't have anything to do with Go. But it

Jonathan Hall:

is probably the biggest thing

Shay Nehmad:

that happened in tech this week. I'm less worried about, new ransomware's popping out, the new security updates for the tools that have to fix them. Yeah. But they're using cool stuff in Go, especially Gophascape, which is interesting to try to hide their thing, but unit 42 caught them. Good good stuff Palo Alto Network who are a competitor of mine, but I'm still appreciative of your security research.

Shay Nehmad:

You have samples available on Virus Total. Link is in the show notes. Boom.

Jonathan Hall:

Boom. Boom. We're done. Lightning went over.

Shay Nehmad:

Alright. We wanted to thank our Patreon supporters for supporting this show. If you want to support the show as well, all our links to Patreon store where you can buy swag, Slack channel, previous episodes, etcetera, etcetera, can be found at cupogo.dev. Please share this show and rate it and do anything you can to help boost our listenership. And now on to the interview.

Jonathan Hall:

I am excited today to be joined by Alice Merrick from the Go team. Shai, unfortunately, couldn't make it today. I don't know what came up, but I'm sure it was important, but not nearly as important as the conversation we're about to have. Alice, welcome to the show.

Alice Merrick:

Alright. Thank you. I'm very excited to be here.

Jonathan Hall:

I'm excited to to talk to you. You learned about our show at GopherCon, I understand.

Alice Merrick:

That's right. I was in Chicago at GopherCon, and I was talking to a couple of attendees. Also shout out for, Robert Burke, who who, first mentioned, cup of Go to me. And so I I went looking through some episodes to help me get started. I like to listen to the Go community.

Alice Merrick:

That's my job. And Mhmm. So I kinda wanna know peep what people are talking about. What do you what are you excited about? And I found one podcast that was all about the community, and I was like, oh, great.

Alice Merrick:

This will be a great, intro. And it turns out you were all talking about the Go Developer survey, which I happen to have run this, you know, a few months ago. So I was super, super just excited to get feedback on that from the community. Most of the time when I'm sharing that survey, I'm I'm sharing it internally. And so I I get some good feedback from the Go team, when I share it externally, then it kinda goes into the blog post out into the void.

Alice Merrick:

And, you know, occasionally, people will start, you know, talking a little bit about it on Reddit or so. But really, this was one of the first times I got to hear some really great feedback on what you found interesting and, you know, what you were confused or why was this in here or how the Go survey has changed. And I was just, oh, man. I would just, you know that was just great to hear.

Jonathan Hall:

That's that's that's nice. I I think that was the episode where we talked with Bill Kennedy. Is that right?

Alice Merrick:

Yeah. It was. So even getting some feedback from him too on what he found interesting was great.

Jonathan Hall:

Cool. So, I wanna talk to you about the the Go developer survey. But but first, I'm I'm curious how you got introduced to to Go to the Go team. What's your history like there? How did that get started?

Alice Merrick:

Okay. So I've I've been at Google for, I don't know, I guess, a little over 6 years now. And I used to work on other developer tools, mostly in Cloud. And so I worked on some some stuff that was internal to Google, so like our internal developer tools and some stuff that was more cloud related. I worked on, probably most most relevant is I actually worked on Garrett for a little bit.

Alice Merrick:

And that is the code review tool that the Go team actually uses. And I I had never, at this point in my life, had never heard of Go until I was doing some research on, you know, what do people find difficult about getting started with with Garrett? You know, why is this so hard? This was something that the Garrett team was interested in. We think it's hard for people to get started.

Alice Merrick:

Can you tell us why? And so I went down this path, you know, like, why, you know, why people use GitHub or Garrett or GitLab or some of these other tools, Bitbucket. And I found a proposal from the Go community that was called just use GitHub. And I don't know if you, I don't know if you remember this. This was this had a lot of comments, and it gave me so much so much to work with, to really help me get familiar with, what people liked or disliked about Garrett, what people liked or disliked about GitHub, and kind of what it meant to the community.

Alice Merrick:

Not just the people who maintain projects, but like the people who are contributing and things like that. And, so eventually, I didn't have the opportunity to just move on to the Go team, but I did get reorganized at one point. And, and I had a choice of a couple different language teams to join. Mhmm. And and one of them was go.

Alice Merrick:

And I wanted to stay in open source. So that's that's where I went. Yeah.

Jonathan Hall:

Are are you gonna tell us the other languages that that lost out to Go? Or is that a secret?

Alice Merrick:

It's not a secret. In fact, like, some of those teams, aren't aren't currently staffed. But, there was a, it was there was a Java team. There was, I think, a Python team, and there might have been something else. Okay.

Alice Merrick:

And so I I decided to to to go and and get started on the Go team, and I loved it. I love the team. I love the community. I love being in open source. As a UX person, it's, I guess, a little unusual to be working on open open source stuff.

Alice Merrick:

Though if you are a UX person or you know one, don't don't ever discourage them from getting involved in open source.

Jonathan Hall:

Nice.

Alice Merrick:

Yeah. It's, I mean, really, just as a, as a model, it's a great model of how a team really cares about feedback from the community, which you don't always get in any, you know, other kinds of product. Or, you know, services or whatever you're delivering, like, the the open source ecosystem and the relationship between people, you know, people at Go, at Google and and the people who use Go outside of Google. Like, it's just a really neat, relationship and a really cool place to be. Cool.

Jonathan Hall:

So how long ago was that that you you joined the Go team then?

Alice Merrick:

I want to say about 5 years.

Jonathan Hall:

Okay.

Alice Merrick:

At this point. Yeah. So I've been around for a little bit. It was just before the pandemic. So there was actually a period of time when I hadn't met anyone else from the from the Go team other than the other researcher who sat in Seattle, and the other the rest of the team was distributed in other places.

Alice Merrick:

And so I think it was about 3 years before I met some of you know, a lot of people.

Jonathan Hall:

Okay.

Alice Merrick:

Yeah. Cool.

Jonathan Hall:

Well, I wanna ask a question. This isn't really go specific, but I think I think it'll be a good question for you. Maybe it is quite relevant because as Go developers, our audience are gonna be very back end heavy type, you know, focused. And I think the idea of UX to most back end developers is something like a React developer who's designing web interfaces. That doesn't sound at all like what you're doing.

Jonathan Hall:

And, you know, I I've worked with some some pretty professional UX people who would who would laugh at that description, but I think that's the common perception. Would you help us understand what is UX, and how does UX relate to something that doesn't have a front end interface?

Alice Merrick:

Yeah. That I mean, that's a good question. I actually got that a little bit from people at at GopherCon as well. It's like, well, what do you do though? And Yeah.

Alice Merrick:

And I'm like, well, have you ever taken the Go developers survey? And then I'm like, well, that's part of what I do. That's I would say, that's the most visible part of what I do. But it's not the only part of what I do. And, absolutely everything that you interact with, you know, a hammer has a has a user interface, Doesn't necessarily need to have a front end.

Alice Merrick:

It doesn't necessarily need to be visual. Some, interfaces are natural language interfaces. You know, if you're talking to your your digital assistant, you might be using natural language or an LLM. You might be using gestures, if you're talking to your lamp or something. You know, there's just all all kinds of things that have all kinds of interfaces, and even developer tools, and developer languages and things that you're using on a day to day basis also have an interface.

Alice Merrick:

Even if you don't typically think about it, Somebody designed that, you know, this keyboard you're using. Somebody designed that, this mouse. Someone designed that. And but also just, like, what your key bindings are, or your or your, you know, your whatever, editor you're using, you know, somebody somebody made decisions about that. And maybe a UX specialist was involved in maybe not, you know, sometimes, sometimes developers kind of come up with these things organically and and things can spread in other ways.

Alice Merrick:

But, you know, if you use Versus code, you better believe there's a, you know, there's probably an army of UX people, you know, behind that kind of thing. So, in a in a language itself also is gonna have, you know, or an API. APIs are designed. Right?

Jonathan Hall:

Mhmm.

Alice Merrick:

And, languages are designed. So anything that is at that intersection of human and some kind of technology is going to have an interface, and some kind of user experience associated with that. So I don't strictly work on graphical user interfaces. I'm interested in the experience of using tools, you know, for humans and, other kinds of technologies.

Jonathan Hall:

Sure. Wonderful. I think this is my last question before we talk about the survey. And I don't know. The answer may be no.

Jonathan Hall:

Maybe it's too nebulous. But is there something you can point to that we would know that you have like, your fingers are so deeply ingrained into that that we could go, oh, yeah. Alice is responsible or largely responsible for this thing other than the survey. Like, another feature of something in the Go ecosystem that that that we would point to.

Alice Merrick:

Something in the Go ecosystem that you can point to. Probably fuzzing. Okay. So if you've, if you've used fuzzing, that was something that I I worked on quite a bit ago and some of the documentation around that and helping inform some of the the use cases there. And then, like, also, I I I don't wanna take all the credit for this because, again, I'm part of a a 2 person team here.

Alice Merrick:

So, I know security, like, go vault and check, in particular. Yeah. That, UX had their had their hands on that. Yeah. So, and that that's just a couple examples.

Alice Merrick:

You know, sometimes people will respond to my research in ways that I haven't even kept track of. So,

Jonathan Hall:

you

Alice Merrick:

know, I'm sure that the the Go team could probably even point to more examples that I'm necessarily not even thinking about. Well,

Jonathan Hall:

I I love those examples because I just think it helps make it tangible that that that what you're doing is, like, go Volcan check. I don't think it has any graphical interface component. Maybe there is one somewhere. But, like, okay, you did that. I could I I now I can imagine the kind of work that you're you're doing.

Jonathan Hall:

So that Yeah. Helps make it more more tangible. So let's talk about the survey. Yeah. Hopefully, every listener has taken the survey.

Jonathan Hall:

We we we always encourage our listeners to do that. I'm sure they haven't all done it, but my first question for you is, at a high level, what are you hoping to learn from the survey?

Alice Merrick:

Alright. Yeah. This is a that's a that's a big one. There are so many things. And I usually when I start out, I have a list of things, like, these are my goals for this, this edition of the survey.

Alice Merrick:

The survey is not open right now, but, we are actually about to start another round.

Jonathan Hall:

You do it every 6 months. Right?

Alice Merrick:

Us about that. Yeah. We use we've started doing it twice a year. We used to just do it once.

Jonathan Hall:

Okay.

Alice Merrick:

And so, some of the things that I wanna learn. Every time we have some, like, sort of top level metrics that we keep track of year over year, are those steady? You know, have we seen any big shift? That's that's one thing. That's, you know, things I can pass up the food chain to be like, Yeah, we're doing all right.

Alice Merrick:

Kind of, you know, gut check. Then there are other things that we collect, every year that are, like, how people are using Go to see, like, are there any changes there and how people are using Go, what they're doing with Go, what kinds of other tools they might be using along with Go, different preferences for other, you know, like IDE, things like that. What are they what are they developing on? And this informs, 1, like, sometimes how we, you know, interpret changes that we're that we see over year over year. Right?

Alice Merrick:

So if we see that these things are stable, then we can say, like, yeah, our population is about the same. We should expect, you know, these results to be, you know, to we would expect changes to be attributed to things that we did rather than changes in our population. Right? So we do collect some of those, even things like how much experience do you have with Go or, what size organization, things like that. That kind of helps us monitor those more metadata kind of things.

Jonathan Hall:

Mhmm.

Alice Merrick:

And then I usually have a couple of topics that I'm interested in. And one of my one of my chief goals is always to help the Go team prioritize what kinds of things they're gonna be working on in the next 6 months or the next year. Right? So finding out what's really, important and critical, to people. So you might see lots of questions on the survey that are like this that deal with, like, hey, how important is this to you?

Alice Merrick:

Do you do this or this thing or this thing? And that's because it's gonna help the team, you know, determine, okay, this is where I should focus. Because a list of issues is a great place to start, but it doesn't really help you know how much of an impact am I gonna have if I take on this work, right? So helping, helping the team, determine what to prioritize and what kind of impact they can expect to have by doing certain kinds of work. That's, like, kind of like, if I can do that, I nailed it.

Alice Merrick:

And then I usually have, like, a couple of other topics that, maybe there might be related to other ongoing research, that Todd and I are doing. They might be related to, maybe even other, like, things of interest in, in other developer ecosystems like this last year. AI has just kind of been in the zeitgeist. So we did ask a lot of, AI related questions. Sometimes these are questions that are related to, other, you know, other people that we partner with, like Deborah or maybe people who, do other kinds of things in the community.

Alice Merrick:

Like, are there certain kinds of questions we can help them, answer and that kind of thing. So I usually have, like, a lot, you know, a lot of things that I'm trying to do. I try to limit to, you know, okay, here are my, like, top 3 or 4 goals or whatever.

Jonathan Hall:

What has been maybe your biggest surprise over the years as you're doing developer survey? Have you ever gotten any answers that were like, wow, I really did not expect that?

Alice Merrick:

Well, I will I will say that, you know, I've I've been asked this before and every nothing is surprising in retrospect. I'll tell you that.

Jonathan Hall:

Yeah. Uh-huh.

Alice Merrick:

It's, so I I often will have to kinda write out ahead of time, you know, what do we expect to find here to determine whether or not something is surprising or not. And I will say that just in the in this past year, something that surprised me, how different things like operating system preference are globally. And so, we tend to get lots of respondents who are from North America, Western Europe, basically, people who are very comfortable responding to a survey in English because at the moment, that's the only, language it's available in. And so some of our data, it reflects that, that population very well, but it might not be as reflective of Go developers in other parts of the world. Right?

Alice Merrick:

And so that was something that we discovered. I wouldn't necessarily say we discovered it this year, but it became a little bit more obvious to us this year when we introduced a a new source of sampling for the survey, and that was through the JetBrains, collaboration. Mhmm. So over the 2 week or so period that the that the survey was over open, about 10% of people who use Go land, were asked, like, hey, you're using Go, like, would you like to participate in the Go Developer survey? So this was, like, you know, about as close to a random sample as we can sort of expect.

Alice Merrick:

Mhmm. And, we did get to hear from people in other parts of the world than we normally get to hear from. And and this so we had a little bit more to be able to say, like, hey, it looks like people in these parts of the world might have a greater preference for just developing on Windows than, you know, than we see here. And it kind of helped us, actually understand some of our website data, which seems like, hey, it seems like we have a lot of Windows users. Where are they?

Alice Merrick:

And it's like, okay, this is why like, you know, we're just not hearing from them in this source. But, we can hear from from them, from some other source. So that was, I would say just on this last, on this last iteration that was surprising to me, there have probably been other surprises that, you know, over time, you just get inured to, you

Jonathan Hall:

know. But I I like that answer because it it leads me right into, like, the the thing that always jumps out of me at being this eternal skeptic that I am. When I look at the results of the survey, the the number one highlight is developer sentiment remains high with 93% of respondents expressing satisfaction with Go. But the people who hate Go aren't gonna respond to a survey. So how do you account for that?

Alice Merrick:

Well, you'd be surprised. I mean, have you been on have you been on have you been on Amazon? Have you seen, read read the reviews there? No. Sometimes I do actually get, I mean, this is a fair criticism.

Alice Merrick:

And we have asked, people who say they are dissatisfied why The this is something that we've done on past surveys. We don't do this every year because the answers don't tend to change a whole lot.

Jonathan Hall:

Sure.

Alice Merrick:

But it usually has to do with, there's something I need that Go doesn't do either. It's some kind of language feature, or it's some library that exists in, you know, some other language ecosystem that Go is just not, you know, nobody's ever really invested in using Go for that. So, that tends to be the the the thing that I that I hear, you know, the most. I've also done research where I talk to people who try to adopt Go and did not.

Jonathan Hall:

Okay. Yep.

Alice Merrick:

So so I'm so I definitely go out of my way to talk to those people because I know they're not going to necessarily be as common on my service. Mhmm. So I have to make a point to talk to people who are unhappy with Go. Sure. Actually, once I met 1, I go for, like, coming up to me, the very just very proudly telling me all the things they had to hate about Go and why it's so awful.

Jonathan Hall:

Curious why they went bought a ticket. But hey, whatever.

Alice Merrick:

Apparently, it was they said it was the best tool for their job at the time.

Jonathan Hall:

Okay.

Alice Merrick:

So but it but it was it was, it was fun for me. But anyway, back to, you know, so we have a couple of different sample population. One way that we advertise the survey is through the go blog. If you read the go blog, you probably really like go. Yeah.

Alice Merrick:

This is true. Now if you're just using go as a part of your, day to day job, you're maybe not like you don't follow the ecosystem that closely. You you're not reading the Go blog. You're just like, I'm just I'm punching the clock. I'm doing my, you know, I'm doing my job and I'm going home.

Alice Merrick:

Mhmm. Maybe you would have heard about the survey through your IDE plug in, you know, Versus code or maybe your Go land user. And, you know, it was like, hey. I noticed you're using Go. Do you wanna tell us about it?

Alice Merrick:

So that's more of a random sample. Of course, somebody has to elect to be like, yeah. Okay. I'll do it. Mhmm.

Alice Merrick:

But sometimes people are, you do expect more extreme answers, right, from people who are sort of electing to participate. Right? You you would expect to see more people who are unhappy, more people who are happy. And when we do comparisons between people who come from a blog and people who come from these other sources, there's statistically not any difference in how we have measured customer or CSAT or customer satisfaction. And this, this gives us some confidence in that number.

Alice Merrick:

And we also see like, this is also a way for us to track things over time. Right? So we can make comparisons year to year. If this dropped dramatically, that would that would be, you know, at least, that would be a terrifying signal. And, so, you know, that either something had dramatically shifted in our population or something had dramatically shifted in how we're doing.

Alice Merrick:

It's important for us to have metrics like that that are just kind of like, I'm taking your temperature. This isn't gonna be this isn't a diagnostic tool. Right? We have to ask other kinds of questions for that. But this is a way to take a temperature.

Alice Merrick:

And this kind of question, it's called a CSAT. I actually had a laugh out loud moment when I was listening to you talk about, NPS and, and CSAT. You know, these kinds of things, they make it easy to make comparisons with yourself year over year. And so and and CSAT is also something that's used, I think, by every product at Google. So it helps us compare with other people who are like us.

Alice Merrick:

Maybe other, you know, other kinds of developer products or tools and that and, things like that. So it can help us, like, hey, look, the Go team's doing something right over there. Their, their CSAT is very high. How are the rest of you doing? So so it helps make, helps to make comparisons, even if it again, it's not the most like, it can be in some ways like, hey, we did good pat on the back.

Alice Merrick:

And and I think, like, some of that is is still also important. Like, hey, we know we're still doing a a good enough job.

Jonathan Hall:

Yep. The, the second highlight from, this last survey says that a majority of respondents, 80%, said they trust the Go team. And and obviously, you're gonna have your own bias here because you're on the Go team. But one criticism we hear, especially in corners of the Internet, like Reddit, where people are just eventually negative is Google is is railroading things through, you know, they they already have decided they're gonna do, let's say, telemetry. Now that was a that was one sort of hot button issue where this complaint came up.

Jonathan Hall:

We know that they've already decided to do it. It doesn't matter. They're just they're just it's just a show to make it look like community support. How how do you respond to this? I mean, obviously, 80% of people apparently don't think that this is a problem, but probably more than 80% know this is a problem.

Jonathan Hall:

But there are certain vocal minority who who who sort of rag on this. How do you respond to that as somebody whose job it is to learn from the community?

Alice Merrick:

Yeah. So this was an experimental question this year. We had never asked this before. Mhmm. It was something that in the developer space at Google, people are starting to be interested in in measuring developer trust, not just, on the Go team, but in, you know, we you know, we've got Android, we've got Chrome, we've got, you know, Flutter, we have all these.

Alice Merrick:

And so this is something that's, of interest to see, you know, what is this like? Does you know, and and what does this mean? And how do we measure this? And so this was an experimental question. And, honestly, we didn't have any way to really interpret what this meant when we collected this.

Alice Merrick:

So I did a follow-up study. Alright. To actually learn, you know, when we ask people, you know, how much do you trust the Go team at Google to do what's right for developers like me or something like that. Or make, you know, and and we wanna know, like, you know, when we say this sentence, what is what does trust mean to you? What does the Go team at Google mean to you?

Alice Merrick:

You know? And and so how are you kind of interpreting this question? Why did you give it the response that you you gave it? And in it and it seems that, like, kind of what this means is, like, super multifaceted. There's, like, there's lots of literature on just, like, trust and how to measure trust.

Alice Merrick:

And some of it mapped, pretty well with what we found, and some of it was, like, a little bit, different just because sometimes people ask about, like, how much do you trust an organization or how much do you trust this particular technology? The way that we asked it was kind of like, how do you how much do you trust the Go team at Google? You know, is the it's a little bit kind of in both camps. You know, is it a, you know, is it a technology? Is it an organization?

Alice Merrick:

What's going on here? And so, well, some of the things that we found is there does seem to be this belief that the Go team cares about and has the capacity, you know, or the competence to be able to make good decisions for go. And that we take into consideration the people who use go when we are making those decisions. And so it's kind of like some competency, some benevolent. There's, you know, and then also just belief that Go will improve over time.

Alice Merrick:

So I will say that that seemed to be, the things that that's the way that I'm interpreting, you know, what they're telling me when they say, like, yeah. I I, you know, I somewhat or very much, trust the Go team at Google. Now, this is something that we're probably gonna continue measuring over time, and we're probably gonna ask even more, like, like, more granular questions in the future to really understand about, like, what are the components that go into this trust and things like that. So, I will say that this is the beginning of this metric. It is not the end of this metric.

Alice Merrick:

I know.

Jonathan Hall:

I think I don't remember how I answered that question. We I may have talked about it on the previous episode. I don't recall. But I recall that, like, when I look at the summary, the the thing that jumps out of me is for developers like themselves. Like, how many developers are are actually like me?

Jonathan Hall:

Like, maybe I implicitly trust the Google team or the Go team to to make all the objectively correct decisions, but I was in such this weird niche corner that, like, none of those decisions apply to me because I'm I'm unique in in, of course, all my all my weird esoteric ways. So, you know, that that's one of the thoughts that jumps through my head and I'm I'm sure you had all sorts of responses, you know, that picked on different different aspects of that. Yeah.

Alice Merrick:

Yeah. So I mean, another another thing that we can do in the future is ask, you know, why? Why do you, like, why do you trust go this much? Or why do you not trust, Go this much? And, you know, I learned just to learn more.

Alice Merrick:

But, yeah, I think you did talk about it on the episode where you mentioned you I think you specifically mentioned telemetry and the decision to make it opt in rather than opt out.

Jonathan Hall:

Uh-huh. The last several items on and this highlights are several of the items were about AI. I'm not gonna go into the specifics there because there's just so much there, but I'm curious. Obviously, AI was a big part of the last survey. What did you learn, in broad strokes about AI in the Go community that that was relevant to you?

Alice Merrick:

Yeah. So, my my colleague was doing some other research related to AI. And so, I think parts of these were more things that were you know, he's trying to triangulate some data with, you know, interviews he's doing with, you know, things that we're finding on the survey. So some of that was just sort of, like, triangulate. Like, can we get a put a quantitative measure on, you know, other things that we're learning?

Alice Merrick:

So, one of the things that we wanted to know was, are people trying to use Go in, like, similar or different ways than how they're using Python? And, like, where is Go fitting in this, this AI space, and how are people potentially going to use, Go in the future here. And it doesn't sound it it's it doesn't sound like people are, like, yeah, I really need, you know, whatever Python libraries, the you know, I'm thinking all I can think about is matplotlib because it's the only thing I use. But but but, you know, other other things like, you know, whatever ML or AI related libraries, you know, is that something we need to build? Do we need to build interoperability with Python?

Alice Merrick:

Like, what do we need to do here so that we're sort of meeting people where they're at? And so that was one thing that we took a look at. It sounds like people who are doing AI ML, which is, like, not everybody. Right? So lots of people that we talk to are not in the space, and, that that seemed right to me.

Alice Merrick:

You know, maybe some people who are working on back end of an application, maybe these are not the AIML people. Like, it's not like we surveyed a bunch of data scientists. So the fact that not everybody is doing this, okay, that's not super surprising. And the fact that the people who are doing this are not necessarily using Go. Also not like again, like, not not too not too surprising.

Alice Merrick:

There there weren't a lot of surprises here, but it was but we also didn't know. Yeah. That's the thing. Is we also didn't know.

Jonathan Hall:

Punches and now you now you're more confident.

Alice Merrick:

Yeah. And surveys are good for that kind of thing is, sort of testing a hypothesis. They're not necessarily the best at generating every possibility of of response.

Jonathan Hall:

Sure. Yeah. What should we be looking forward to in the next survey? Can you give us any, any sort of hints? Or is is that does that violate the validity of the results if we know ahead of time?

Alice Merrick:

Well, I I, you know, I'm really happy to tell you that I it's not written yet. And so I might have to turn this back on you. And ask you, I need to ask you, what do you want to hear more of? From because I'm actually in this process right now is like collecting, you know, feedback and questions and stuff that that's gonna go on the next survey. And so I'm curious.

Alice Merrick:

I I don't always get to address, you know, the community directly and, what do they wanna hear more about? What's interesting to them and what's gonna help them make decisions for the next, you know, 6 months or year?

Jonathan Hall:

So that reminds me of something I just saw. I have to look it up here. Oh, they they were they were curious how many applications, like the split of application deployments by operating system. Mhmm. And they looked at the survey and and they found I pro and it says I primarily deploy go software to and Linux windows and so on.

Jonathan Hall:

But but I noticed that this is about how many people deployed to those places, not how many applications are deployed on those on those operating systems. So, like, to be to be silly extreme, if all of the Windows developers are built working on one app, who responded to the survey, that would be a point of 1. And if every Linux developer is respond is working on a set individual app, of course, you know, that there'd be 1,000,000 or, in this case, 5,005 100 Linux apps and one Windows app, but the numbers look different because they're talking about developer numbers. You see what I'm saying?

Alice Merrick:

Yeah. Yeah. That's true. You can No.

Jonathan Hall:

I don't know how you could possibly solve that with the with this sort of survey. But

Alice Merrick:

Yeah. You you can't Yeah. From what we asked, we just asked, like, which platforms are you deploying to?

Jonathan Hall:

Mhmm.

Alice Merrick:

And they could select as many as, you know, as they do. Yeah. And and maybe they only had one application on

Jonathan Hall:

Oh, sure. Yeah.

Alice Merrick:

Yeah. But then they have to

Jonathan Hall:

Yeah. Yeah.

Alice Merrick:

Yeah. And that's yeah. That's not represented here. And so my question is, is that, like, is that distinction really important? And, and like, what what would that help you, what kind of decision would that

Jonathan Hall:

help you make? It would help me win an Internet debate. That's really all that matters due to me. I I don't actually I don't actually know what what, I I think it was a point of curiosity for the person who made the the observation, and I was just pointing out that these aren't exactly the same thing. You're you're not making quite the same, the data you're presenting to this person on on LinkedIn.

Jonathan Hall:

The data he's presenting doesn't quite make the claim he's claiming it does, but it's a close one. So I was just being my my normal internal skeptic. It wouldn't matter to me, that particular thing. So I don't think that's gonna help you in the least. Yeah.

Jonathan Hall:

Just the first thing to go to mind.

Alice Merrick:

Yeah. Well, that's the thing. Well, I mean, this is a good demonstration of why I sometimes say no to questions on

Jonathan Hall:

Yeah.

Alice Merrick:

The Go Developer survey as well. It's like, sort of in this process, I have to have a valid reason to collect data, like, just as my my duty as a data steward is that I can only collect things that we're going to use, and that's going to help us in some way. And curiosity, I have to is pretty low priority, like, unless it's gonna, you know, unless it's gonna help us, move forward, which is, you know I I mean, there's nothing wrong with asking things, out of curiosity. Lots of academics do that.

Jonathan Hall:

Of course.

Alice Merrick:

But that's just not my that's not my duty to the to the Go community and the Go team.

Jonathan Hall:

So one thing that I would find very fascinating as a host of a of a podcast that tries to help promote Go is, what libraries are missing that would that would make Go adoption easier? And, you know, I we we bring on a lot of guests to talk about, data science and and AI ML stuff in Go because we feel like that's an area where Go is growing, kinda like you were just talking about Go versus Python. I would love to see Go, really compete with Python in that area. I think it's a better language for that, you know, with type safety and it's faster, all these things. But there's a strong sentiment not to and I think from the survey you've seen that a lot of the reason is it's missing libraries.

Jonathan Hall:

So, you know, that would be one area, but I don't I'm not exclusively interested in in that. But just in general, like, where could could I, as a co host of a podcast and as an open source contributor, where could I spend my time to help help fill in the gaps? We don't need another ORM. We have enough of those. We don't need another web framework.

Jonathan Hall:

Where could I spend my time with interviews and with with contributions to open source code that would help promote Go?

Alice Merrick:

Okay, well, there's a couple of there's a couple of things here that I want to tease apart. And one is, the idea that more libraries will increase Go adoption, which my research does not indicate that this is necessarily true. I don't think that that's true. But I could talk about that. But I want to address the missing libraries thing, because I have asked this before, as I specifically said, what if anything, would let you use go more, you know, and I have this, I I asked this question as an open text, question for for several years, and then we moved to a format where we provided the responses based on those those previous things.

Alice Merrick:

And one of them was, missing libraries or other things that were missing in the ecosystem. And then if they selected that response, I then said, okay. Tell me what's missing. What's the thing that's that's, blocking you? And for some people, it was GUIs.

Alice Merrick:

They want to, you know, they're like, oh, I just I I wanna build GUIs. And for some people, it was AIML. And again, I asked this sort of, like I think the last time I asked this was, like, 20 or 21. So, you know, things have changed, you know, since then. But that's, like, that's where, like, you know, that's where people kinda wanted to to see more, you know, more libraries or more support.

Alice Merrick:

But the things that they were building were, like, because I also asked them in other surveys, like, okay, if you're using Go for GUIs or if you're using Go for, you know, AIML, like, what, like, what are you doing? Why do you use Go for this? And, like, some of them were just kind of like, oh, well, you know, I I wanted to learn. It was fun. It was a side project.

Alice Merrick:

And so, like, for some of those kinds of things, it was like, well, it was hard to make a business justification for us to go and build those kinds of things. But there's definitely interest there. Like, definitely, like, if if you're if you're looking for, like, what are just people just interested in doing, GUIs and and GUIs and AIML are kind of like the top things that that we, you know, have have we've been told that that are missing. And, you know, there are some good reasons, like, even, you know, there might even be business cases now for doing some of these things, and go, when I ask people why do they, like, why do they use go for gooeys or why do they want to, one of the responses is very much similar to why people write CLI in Go, which is one of the most common use cases for Go.

Jonathan Hall:

Mhmm.

Alice Merrick:

And it's like, well, it, you know, deploys anywhere. You know, like, it's just so easy. And it just so happens that my end users, prefer a GUI than than a CLI. So it seems like it's kind of for, you know, sort of similar things. You know, I'm building this, like, little utility or something.

Alice Merrick:

It just so happens that my end users, don't like CLI. They they wanna they wanna gooey. So and I'm like, hey, that's that's like a, you know, that's pretty good. And I know that there are some things that exist in the the ecosystem that will that will help people do that. I don't know how I don't know how well supported or maintained or whatever.

Alice Merrick:

I don't know if this is meeting people's needs. It's not like a thing that, I have specifically looked into. But I do know that it's, you know, it is the thing that people are interested in. And, like, maybe it's just so that they can, you know, they have a starter project, and it's fun. Like, and I think that that's also a good like, that's a that's a good important use case.

Alice Merrick:

It's just not necessarily one that, the Go team is gonna go out and build.

Jonathan Hall:

Yeah. Cool. Yeah. I think, you know, you you joined the Cup of Go channel. I don't know if you're Yeah.

Jonathan Hall:

Hanging out there regularly now, but, you can we can reach out to you there. Yeah. My final question that the question we ask all our guests, when you first started learning Go or were introduced to Go, what was your biggest surprise?

Alice Merrick:

So we talked about this a little earlier and that I don't write Go regularly Mhmm. But something that is different, about Go that I found surprising is, just from what I know about, you know, things like Java and, you know, and other other languages is they have frameworks, and they have, you know, lots of ways of doing things. And in Go, there seemed to be kinda, it was a little bit more I don't I don't wanna say bare bones because that makes it sound negative. But Yeah. There is, it seems like very easy for people to, read and understand each other's code in ways that, like, you can when you when I looked at Go, I could see this language was really meant for, for, you know, kind of big software projects with lots of people working together on them.

Alice Merrick:

Like, it was really trying to solve the problems of, software development as a social activity. You know, even, like, gofump. Like it, you know, it's formatted the same, we don't have to fight about, and little details like that, as well as the sort of lack of these, like, you know, big, big frameworks, made it something that was really easy to share, like with other people. And so I would say that that for me was like the, I would say the biggest surprise. And that it's kind of I realized that's kind of high level not like,

Shay Nehmad:

Oh, that's good.

Alice Merrick:

But I don't use it. Yeah. But yeah, that that was in and also just like how much people love it.

Jonathan Hall:

Yeah.

Alice Merrick:

I don't always I haven't always worked on things that people love. So that was, that was,

Jonathan Hall:

As a UX enthusiast, I'm sure that's a relief.

Alice Merrick:

Yeah. I mean, that really feels good.

Jonathan Hall:

Yeah. Good. Great. Well, Alice, I really appreciate you coming on. It's it's good.

Jonathan Hall:

I I think you're the first present member of the Go team to come on the show. We've had some past members.

Alice Merrick:

Exciting.

Jonathan Hall:

I I think you're the first one who's, a current member of the Go team on the show. So if if I'm wrong, I apologize to whoever I I forgot, but I I I'm pretty sure you're the first.

Alice Merrick:

Yeah. Well, that's great. I hope I I hope this starts a a new trend for you if you're interested in talking to GoTo members. Yeah.

Jonathan Hall:

Well, thanks so much for coming on, and thanks for sharing your wisdom. Maybe we'll have you on again soon. And, until next time. Alright.

Alice Merrick:

Bye. Yep.

Creators and Guests

Jonathan Hall
Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Shay Nehmad
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Don't skip the gym! 🏋️ And interview Alice Merrick, UX researcher on the Go team
Broadcast by