Opening up the opinion box (Go Time #191) - podcast episode cover

Opening up the opinion box (Go Time #191)

Aug 05, 202156 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Mat Ryer and Jerod Santo sit down to review and discuss the MOST and LEAST unpopular “unpopular opinions” since we started keeping track of such things. Also Generics.

Join the discussion

Changelog++ members save 2 minutes on this episode because they made the ads disappear. Join today!

Sponsors:

  • Teleport – Teleport Access Plane lets you access any computing resource anywhere. Engineers and security teams can unify access to SSH servers, Kubernetes clusters, web applications, and databases across all environments. Try Teleport today in the cloud, self-hosted, or open source at goteleport.com
  • LaunchDarklyShip fast. Rest easy. Deploy code at any time, even if a feature isn’t ready to be released to your users. Wrap code in feature flags to get the safety to test new features and infrastructure in prod without impacting the wrong end users.
  • Equinix Metal – If you want the choice and control of hardware…with low overhead…and the developer experience of the cloud – you need to check out Equinix Metal. Deploy in minutes across 18 global locations, from Silicon Valley to Sydney. Visit metal.equinix.com/justaddmetal and receive $100 credit to play.

Featuring:

Show Notes:

MOST unpopular
  1. Baseball is the most exciting sport in the world (Grant Steltzer on episode #159)
  2. Using err as an error variable make code hard to read (Steve High on episode #179)
  3. Chocolate is nasty (Jon Sabados on episode #174)
  4. JS Party is better than Go Time (Jerod Santo (of course) on episode #154)
  5. Copy/paste with formatting should be default (Jay Conrod on episode #187)
Runners up LEAST unpopular
  1. Inheritance and complexity in configuration languages (Marcel van Lohuizen on episode #163)
  2. Disadvantages can become advantages as the world changes (Kris Brandow on episode #157)
  3. The Go community lacks great GraphQL clients (Mislav Marohnić on episode #153)
  4. Bad feedback better than no feedback from new users (Carolyn Van Slyck on episode #184)
  5. Successful devs are stubborn (83% pop) (Jerod Santo on episode #167)
Runners up Generic Opinions Other thinks mentioned

Something missing or broken? PRs welcome!

Transcript

Transcript for Go Time #191 Mat Ryer:

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.

Jerod Santo:

Right.

Mat Ryer:

And it got quite funny.

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

Exactly. \[laughs\]

Mat Ryer:

"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?

Jerod Santo:

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

Mat Ryer:

Yeah.

Jerod Santo:

\[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.

Mat Ryer:

Yeah.

Jerod Santo:

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

Mat Ryer:

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?

Jerod Santo:

It's quite ornate.

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

Yeah, it's nice, it's nice.

Jerod Santo:

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.

Mat Ryer:

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.

Jerod Santo:

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.

Mat Ryer:

Yeah...

Jerod Santo:

It's getting pretty meta.

Mat Ryer:

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

Jerod Santo:

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.

Grant Seltzer Richman:

Baseball is the by far most exciting sport in the world

Mat Ryer:

Baseball? Which one's that?

Grant Seltzer Richman:

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

Mat Ryer:

The ball. Clue's in the name.

Mat Ryer:

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?

Hana Kim:

So other than U.S. and some Asian countries, who plays baseball?

Mat Ryer:

Yeah, I don't know.

Grant Seltzer Richman:

Latin America?

Hana Kim:

Oh, yeah. And in Europe?

Grant Seltzer Richman:

No, not really.

Jerod Santo:

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

Hana Kim:

But they are missing the best sport, right?

Mat Ryer:

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

Derek Parker:

Best or most exciting? I would refute most exciting. I think football is pretty exciting. I get exciting watching -- I don't know if you consider this a sport, but I like watching poker championships and stuff, and that sounds pretty exciting. It depends on your metric.

Mat Ryer:

I watch Starcraft online, the Starcraft championships.

Derek Parker:

Yeah, there you go.

Mat Ryer:

That's all exciting.

Derek Parker:

Yeah, yeah.

Mat Ryer:

But I just don't go outside, so...

Jerod Santo:

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

Mat Ryer:

Well, it depends...

Jerod Santo:

Well, 95% of people disagreed with Grant...

Mat Ryer:

That's amazing.

Jerod Santo:

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

Mat Ryer:

Well, there we go.

Jerod Santo:

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

Mat Ryer:

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...

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

It is. He's number one.

Mat Ryer:

Yeah.

Jerod Santo:

Number two goes to Steve High.

Mat Ryer:

Should we have done these in the reverse order?

Jerod Santo:

Why reverse order? \[laughter\]

Mat Ryer:

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

Jerod Santo:

No.

Mat Ryer:

Okay. \[laughter\]

Jerod Santo:

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

Mat Ryer:

Okay, fine.

Jerod Santo:

Number two.

Mat Ryer:

Yeah.

Jerod Santo:

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.

Steve High:

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.

Mat Ryer:

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...

Jerod Santo:

Like err1 and err2.

Mat Ryer:

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.

Jerod Santo:

Right.

Mat Ryer:

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.

Jerod Santo:

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.

Mat Ryer:

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.

Jerod Santo:

\[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.

Mat Ryer:

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.

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

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.

Jon Sabados:

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

Angelica Hill:

Chocolate is nasty?! Well, I have one thing to say about that - you mean American chocolate is nasty... Because I'm sorry, but British chocolate is on point.

Mat Ryer:

They're different.

Angelica Hill:

Yeah.

Jon Sabados:

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.

Mat Ryer:

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

Jon Sabados:

Okay, that's probably why I like it.

Mat Ryer:

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

Jerod Santo:

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...

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

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.

Jerod Santo:

We all have different opinions about foods.

Mat Ryer:

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.

Jerod Santo:

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

Mat Ryer:

Yeah. Buses were great, I think.

Jerod Santo:

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?

Mat Ryer:

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

Jerod Santo:

You like them all.

Mat Ryer:

\[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.

Jerod Santo:

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...

Mat Ryer:

I see.

Jerod Santo:

...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.

Jerod Santo:

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.

Mat Ryer:

Ooooh...

Johnny Boursiquot:

You're off our show. You're off our show.

Jerod Santo:

\[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.

Mat Ryer:

That's cheating. That's cheating.

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

So in review...

Mat Ryer:

See, we did poetry...

Jerod Santo:

...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...!

Mat Ryer:

That is quite the pitch.

Mat Ryer:

Quite the pitch indeed.

Jerod Santo:

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.

Mat Ryer:

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.

Jerod Santo:

Well, the weekend to come. You don't look back to the weekend and say "I can't wait for that that already happened..."

Mat Ryer:

No, but you say "Oh, that was a good weekend." We remember it in a different way. But it's just about distance...

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

Fair enough.

Mat Ryer:

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.

Jerod Santo:

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?

Mat Ryer:

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.

Jerod Santo:

\[laughs\] Yeah, I agree.

Mat Ryer:

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.

Jay Conrod:

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

Mat Ryer:

Oh, it's not gonna be about hairlines, is it? Johnny Boursiquot: Go! I wanna hear it. \[laughs\]

Jay Conrod:

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

Mat Ryer:

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

Jay Conrod:

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.

Johnny Boursiquot:

Yeah, that's why you work on fuzzing. \[laughter\]

Jay Conrod:

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.

Mat Ryer:

Yeah. Wow. That one really -- I mean, I've never been angry before on this...

Jerod Santo:

Are you still angry?

Mat Ryer:

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.

Jerod Santo:

Yeah.

Mat Ryer:

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.

Jerod Santo:

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."

Mat Ryer:

Yeah, obviously.

Jerod Santo:

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

Mat Ryer:

Yeah.

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

\[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\]

Jerod Santo:

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.

Mat Ryer:

Thank you.

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

Correct.

Mat Ryer:

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

Jerod Santo:

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.

Mat Ryer:

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.

Jerod Santo:

\[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."

Jerod Santo:

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...

Jerod Santo:

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.

Mat Ryer:

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

Jerod Santo:

\[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%.

Mat Ryer:

Yeah.

Jerod Santo:

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?

Mat Ryer:

Yeah.

Jerod Santo:

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.

Carolyn Van Slyck:

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

Mat Ryer:

Hm, interesting...

Carolyn Van Slyck:

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...!"

Mat Ryer:

It's Johnny's fault.

Carolyn Van Slyck:

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.

Mat Ryer:

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?

Jerod Santo:

\[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.

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

We don't know.

Jerod Santo:

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.

Mislav Marohnić:

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.

Mat Ryer:

There we go.

Jerod Santo:

86% popular.

Mat Ryer:

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?

Jerod Santo:

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?

Mat Ryer:

Let's, please.

Jerod Santo:

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.

Mat Ryer:

Any other unpopular opinions?

Kris Brandow:

I've got one...

Mat Ryer:

Hmmm...?

Kris Brandow:

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.

Mat Ryer:

Well, I love the idea of that being true.

Jerod Santo:

Yeah.

Mat Ryer:

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

Jerod Santo:

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.

Mat Ryer:

\[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.

Jerod Santo:

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

Mat Ryer:

I hope so.

Jerod Santo:

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?

Mat Ryer:

Marcel van Lohuizen...

Jerod Santo:

My apologies, Marcel van Lohuizen.

Mat Ryer:

Yes. Of CUE fame.

Jerod Santo:

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.

Marcel van Lohuizen:

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.

Mat Ryer:

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.

Jerod Santo:

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

Mat Ryer:

Yeah, because that is the most popular one.

Jerod Santo:

It is, of all time.

Mat Ryer:

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?

Jerod Santo:

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.

Mat Ryer:

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.

Jerod Santo:

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\]

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

Well, they're opinions about generics.

Mat Ryer:

Oh, I see... \[laughter\]

Jerod Santo:

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

Bill Kennedy:

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?

Johnny Boursiquot:

Golden.

Bill Kennedy:

I think you're golden.

Jerod Santo:

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

Ramiro Berrelleza:

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.

Jerod Santo:

\[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?"

Daniel Martí:

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.

Mat Ryer:

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

Jerod Santo:

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.

Mat Ryer:

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.

Brian Ketelsen:

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

Mat Ryer:

Hm.

Jon Calhoun:

Oh, boy. We're already starting that.

Brian Ketelsen:

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.

Jerod Santo:

That was great.

Mat Ryer:

Yeah.

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

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

Jerod Santo:

Oh, that's unexpected.

Mat Ryer:

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

Jerod Santo:

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?

Mat Ryer:

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.

Jerod Santo:

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

Mat Ryer:

Oh yeah, I forgot about that.

Jerod Santo:

...I can't remember what your little story was.

Mat Ryer:

Yeah, I've got a box...

Jerod Santo:

That's right.

Mat Ryer:

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

Jerod Santo:

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

Mat Ryer:

I'll bury them back in the crypt.

Jerod Santo:

\[laughs\] Of course.

Mat Ryer:

Where they belong.

Jerod Santo:

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

Mat Ryer:

Yeah... Yeah... Why not?! Go Time!

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android