Opening up the opinion box

I remember when I first saw unpopular opinions on Twitter, of course, people saying it, and then it got very meta. It was like people saying “Unpopular opinion”, and then saying a very popular opinion.

Right.

And it got quite funny.

Yeah, I do recall that theme on Twitter. There was even a Subreddit called Unpopular Opinion. And I remember getting kind of snarky and mad about it, because - not the Subreddit, but the Twitter theme - because people would use that as a way of getting viral tweets, but their opinions were always very blaze. So the template was like state “I’m gonna say an unpopular opinion”, and then insert one of the most popular things you could possibly say, and then go viral. That was the formula people were using.

Yeah, like “Unpopular opinion: I think we should all keep breathing oxygen!”

Exactly. [laughs]

“Unpopular opinion: drink water.” It’s like, “Okay, yeah. Fair play.” There’s something about this idea of having a regular segment that you take very seriously, of something that can be quite silly, and that’s what I thought it was gonna be at the end of the show… And it kind of is; it’s a time everyone can kind of relax, we’ve sort of done the business, we’ve talked about the important subject, and at the end of the show we can relax now, it’s unpopular opinions, and it can be silly, and we can disagree, and it’s quite fun. But it turns out as well, there’s been some really interesting conversations there too, hasn’t it?

When we first started the segment, it was supposed to be incredibly silly, not serious…

Yeah.

[03:53] And then we thought it’d be kind of fun to lean into that in kind of a sarcastic way and make it as serious as possible. Hence, we’re recording you, we’re gonna take a clip, we’re gonna take the time to make a clip of your opinion, we’re gonna put it on Twitter, and we’re gonna ask everybody what they think about your opinion. So you share the opinion on Go Time, and then we have a poll and a very official poll on @GoTimeFM on Twitter… And not only that, but we actually track the results and save them for a later use. It couldn’t get more serious. I mean, practically, you could start a government around such a policy.

Yeah.

And maybe we should. Maybe that should be an unpopular opinion.

Yeah, that probably would be an unpopular opinion. I copied each one of them out onto a parchment and keep them locked in a dungeon nearby… And I’ve collected that box today from that dungeon; it’s very old and ornate. Look at this. What do you think of it? Can you see it?

It’s quite ornate.

Yeah. I said that. What do you think about it?

It’s old, and ornate. I’m impressed.

Yeah, it’s nice, it’s nice.

So in there you have all of the unpopular opinions. Well, not all of them. You’ve collected the most unpopular and the most popular… And today we’re gonna pull them out and give the feedback on what actually happened on Twitter. Because on the show, you hear the opinions, and on Twitter you get the results, but we’ve never brought the results back to the show, so that’s what we’re here to do.

Yeah. I thought it was a great idea when you took them to Twitter and started to really find out if they were popular or not. But that’s the thing, if something is 70% unpopular, what does that mean? Has the person done well in the segment? They’ve made something that’s unpopular? Is that the goal? Or is the goal that they want their opinions to be popular? I still don’t know.

Well, that’s the funny part - it’s because you started telling people if their opinion is popular, they have to come back on the show and try again. So it seems like the goal is to be as unpopular as possible, unless you wanna go back on Go Time; then you’ve gotta go popular and hope we invite you back.

Yeah…

It’s getting pretty meta.

Yeah, I don’t know how people are playing it these days, to be honest.

Well, we know how Grant Seltzer played it on episode 159. This was from GopherCon last year - what to expect when you’re not expecting. Grant has the prize as the most unpopular opinion of all times.

Baseball is the by far most exciting sport in the world

Baseball? Which one’s that?

It’s the one with all the bases and the ball.

The ball. Clue’s in the name.

Clever name now, actually. I genuinely didn’t actually make that link. Well, Baseball - it gives us lots of metaphors, doesn’t it? It contributes the most metaphors, but I don’t know… Hana, do you agree? Is baseball a good sport?

Yeah, I don’t know.

Latin America?

No, not really.

No, we have different versions of it, I don’t know… But yeah. So that is potentially unpopular.

Apparently so, yeah. That’s what we’ve heard. According to Grant, yeah. Derek, is baseball the best sport?

I watch Starcraft online, the Starcraft championships.

That’s all exciting.

But I just don’t go outside, so…

There you have it. Is it baseball or Starcraft the most exciting sport?

Well, it depends…

Well, 95% of people disagreed with Grant…

That’s amazing.

…that baseball is not the most exciting sport in the world.

Well, there we go.

[07:59] So it’s kind of funny that the most unpopular thing has nothing to do with Go or programming.

The thing is it’s a tough one, isn’t it? Because you’re making a very bold claim. I mean, saying it’s the most exciting sport… If you just said “Baseball is one of the most exciting sports”, you could have made a few more friends, I think…

Yeah, so that’s part of it. I think certain people hedge their opinions to make them more agreeable, and then others just lean into the extreme, like Grant did here, and that’s when they get most unpopular. I also agree with Derek that the word “exciting” is really what it hinged on… Because I’m a fan of baseball; I think it’s a great sport, I enjoy it quite a bit. I would say it can be intense, or drama-filled, but it’s definitely not the most exciting. There’s a lot of downtime in baseball. There’s a lot of standing around, there’s a lot of downtime… You might even say it’s one of the most boring, even though it has moments of extreme excitement. But I think if you would have said that it’s the best sport in the world, he wouldn’t have gotten most popular, but he would have probably been more in the middle, where he’d split the audience. But by calling it the most exciting, I think he won the prize of most unpopular of all time.

Yeah, well done to him. I think that’s an achievement, isn’t it?

It is. He’s number one.

Yeah.

Number two goes to Steve High.

Should we have done these in the reverse order?

Why reverse order? [laughter]

Well, it’s like, five, four, three, two, one. Building up to the best one.

No.

Okay. [laughter]

But I appreciate the mid-show feedback. No, we’re gonna just go this order.

Okay, fine.

Number two.

Yeah.

Steve High, on episode 179, “Event-driven systems.” I do not believe you were on this episode. Also one of our most listened-to episodes of all time.

I shared this with Dan yesterday, and he didn’t like it at all, so I’m pretty sure this is unpopular. I think the overuse of err as an error variable - I think it makes code harder to read. Now, there’s a lot of guard rails around that statement… Obviously, you shouldn’t be writing 200 and 300-line functions. I don’t know, I think errors should in some way describe what the error actually is, even if you put an N, or a g in front of it.

I don’t know, I see the reuse of err too much, and to me it just makes code a little harder to read. As a corollary to that, I think there is another part of the language that people don’t use that often, and that is naked braces. You just have two mustache braces, and then – to me, I look at the code and I can just totally read it a lot cleaner, even though it does some things with scope as well… It just makes things a lot easier to read. An old guy like me, with failing eyes, it’s really hard for me to figure out where that err began. I just can’t. So just give it a better name.

See, this is where it gets interesting. It started as a silly thing, and now – like, that is a genuinely interesting point that was just made there. And it’s unpopular in the sense that almost everybody writes Go in that way, using the err variable to call errors. Sometimes there’ll be a reason why maybe you’re dealing with two errors, so you’ll give them specific names…

Like err1 and err2.

Yeah, or sometimes a little bit more – yeah, it can be. Or sometimes a bit more descriptive, like – you know, you might be doing a parsing task whilst also trying to save some things. It might have a parseerr and a saveerr.

Right.

But it’s the exception, it’s not the rule… So it brings up an interesting point then - you can’t really argue that code should be made more clear, and if doing that would make the code more clear. That is a really interesting idea.

Yeah. There’s also clarity in convention as well; since everybody uses err, doesn’t that make it clear in terms of what it is? I guess in the case where you have multiple things, it doesn’t. But because the convention in the Go world is to do that, it seems like going away from that, being the one contrarian actually makes your code less clear.

Yeah, that’s a fair point. So then are we just gonna do what’s popular because it’s popular, for its own sake, because it’s sort of already established and it’s hard to fight? Or do we try and evolve “Is it worth a fight, to battle or try and change minds there?” That’s really interesting.

[12:14] There’s also a bigger thing here that this plays into, which is abbreviating things in code, in clarity… Because brevity is the soul of wit, but it’s not the soul of readability necessarily. And I’m not a big fan of just chopping words up, especially in this case, if we just say like “Well, a word you’re abbreviating is error, and you’re abbreviating it with err, which is just two letters shorter.” I understand taking internationalization and saying i18n. To me that’s a huge win. But this seems like such a small win; I wonder where it came from.

Yeah, I don’t know. I think probably the tradition of C. There’s another thing that Dave Cheney often talks about in Go, which is that if you’re using a variable nearby, i.e. if you’ve just got a little loop that you’re gonna loop around something, then single letters are fine, because the context is right there in front of you. If it spans multiple pages or a full page of code, maybe you lose that context of what that thing means, so it’s worth having a slightly more descriptive thing. Sort of like the further away you get from where it’s being used, the more descriptive its name needs to be. Fields in a struct, for example, need proper, good names, ideally, rather than single letters.

I do agree with that one. I think that’s a good way of going about it. Well, 91% of people disagreed with Steve High on Twitter. So Steve, you are the number two most unpopular opinion of all time. Apparently, err is what people wanna use.

There you go. So it’s established now… And there is value in that, in sticking with the proud wisdom idioms.

Yeah. I would say that if you do wanna change the way the crowd works, I think coming on Go Time and having this unpopular opinion that states your case is a good way of going about it, versus merely changing your own code in the code that you write, and never telling people why you’re doing it. So maybe you can convince some people. But only 9% so far, at least of the Twitter folks.

Let’s move on to something totally unrelated… Well, it’s related insofar as it’s number three most unpopular of all time, but the relation ends there. It has nothing to do with Go, it has a lot to do with chocolate.

Alright, so this will probably make me some enemies, but chocolate is kind of nasty. [laughter]

They’re different.

Actually, milk chocolate, like Hershey’s milk chocolate – actually, I don’t know if that’s even American or whatnot… That’s the only chocolate that I like. You know, the stuff that people normally think is good, like the dark chocolates and whatnot - ugh! No.

That Hershey’s chocolate contains no chocolate. Did you know that?

Okay, that’s probably why I like it.

Yeah, I don’t know what it is. I don’t know what it is.

So that was Jon Sabados on episode 174, “The trials and tribulations of testing in Go”, an excellent episode if I do say so. 84% unpopular. People like chocolate, Mat…

No, they do… And he should have known that, really.

He probably did know that, which is why he brought it up.

He did know it; that’s why it’s an unpopular opinion, isn’t it? Yeah, I’ve just realized the format; I’ve just understood it. Yes, interesting… Funny, isn’t it - people are all different. That’s all I’ve got to say on that.

We all have different opinions about foods.

Yeah. We did say that they didn’t have to be about tech… And if I remember, the first ever one was about New York taxis.

That’s right. The bus versus taxis, or something like this.

Yeah. Buses were great, I think.

Yeah. Well, which ones do you like better? Do you like the technology, the Go-related ones, the software world? Or do you like these non sequiturs about chocolate, baseball, taxis?

Yeah, I like all of them. I like them all.

You like them all.

[15:55] Well, you can learn things about the language and different ideas that people are thinking about the language. That was the surprise for me, because I thought it would be much more personal about things like, you know, I like to copy on my computer… I’ll never paste. That’s [unintelligible 00:16:12.02] You learn quirky things about people, where they’re a bit interesting. And you do get that too, in that case… But yeah, I really do enjoy all of them.

Well, this next one was by me… And you were there. This is episode 154, “How Go helped save Healthcare.gov”, which actually became (I think) the most popular episode of the modern era, probably because of this opinion right here. This is what drove everybody to the show. I was actually going for most unpopular of all time; I didn’t expect to come in with 81% unpopular, although I did help the JS Party listeners also vote on that particular poll, just for fun…

I see.

…and that is that JS Party is better than Go Time. You remember this opinion very well, Mat, because I think you were quite convinced, at least for a moment, by my superior logic and wisdom. Here we go.

So I’m not gonna come on a podcast about Go and say that JavaScript is a better programming language; I’m no fool. I wanna walk out of here alive. But. I will happily start out a proxy war by saying that JS Party is a superior podcast to Go Time.

Ooooh…

[laughs] Let me quantify this a bit, okay? I have some evidence. So more is better, okay? We have more panelists, we have more male panelists, we have more female panelists, we have more variety, we play game shows, we host formal debates, we write and rehearse poems, we explain things to each other like we’re five… You guys don’t explain anything to each other like you’re five.

Go Time records on Tuesdays, one of the worst days of the week. JS Party records on Thursdays. Thursday is closer to the weekend; obviously, better. We cover more topics… Go Time is about Go. JS Party is about JavaScript and the web. That’s twice as many things.

That’s cheating. That’s cheating.

That’s twice as many things. We know the web is huge, so… Tons of variety.

You can’t take HTTP to a JS Party. [laughter]

So in review…

See, we did poetry…

…we have more awesome panelists, we have more variety, it’s on a better day… And this is the big finale point. You’re gonna like this one. JS Party has 100% less Mat Ryer, which means we really cut down on those awkward silences. [laughter]

Johnny Boursiquot: Wow…!

That is quite the pitch.

Quite the pitch indeed.

Now, I do have to say that since then we actually have gotten some Mat Ryer on JS Party, so I think my claim has proven out to be false.

Yeah, not 100% now, but still quite good for an SLA. If part of your SLA was not to have me on it, I think you’re still in the nines. You’ve still got a few nines there. I just wanna pick up on one point though… Thursday is no closer to the weekend than Tuesday.

Well, the weekend to come. You don’t look back to the weekend and say “I can’t wait for that that already happened…”

No, but you say “Oh, that was a good weekend.” We remember it in a different way. But it’s just about distance…

Come Tuesday you’re not thinking about last weekend. Come on. You’re thinking about this upcoming weekend, aren’t you?

I don’t know. It depends how good it is.

Fair enough.

But just as far as distance to weekend goes, I just wanted to make that clear. I know that our listeners can be very pedantic.

Unfortunately, 81% of people disagreed with me, but they got me at number four all-time most unpopular opinion. Now, the next one was recently, and this one I think – did you throw up in your mouth a little bit, when Jay Conrod said this?

I think Jay Conrod was doing this serious, like as a personal attack, on air. Do you know what I mean? I feel like it’s got that vibe about it.

[laughs] Yeah, I agree.

Because he knows my position on this. And bear in mind, he wouldn’t say this if he didn’t already know my position on this. That’s the thing that gets me about this one.

I’ve got one. Mat, I’m not sure if you’ll consider this a personal attack or not…

Oh, it’s not gonna be about hairlines, is it?

Johnny Boursiquot: Go! I wanna hear it. [laughs]

My unpopular opinion is that Ctrl+V or Cmd+V (for the Mac users out there) should paste with formatting by default.

[20:08] That is outrageous. That one genuinely [unintelligible 00:54:04.26]

I know, right? And the reason is if you’re pasting within the same doc, like you’re moving a paragraph or something, you definitely wanna keep that formatting. If you’re copying from a different doc in the same app, you probably still do… I know it’s weird when you paste from the web browser and it has formatting you don’t want, but I think it’s better for Ctrl+V to do the same thing wherever you are, every time. I like software that’s simple and not too magical, or at least simple to understand and explain, even if it’s doing something complicated.

I know, right? That’s why I work on modules, too. [laughter] Go is a language – I mean, there are definitely parts of it that are a little too magical for my taste, but Go is a language that values simplicity and explicitness, and that’s why I have bad opinions about pasting.

Yeah. Wow. That one really – I mean, I’ve never been angry before on this…

Are you still angry?

Well, as I say – I mean, come on… This thing is like – this gets me still, every day; I have to paste in this awkward way to try and get rid of the formatting. He does make an interesting point though, about within one doc.

Yeah.

If you’re in a doc and you’re copying and pasting. I actually think it probably does make sense there. But not between apps. If you’re in Safari and you copy some text, why on Earth would you want it to have the exact color that that website happens to have in your document? That will almost never be the case.

Yeah, I just ran into that the other day - I was copying out of Safari in to Keynote, and it was yellow in Safari, so it came into Keynote in yellow. And I’m like “Yo, I just want the text. I don’t want the yellow.”

Yeah, obviously.

I mean, I couldn’t be more against this opinion. I think this is the one that I’m the most against so far.

Yeah.

Well, maybe chocolate is bad - I’m against that one as well… But as you noticed in the clip, Jay did specifically say he knew you were gonna get mad. He doesn’t want you to think this is a personal attack, which of course means that’s exactly what it was.

Well, he knew that he was gonna get to me.

And he got to you. You’re still mad to this moment.

Yeah. Well, again, the lesson here, everybody, is everyone’s different… And you know, sometimes people are just definitely wrong.

[laughs] So there’s your top five most unpopular opinions to date. We also have some runners up that we will just briefly here mention… On episode 167 Ian Lopshire said that he thinks futures have a place in Go. 76% of people disagree with Ian on that point.

One episode 183, Preslav Rachev said that Go needs more magic. I did not expect that to be popular, and it was not. 75% of people disagreed with Preslav on that point, and that actually generated a nice conversation on Twitter about such things… Which we’ll link to, of course, on this episode, so you can go read that conversation. Quite a debate around that point.

And then somehow, Mark Bates got himself onto the show, and on episode 171 he confessed that he doesn’t particularly like bacon, which was also 75% unpopular.

So that is our top five most unpopular opinions… Baseball - the most exciting. Err, hard to read. Chocolate kind of nasty. JS Party is better, and paste with formatting - a default.

Break: [23:42]

Well, switching gears now, let’s switch now to the top five most popular. We’ll do this your way - we’ll work our way up to number one. We’ll do it your way, Mat, just because I’m kind and gracious.

Thank you.

So let’s start at the bottom, also because I get to go first that way… Because hey, I’m back. This one was 83% popular with the crowd.

Okay, so hang on, what does that mean, 83% popular? This means 83% of people agree with you, right?

Correct.

But the segment is Unpopular Opinions… So are you winning or losing?

Well, I’m on both lists, so I both won and lost. These are actually the top five losers, because their opinions are popular, which means they failed to be unpopular.

Yeah, but it’s good to be popular, ain’t it? That’s the thing… This is what I’m struggling with in my understanding this.

[laughs] There’s an old Demetri Martin joke that he says that when you win Employee of the Month, you’re simultaneously a winner and a loser. [unintelligible 00:25:39.22] So here we are, “Successful devs are stubborn.” This was my opinion on episode 167, “The art of reading the docs.”

I kind of stole my own thunder earlier in the show… Because my opinion is that one of the primary traits of successful developers is stubbornness. Not intelligence necessarily, not anything else… Although we can have more than one trait in people; it can happen. But I think that what I’ve seen over the years and what I’ve experienced is the ones that really succeed - and of course, define success… Proficiency in what they’re doing, maybe you reach a level of a CTO, maybe you’re a senior engineer… Whatever it is. Like, you can build apps; you can make it through… It’s that those people are generally stubborn. And maybe that’s not the perfect word to use, but… That refusal to give up until it works. Powering through the docs, like we talked about, or through the source code… The willingness to dive into the source code and say “Nah, I’m not gonna just go eat dinner right now.”

Now, it doesn’t mean it’s always the best trait, but I think it’s there often. “I’m gonna sit here and I’m not leaving till I understand this.” I see that in so many successful engineers that I’ve met over the years, and we’ve interviewed on the shows… The ones that will just keep rewriting that function until it’s good enough; they’re never happy with it being good enough, and they’re gonna keep going until they have the ability to write functions pretty well the first time around, or maybe the second pass. Stubbornness is usually there.

Now, stubbornness causes all sorts of problems, too. It can actually be maladaptive in many circumstances, and make social interactions, and working on a team - all these things can actually cause problems. But I think it’s a virtue in certain cases. When it comes to software development I think that lots of the people I’ve seen who are successful are also stubborn, or persevere, or however you wanna say it in a kinder way. That’s my opinion…

So some of this opinion came out of the work I’ve done in teaching, where I’d find certain students, when they hit that roadbump – because a lot of learning how to achieve things in software is making it through the hurdles and the roadblocks… And certain students would hit a roadblock and they would just tap out. They’re just like “I can’t do this”, and it was over with. And they would never really advance from there. Whereas other students would hit that roadblock and they’re like “I’m just gonna bang my head against this roadblock until it breaks down, and I get through it.” And those are the ones that end up going through and being successful.

I see, yeah. I mean, that does kind of make sense…

[28:04] It does. And I also had an appropriate number of hedges in there, if you listen closely… I didn’t take a hard line; I also recognized how stubbornness can be a problem in teams, and in life… So I think that’s why so many people agreed with me. 83%.

Yeah.

Now, somebody else who did a whole lot of hedging was Carolyn Van Slyck. In fact, behind the scenes, when we create these clips, a lot of the results have a lot to do with things that aren’t necessarily what was said, because not everybody listens to the audio, and a lot of it is like headline creation… And some people do a great job of stating their opinion in a one-liner and then backing it up, and then other people kind of talk in a more fluid sense, and I as the clip creator have to somehow represent that in some sort of a soundbite or a digestible headline… Which can be problematic, because I have misrepresented a few opinions on accident, and I have later had to – what is it called, eat crow?

Yeah.

I don’t know why it’s called that. But yeah, I’ve had to eat crow, and say “Yeah, I really screwed that one up.” So Carolyn Van Slyck’s opinion on a recent episode, “All about Porter”, which was another good one that you’ve put together on episode 184, is the number four most popular Unpopular Opinion of all time, with 84% in agreement with her… And I actually had to work with Carolyn behind the scenes to create the headline, because I had no idea how to say it best without misrepresenting what she was trying to say… And she even created some hedges in the headline, such as putting a question mark at the end and saying “maybe”. And I’m like “Carolyn, this is not gonna be unpopular…” It turns out it wasn’t.

I think new contributors have a superpower that maintainers will never have for a project.

Hm, interesting…

Yeah. Digging into that a little bit… Think of the person who comes up to your project and tells you that it’s wrong; it’s not solving the same problem, or they don’t get it… Just like Johnny giving me a little bit of grief at the beginning of the show, because even though I honestly tried to describe what Porter did, I missed connecting with him, right? And as a maintainer, oftentimes when you get this feedback, your first instinct is to be very defensive and go “Oh…!”

It’s Johnny’s fault.

Yeah, exactly. [unintelligible 00:30:17.18] “Obviously, you’re not doing the advanced, cool things that I’m doing”, or something like that. You never know. But actually, as a maintainer, if you take every single one of those as an honest to goodness truth, you failed to communicate with that person… Example being I have a new user guide, a quickstart that gets them up and running. They run through it and they still don’t get it. That’s on me.

My landing page - someone comes to it, they read about Porter (or anything), and they go “When would I use it?” These are feedback that you can take and go “This is what I was missing”, and you’ll never see that as a maintainer. If you wrote it or you’ve been working for it a long time, if you’re neck-deep in that project, you will never have this perspective, ever. And every single person who’s willing to make themselves vulnerable and tell you that there’s a problem, that they didn’t get it - it doesn’t matter; they may be a jerk about it, but think about that feedback. They wouldn’t have said it unless you had failed in communicating somewhere.

Well, that’s why the Porter documentation is so good… If you have that attitude, then of course. And yes, that’s obviously the very best. You can tell that Carolyn spends a lot of time thinking about that. And it’s a sort of user experience of your API’s or whatever it is that you’ve got at your projects. And it is so important. It’s one of those important things, like writing as a skill even becomes such an important thing for software engineers to have, and it’s worth kind of exploring and practicing, and things… Because yeah, it makes all the difference. If you can onboard people easier, just by spending a bit of time in the writing, and thinking about it really from their point of view, which is this shortcut trick… If you wanna write better documentation, you have to sort of imagine you don’t know anything. If you can work with somebody as well, that also is cool. But Carolyn is right, if they’re new people to the project, their questions are really valuable, because they probably represent lots of other people too, don’t they?

[32:45] Yeah, absolutely. That’s the thing - when you’re receiving bad or negative or jerky feedback, first of all it hurts because it’s on something you’ve poured a lot into; we identify oftentimes with the thing that we created, of course. But for every one person who gives you that feedback, you have to realize there’s probably nine - or maybe 99; I don’t know what the order of magnitude is - happy people that are using it and have never said a word to you.

Fair point. I can see why it was a popular one. 84% popular.

Yeah. Good job, Carolyn… Or bad job, if you’re trying to be unpopular.

We don’t know.

Number three most popular opinion of all times - this comes from Mislav Marohnić. He works at GitHub on their CLI. He was on episode 153, “GitHub’s Go-powered CLI.” He had the opinion that the Go community lacks great GraphQL clients, so let’s take a listen.

I’ll start with a Go-related one, because the other one was not specifically Go-related. A lot of what we were excited to do with the GitHub CLI - so the next iteration after hub - was we wanted to really try out how it feels using the GraphQL version of the GitHub API, which shipped in between. Of course, hub originally has used the REST version, and there was not enough added value into migrating completely to another version of the GraphQL API, so we only did that experiment with GitHub CLI when we eventually started working on it, thinking that that would be this massive win in this new API paradigm, which is supposedly really more powerful… And I’ve found that the exact features of the Go language static typing and compiling, that it’s not actually lent itself well to being a good GraphQL client.

While I’m talking about this, just keep in mind that I’m mostly just talking about an experience of writing in Go a GraphQL client, so something that makes and parses GraphQL requests. I have zero experience of making a GraphQL server in Go, which some of my other colleagues at GitHub have experience with, but I don’t have first-hand experience… So this is not about making a server, which I feel that there is more solid tooling. But when we look at the offering of the different GraphQL clients that are written in Go right now, and mostly used as a de-facto standard when we look at the largest, most prolific projects that are open source right now, if we look at how they make requests, not just to GitHub’s GraphQL API, but to any other, I feel that all of those libraries right now are missing the mark on what makes GraphQL really stand out.

GraphQL is not a query language that wanted to be used by having a pre-generated query, which is always the same per compiled version of an app, and then having different requests come in separately, because they were all statically-generated from maybe a schema, or something like that… GraphQL wanted to first of all allow people to bundle several queries at once, or even several mutations. I don’t think it will allow bundling a query and a mutation acting on the results of those queries; I think that’s decidedly against its design.

[36:04] But it definitely can execute an arbitrary number of queries at the same time, and also an arbitrary number of mutations. So if I wanted to change labels in a hundred GitHub issues in the same request, theoretically I can do that. And I was really excitedly searching for Go tools that allow you to kind of batch up a bunch of queries, and then they all execute transparently over GraphQL. It wasn’t a thing that I was able to find.

There we go.

86% popular.

Yeah, kind of – I agree with that, actually. I’d probably vote for that one being popular. David and I wrote one at Machine Box, which is still used; it’s a client, github.com/machinebox/graphql. It takes this very sort of light approach, for that reason - because the queries are different every time. So you’ve kind of put the queries just in with the strings. It’s part of what you’re doing. But of course, with that you lose type safety that I suppose is what the others are trying to bring… But yeah, it’s an interesting point. Very technical one, wasn’t it?

It was. He also shared another unpopular opinion which we turned into a blog post that got a lot of traction as well. It was a very long opinion, so I didn’t even clip it… But it was that Git is too hard. And he goes into the reasoning for that, which was something to hear from a guy who works for GitHub and has worked on and around Git for so many years… So I’ll link that one up in the show notes as well, for those who wanna read it. Of course, you can listen to that episode if you want both of Mislav’s opinions as well. It was a great conversation around why Go was a great fit for their new CLI, the official GitHub command line interface.

Shall we move on to number two?

Let’s, please.

This one’s kind of funny, because it’s from Kris Brandow, who’s a Go Time panelist… Who has tried really hard to have unpopular Unpopular Opinions. And here he is with the number two most popular Unpopular Opinion of all times. He shared this on episode 157, “The secret life of Gophers”, which was also a GopherCon episode from last year… And that’s that he thinks things that are disadvantages actually become advantages. Let’s take a listen.

Any other unpopular opinions?

I’ve got one…

Hmmm…?

I feel like this actually might be an unpopular opinion… I guess it really depends on who you are, but I think a lot of the things we usually see as disadvantages, especially when it comes to the D&I space, like race, or gender, or sexual orientation - they can actually be advantages in a lot of ways… Say like “Well, you get less things. You don’t get as much of a leg up because you’re a black person within a white and Asian-dominated industry…”, but I see that as like “Oh, well I have to work harder - yes. But then I know how to work harder, so I can just keep working harder.” I have the extra stamina, I have the ability to keep going.

Or as a queer person, people are like “Oh, I would never wanna be queer”, and it’s like “Well, I got to choose my life. I got to sit down and think about and figure out what it was that I wanted my life to be”, and I see that as like a tremendous advantage.

So I think in a lot of ways the things we usually see as disadvantages are more just like differences, and in some cases, as the world changes, they can become advantages.

Well, I love the idea of that being true.

Yeah.

I’m very pleased that that one’s 93% popular.

Kris has gone on to share many unpopular opinions over the last year since he joined the show as a panelist; none have been quite this popular, but none have quite been as unpopular as he had hopes… So I love working with Kris on this, because he’s always like “I think this one’s –” Even that one, he was very positive; he’s like “I think this is gonna be very unpopular”, but no. It turns out no.

[40:01] Yeah. I mean, it just sort of sums Kris up, that sort of spirit; nothing can slow him down. It’s just a sort of great attitude to have; it’s very inspiring. But yeah, it annoys me that we still talk about diversity, that we still have to keep talking about it. It seems to be – maybe it’s one of the things we’ll always have to talk about. It just becomes a part of what we’ll always have to do, for some reason, fighting against some default – I don’t know.

I don’t know. Time will tell. I think it’s gotten better, from my perspective, over the last five years…

I hope so.

What I’d like to see as a trend, which is happening - it’s something that we practice here at Changelog - is instead of bringing on diverse guests to talk about diversity, let’s just bring on awesome, diverse guests to talk about what it is that they’re awesome at, and let’s let that be a thing. And I’m seeing that quite a bit nowadays, so that’s enlightening – or not enlightening; heartening. But like you said, we do need to talk about these things still, and so we still are.

Okay, shall we get to number one? Marcel van Lohuizen - is that how you say his name?

Marcel van Lohuizen…

My apologies, Marcel van Lohuizen.

Yes. Of CUE fame.

Yeah, of CUE fame, talking about CUE, “Configuration superpowers for everyone.” This was on episode 163. 94% popular. Darn near everybody agrees with him when he says that “Inheritance is the biggest source of complexity in configuration languages.” Here it is.

To me, inheritance is the biggest source of complexity in configuration language, and a great evil that should be avoided… Which might sound sensible after everything I have explained today… But it does mean it eliminates most configuration languages as a useful tool. That might be unpopular.

Yeah. Well, I don’t know if it’s gonna be unpopular to Go people, because one of the nice things about Go is you can’t build these complex type hierarchies… And I used to do C#, and honestly, I would build cathedrals, honestly… Beautiful things - generics, generics with various conditions… And then the next day when I’d go to try and look at it, I was like “No. No.” I’d start again.

And Go sort of doesn’t have them, so you can’t tie yourself in knots in the same way. But we’ll see… We do test these unpopular opinions, Marcel, and if you don’t manage to – we actually poll them on Twitter to find out if they are indeed unpopular. And if they’re not, you have to come back on and think of another one.

So it sounds like Marcel needs to come back on the show…

Yeah, because that is the most popular one.

It is, of all time.

Yeah. See, I think sometimes the way that the person pitches it is usually so convincing that when people just hear that clip, it’s like, you can’t help but agree with it. I think it’s a bit of that that happens, which is why a lot of them – it’s quite hard to get an actual unpopular one, isn’t it?

It is. Which is why Kris has put a lot of work into getting unpopular ones, and still he manages to be popular… But he’s also very good at explaining these things, and Marcel did a great job explaining the reasoning why. And I agree. I think if we required clip consumption before voting, I think we’d have even more popular opinions… Because usually, the one-liner can be harsh or outlandish in order to get that unpopular, but then when you hear the explanation, it softens it, it provides context and nuance… And like you said, people describe them very well and you can’t help but agree at the end of the day.

Yeah, they do a great job. And you know, they’re always entertaining, or you learn something, or both… So I’m really pleased that we do these.

So am I, and we do have some runners-up for most popular. On episode 173 Natalie Pistunovich said “If you have a decently-paying job and aren’t in a minority or diversity group, don’t apply for diversity scholarships.” That one was 83% popular, but let’s face it, it probably should have been closer to 100%.

On episode 167 Kris Brandow said “We try to make software engineering look too easy.” 81% of gophers agreed. And on episode 165 Michael Knyszek said “Go’s garbage collector doesn’t need to become generational.” 81% of people agreed.

Break: [44:27]

Next up we have a bunch of generics unpopular opinions… What do you think, should we try to do all of them?

Yeah, let’s go through them quick. Do a lightning round. Lightning generic – what do you mean generic?

Well, they’re opinions about generics.

Oh, I see… [laughter]

Okay, we have three nays and a yay. Let’s start with the positive one… This is Bill Kennedy on episode 172, “Design philosophies.”

I’m a fan of generics. I think that generics are gonna bring some really great things to the language, that we don’t have today, that I’d like to see. Now you can say “Bill, what is that?” I wanna see a package in the standard library that can implement as many of the concurrency patterns that we all have to code ourselves. I think there’s more bugs in Go code today because everybody’s writing their own pooling patterns, fan-outs, other complex things that could be coded by somebody on the language team where you just pass a function or something, and you know that the concurrency pattern is solid. So I’m super excited about that.

The sync.Map - look at the comments around the sync.Map type. You know somebody engineered that to be mechanically sympathetic with the hardware caching system, that you don’t get if you use a regular Go map? Imagine we could put a concrete type to that. I wouldn’t use a regular Go map every again, because if I’m gonna be doing heavy, heavy map stuff, and I’m gonna get the mechanical sympathies of the caching system with that type, and I get to use a concrete type on top of that?

I think you’re golden.

On episode 177, “Building startups with Go” Ramiro Berrelleza said he’s against generics. This opinion split the audience. 51% agreed with Ramiro.

I believe that the whole not having generics is a good thing for Go, and that there’s only one way of doing things is really, really good. Everytime there’s a discussion on introducing another way of dealing with returns, or errors… Like that pattern of if err!= nil, then do that - I know it’s repetitive, but I love it. Going back to what I was talking about earlier, it makes your code a lot more declarative, intent is clearer on why you’re doing things, so that is something that I hope that the people who are working right now in generics - I wish they would not do it. I think now it’s a done deal. But if they do, I hope that we don’t lose on this one way of doing everything; that’s one thing that I love about Go, that when I was coding in Python gave me a lot of trouble. There’s one way of writing to disk, and that’s great; and then everybody follows that pattern. That is something that I hope sticks around for a while.

[48:13] Daniel Marti, who’s one of our frequent guests, is also against generics. Not the feature itself, but the amount of time and money that could have been invested elsewhere. This is from episode 155, titled “What would you remove from Go?”

I’ve got one, and I’m not sure how I feel about it… I think Go as a language is making a mistake by investing so much into generics… Because they’re putting a bunch of very smart people for years and years into generics, how to design them and how to implement them… And if instead you’ve invested those resources in improving the compiler’s support of interfaces, with changes like the one we discussed for 1.16, I think if you covered the common use cases of interfaces and made them faster, I think a lot of these use cases for generics would go away.

That’s an interesting one. Is that popular or unpopular?

It turns out it was 59% popular with Go Time listeners. Last but certainly not least, we have Brian Ketelsen. Brian joined Mat on episode 170 to talk about code generation. He was so excited to share his unpopular opinion he shared it before the segment ever started.

Brian Ketelsen: My favorite is when you have a pattern that you want to apply to a problem set, and you need to do that over and over. You need to treat a particular resource a certain way. And it’s gonna be the same for all the resources. There isn’t exactly a generic way to do it, but it’s such a cookie-cutter approach that you can write some metadata and then use that metadata to introspect the problem domain and then generate code.

Yeah. I’ve used it before I had a data structure, and obviously, Go doesn’t yet have generics, but… I had a data structure – I wanted to support multiple types, and I wrote a little program where I could just give it the array of types that I wanted to support, and it would generate the code for each type. So I got strong types, but I didn’t have to write out every version of it.

I mean, go generate is the only generics we need in Go.

Hm.

You said “Come armed with an unpopular opinion”, there’s mine - we don’t need generics in Go. Generics make Go harder to read, and they’re going to decrease my quality of life as a Go programmer. There’s my unpopular opinion. Tweet that up; put it on Twitter, that’s my unpopular – generics will decrease my quality of life.

That was great.

Yeah.

[51:00] That was like in the first five minutes of the show, I think.

Yeah, that show was a great one. People should listen to the whole thing. He starts the episode with a song.

He does. And he ends it with a song as well.

Yeah. Well, you expect that, but starting it with a song?

Oh, that’s unexpected.

Yeah. That’s amazing. It’s a great episode though.

So one thing I’ve been curious to ask, Mat, is your take on generics. You’ve hosted a lot of people’s opinions… Most recently I think Mark Bates and Johnny both gave opinions on generics, on the mistakes episode that we just shipped I last week or two weeks back… But I never hear you say what you actually think about it. You just kind of host other people’s thoughts. What’s your take on generics in Go?

Well, the reasons that people don’t want it, I get and I agree with. And the reasons that people want it, I get and agree with. So it’s kind of like – I won’t abuse generics because I’ve been burned before, basically. So I’ll be able to (I think) use generics – maybe I will overuse it, who knows, but probably I’ve got a good chance of using it in the right place and in the right way, to solve the right kind of problem. And the thing is, that wasn’t true for me for channels, because I hadn’t had any experience with channels, so I was using them all over the place when I didn’t need to. And that’s an important thing to take into account when we add new features to the language, because there will be lots of people that are new to the language, or that just haven’t had maybe generics before in a language; that’s entirely possible. And it seems like it fits more problems than it really does, I think.

I think it’s just gonna have to be conversation that happens; we have to have talks about it and keep talking as a community, and write blog posts, and do podcasts and talk about it, to figure that stuff out, which we have to do for everything anyway. But I do understand some of the objections to it, but I also see – there are certain problems, the sweet spot, where it’s gonna make the code pretty great, really.

I’ve been quite a big fan of codegen before, and that episode with Brian was talking about code generation (episode 170). So I’ve also had a lot of success with code generation. I quite like that. That’s almost like a developer tool to write the code for you. It’s not part of the CI, it’s not run automatically anywhere. It’s an explicit command you do after you’ve changed some data source… And you’re sort of responsible for the code that gets generated, so you then check that code in.

So that ownership model of generated code I think is very powerful, and you can solve basically any problem you can solve with generics, you can solve with that technique. So for people that have got that technique down, I think they may never use generics, or maybe they will, in the right places, because it makes the code cleaner, or they just wanna do it to try it.

Well said. Thanks for sharing that. Mat, thanks for hanging out and bringing these clips out of your dungeon, with your ornateneness–

Oh yeah, I forgot about that.

…I can’t remember what your little story was.

Yeah, I’ve got a box…

That’s right.

…a really ornate box. I’ll pop them back in, actually.

What are you gonna do with that after we’re done here?

I’ll bury them back in the crypt.

[laughs] Of course.

Where they belong.

Alright, we will see you next time, on… Go Time! Is that how you do it. On… Go Time!

Yeah… Yeah… Why not?! Go Time!