The panel discuss the parts of Go they never use. Do they avoid them because of pain in the past? Were they overused? Did they always end up getting refactoring out? Is there a preferred alternative?

Our “what’s new in Go” correspondent Carl Johnson joins Mat & Johnny to discuss… what’s new in Go 1.20, of course! What’d you expect, an episode about Rust?! That’s preposterous…

Go 1.18 was a major release where we saw the introduction of generics into the language as well as other notables such as fuzzing and workspaces. With Go 1.19 slated to come out next month, one has to wonder what’s next. Are we in store to be blown away by new and major features like we saw in 1.18? Not exactly but there are still lots of improvements to be on the lookout for.

Joining Mat & Johnny to touch on some of the most interesting ones is Carl Johnson, himself a contributor to the 1.19 release.

Here’s a little bonus episode before we get back to your regularly scheduled Go Time. We’re calling it the funny bits. It’s a compilation of times we cracked up making the show for y’all. If you dig it, holler at Jerod. If you don’t, email Mat Ryer.

Carl (Director of Technology for Spotlight PA) and Wayne (Principal Engineer at GoDaddy) join Mat and Mark to talk about the new go:embed feature in Go 1.16. They discuss how and when to use it, common gotchas to watch out for, and some rather meaty unpopular opinions thrown in for good measure.

In a post aptly titled “Tripping over the potholes in too many libraries,” Carl Johnson explains his philosophy on using dependencies.

In short, I think it’s become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet. Their ecosystems make it very very easy to become reliant on this stuff. Trouble is, those libraries are frequently 💩. If something about it is broken, you might not be able to code around it, and may have to actually deal with them to get it fixed. Repeat 100 times, and now you have a real problem brewing.

I have a simple rule: never use a dependency that you could replace with an afternoon of programming.