Kate:
Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. With me today is Johnny Boursiquot. Hi, Johnny. How's it going?

Johnny Boursiquot:
It goes, it goes. Happy to be here.

Kate:
And a lot of our listeners have probably heard Johnny's voice. He is on the Go Time FM podcast. I know I have heard your voice a lot. Thanks for joining us.

Johnny Boursiquot:
Happy to be here.

Kate:
And then Paul, our engineer at LogRocket. Hi, Paul, how's it going?

Paul:
Good. Happy to be here.

Kate:
Thanks for joining. Yeah. So, today we want to talk about all things Go. So, Paul, do you want to take it away?

Paul:
Yeah, absolutely. So, why don't we start with how you got into Go? Why did it peak your interest? I don't know, there's so many languages out there, why Go?

Johnny Boursiquot:
That is true. There is no shortage of the languages to pick from these days. Go... Let me see. I came in to Go when I was doing... At the time, when I was doing a lot of Ruby development. So, I had gotten comfortable and used to sort of the nice expressive way of doing Ruby and there were a dozen different ways to do any one thing. So, these days, I think that's more of a con than a pro, but I digress. Basically, I had gotten comfortable. I think part of it was I was for the next challenge, professionally. I used to pick up, generally, a new programming language every one or two years, just to keep myself always learning, that kind of thing.

Johnny Boursiquot:
And I had gotten comfortable with Ruby for three years prior to that. And I was ready for my next language. And then, I saw a Go and a friend of mine, who also is very prominent in the Ruby community, or at least he was at the time, he's also doing Go now. He said, "Hey, check out Go. You might actually like it." And the first thing that jumped out, it's like, "Okay, I left the statically typed programming language world prior to jumping into Ruby." And I like my dynamic types. I like being able to work without types and not constrain myself. Because sometimes I'm experimenting, I just want... I can't worry about the type safety concerns.

Paul:
Absolutely. Gives you a creative freedom. You can jump right into an idea.

Johnny Boursiquot:
Exactly. And when I saw Go, I was like, "Okay. This is going to be a change from what I've gotten comfortable with." But the moment I started playing around with it, it felt like I was... It was the first statically type programming language that I used with a compiler that didn't take a long time to compile my code. It felt like the feedback cycle from the time I wrote the code to the time I said, "Okay, Go build." Or, "Go run." The feedback cycle was so quick that I was like, "This feels like I'm scripting a little bit." This doesn't feel like when I do Java or when I do C or something like that where, depending on the size of the program, it might take a while before I get that feedback.

Johnny Boursiquot:
This actually can feel more like scripting, right? So, I started playing around with it. I started building command line tools with it. Something it's very, very good at, by the way. And I mean, from that point on, I was hooked. Any chance I got to use Go on any project on any team, I'd start using it. And sooner or later, other people around me started getting curious, "What is this language you're using?" I'd sneak it into companies I worked at and stuff like that. And sooner than later people started picking up on it as well. I'm like, "Okay. There's something here."

Paul:
Planting seeds.

Johnny Boursiquot:
Exactly. Yeah. And this was back in maybe 2013, 2014. Yeah. So, it's been a minute.

Paul:
Yeah. So, do you think the adopt goes good for teams because of its modularity? Or because of how easy it can be to get into if you are in the right mindset? Because that's one thing with JavaScript. It's modules everywhere. If you're using notes, it's big plugs. So, that's why I relate that as a strength for JavaScript for teams. Where does Go fit in there?

Johnny Boursiquot:
So, over the course of my career, which I'm grateful I'm running, I'm coming up on... Have been like 25 plus years, now. I've been on many teams over the years and worked at lots of different companies of different shapes and sizes. And I've gotten to experience what happens when you bring teams up on new technology or where are the stumbling blocks? Where do they struggle? Where do they excel? And Go was the first language where the code that a newbie developer and also a developer who's experienced, but doing Go for the first time. Two different approaches, two different style of design and thinking through code.

Johnny Boursiquot:
But even though you had these different experience levels, these different competency levels with the language, I could look at Go code. If I have a newbie developer who is actually writing Go code in an idiomatic way. Idiomatic being like, "Okay. These are the ways we write Go code." You can write Go code that doesn't quite look like Go code and we'll get into that a little later.

Johnny Boursiquot:
But if I'm following the community idioms, whether I'm an experienced developer who's been writing Go for five years or more, or I'm a new developer who's mastered the idioms but I'm still learning. I'm still wrapping my head around everything Go can do for me. Sometimes it's almost indistinguishable whose code you're looking at. But part of that is because Go has been written in a way... Go development is done in such a way that it's the same approach, the same style. It's the same approach. The air handling is done in a very similar way.

Johnny Boursiquot:
I alluded to this earlier. In Ruby, there's half a dozen ways to do any one thing and Go there are much fewer. When you read that code, whether a newbie or an experienced, you can actually just make sense of it. So, that was one of the key things that I saw with teams adopting Go. That everybody got to be productive very, very quickly. I didn't wait for somebody to be experienced for a year or two or three years before they started producing good Go code. I can get somebody trained up in three or four months and then they'll be just as effective as somebody who's been doing it for a year or two.

Paul:
What would you say are some of those higher reaching things that Go helps bring down for new developers?

Johnny Boursiquot:
One of the biggest things you run across, especially if you come from a scripting world, such as Python and Ruby and whatnot, where dealing with concurrency, you have to jump through hoops. You have concurrent Ruby programs, concurrent Python programs. I don't know how much that has changed over the years. And I haven't been in that community for too long, but trying to scale such programs through concurrent processes or threads or whatever, fibers, whatever mechanism these different technologies have, it's a much higher barrier to entry right than it is in the world of Go.

Johnny Boursiquot:
In the world of Go, the concurrency [inaudible 00:07:56] are built into the language. I don't have to have a separate framework. Once you understand some fundamental concepts, it's easier, in my opinion, to start doing concurrent Go, than it is to try and get the same benefits coming from a dynamic programming language environment. Again, there are [inaudible 00:08:16] that make that process a little easier, you don't have to fiddle with the bits too much. But when you're writing Go, you're not going through a framework. You're not going through a black box.

Johnny Boursiquot:
You have your Go routines and you're invoking functions with a Go keyword. You have communication and synchronization that happens between Go routines with the same set of keywords. Your selects, your channels and interacting back and forth between those different threads of execution. So, the primitives are all part of the language and they're right there for you to use. So, once you wrap your head around... If you've never done multi target programming and you start doing it in Go, or if you've done it in other programming languages and you come in, start to do it in Go, it's a breath of fresh air. You're like, "Oh, my goodness, this is..." It makes it accessible. It makes concurrency accessible to those who are still learning.

Paul:
And concurrency is usually this big black box of magic that everybody puts their toe into and very few come out-

Johnny Boursiquot:
Unscaped.

Paul:
Yeah.

Johnny Boursiquot:
Exactly.

Paul:
Unless you really know what you're doing.

Johnny Boursiquot:
Yeah.

Paul:
Yeah. I mean, that sounds very enticing to me, also coming from having written very concurrent programs that should not have been in Python. So, that sounds great. That sounds really good. So, one other language I'm sure that you heard about is Rust. And these are both system languages. So, can you give us the quick elevator speech on your differences in your mind?

Johnny Boursiquot:
So, I must preface my insert with the notion that even though Go was, I think way back in the day, originally presented as a systems language, I'd argue that today is much less the case. Yes. You could write low level system software with Go, but if given a choice between doing so in Rust or in Go, I would prefer to write a low level systems... Writing an operating system, for example, I would not pick Go to do that with, I would pick Rust, because of the way it deals with memory and the borrower checker and all those things that it gives you out of the box to make sure you're writing really safe and secure programs. I would rather use that tool for that job than use Go.

Johnny Boursiquot:
Where Go shines is in dealing with anything at the network layer and above. So, anytime you have to have services talk to each other over TCP, exchanging packets and things like that. Or anytime you have to write a service that talks to another service, to be with gRPC or you're talking in plain HTTP, or you need a long list services within your infrastructure that are quick to deploy, quick to build, quick to manage and operate from an SRE standpoint, really, I think the network application world is really where it Go does brilliantly.

Johnny Boursiquot:
Things like writing a message key use, even some databases are built in Go. Yeah. Kubernetes' the poster child for Go, I would say. That is really where it shines. So, in that sense, the old adage of use the right tool for the job kind of thing. In our space, I think, is really [inaudible 00:11:38] there for these two different languages. I think they have a place for each one of them.

Paul:
I feel like that's the most satisfying answer I've gotten for that question. It really helps distinguish them between... They're both system languages with different features. That puts them in the same weird box. So, yeah. If we could consider Rust more systems and Go, network layer and up, that's where it shines.

Johnny Boursiquot:
Yeah.

Paul:
Cool.

Johnny Boursiquot:
Absolutely.

Paul:
So, one thing I think about that I love about Rust is it's a systems language, but when you use it, you could do functional style stuff. You can do these maps and all that stuff. And I would love to know what you think about function as a service style applications. Because I don't know what those are, but when I saw that you were into that, I was thinking, "Wow, that sounds like functional programming." So, am I completely off when I think about that?

Johnny Boursiquot:
Interesting enough, you're not completely off, but depending on the context. It's important to pull on the different threads, the nuance a little bit. So, in the functional programming sense, you can do... To some degree, you can do functional programming style coding with Go. Functions are first class citizens. Where you might run into trouble is some optimization, tail optimization. Go is not really designed for that style programming. It's more along the lines of the imperative style where it's very C like.

Johnny Boursiquot:
So, it's never going to compete with true functional programming languages. It's not built and optimized for that. Now, if we go much higher up the stack where we start talking about functions as a service, as you mentioned. That's a completely different world, even though you're dealing at the unit level of a function, which could be an entry point for triggering a whole bunch of other things. When we talk about functions, even though these things are supposed to be small, I've seen very large functions that run as a service environment. I've seen entire Java applications packaged up as what's supposed to be a very small thing. But again, I digress.

Johnny Boursiquot:
But in the, quote unquote, serverless world, where functions as a service dominates and that's the thing. You create those functions and you deploy them and you invoke them when you need them. And when they're not running, they're tucked away somewhere. You don't pay for them to run. The next time you need to use them, you invoke them. Whether it's some event that happens within your infrastructure, or you are using some API gateway to trigger those functions to wake up.

Johnny Boursiquot:
So, there's a part of the infrastructure where there's some operational aspects where something is going to grab your code, put it on the container, spin up that container and make sure it's secure and it doesn't have access to what it shouldn't have access to and nothing can peer into it in these operational concerns. And then, it basically control, then it gets handed over to your code, which basically is your function, it's your executable. It's a Go executable, since you're talking about Go.

Johnny Boursiquot:
And then basically, whatever data is sent in to as input, gets handed over to your application, it does its thing, sends back a result. That infrastructure takes you out, sends you that result back to whatever client needs it. And then, your function, your code, gets tucked away again. Gets put away again until the next time it's invoked. So, that whole world of function as a service and serverless and that kind of thing, and you have those with every cloud vendor, Azure and GCP and AWS.

Paul:
It's like Lambda, right?

Johnny Boursiquot:
Yeah. Exactly. [inaudible 00:15:31] of name for Lambda and you have cloud functions and et cetera. Yeah. So, those are slightly different context and explanations for the functions argument.

Paul:
Got you. So, why don't we pivot a little bit from strictly talking about Go and talk about what you did at Heroku and your experience at Heroku. So, maybe tell us when you started there and the first projects you started working on?

Johnny Boursiquot:
Yeah. So, I joined Heroku two years and... Wow. I think it's nine months or something, now. So, yeah. I've been there for a little while. And it's been a wild ride. Heroku, as you know, and probably a lot of your audience will know is loved by all. It's one of those foundational services. It's been around for forever. It makes it super easy for developers to just throw something up and quickly ideate on something and get an MVP out the door and build their business or run things for companies. I mean, it tries to encapsulate and make it very easy to just run your software in the cloud with as little ceremony as possible.

Johnny Boursiquot:
Which is very different from trying to role your own Heroku thing. A platform as a service, which is the category of a cloud software that Heroku falls into, PaaS. Trying to create your own platform as a service on top of things like Kubernetes. Whereby, you might try to replicate the same developer experience, internally, at your company or something like that, if you're big enough. Basically, trying to replicate that experience, which is what I think a lot of people try to do these days. They try to replicate Heroku, a developer experience, on top of their own infrastructure, where they've orchestrated things in Kubernetes. And they're finding that it's very, very hard to do.

Johnny Boursiquot:
Heroku has had many, many years to perfect that whole thing. And we are exceedingly good at it. So, when people try to do the same thing and they find out, "Okay, this is not as easy as it looks." So, going into that world where I was a customer of Heroku, even before I started working on Heroku, was a dream come true. And it was like, "Man, now I get to see how the sausage is made. I get to see how all these things are put together." And I'll tell you, it is a magical world of... I mean, today you talk about microservices and everything and that became popular at some point. I don't know if it's popular anymore or people have moved on to whatever the new hotness is, maybe blockchain or something.

Johnny Boursiquot:
But I mean, Heroku has a true microservices environment where you have so many components doing a very specific job, and all of them are talking together and exchanging messages and information to make the magic of using Heroku happen. And it is truly like something I've never seen before. It is quite a wonder, technical wonder, to marvel. And my part in it when I joined, I joined as a site reliability engineer, it's a way of basically... Because SRE is going to... You'll find that different companies use the term SRE to mean slightly different things, depending on where they are and the maturity spectrum for their operations. When I joined as an SRE, basically I was going there to solve a very specific set of problems with regards to adoption of SRE practices, because Heroku basically predates the whole term That whole notion of SRE, it predates all these things.

Johnny Boursiquot:
And Heroku's been around for ages, surely they got SRE by some other name, surely they had it right, they got it right. Otherwise, they wouldn't be in business. So, my job was to go in and basically say, "Hey, I'm going to come slap the big blue book from Google at you and say, 'Hey, this is how we do SRE. We're going to change all the things.'" That was very humbling. When I went in there, I'm like, "Wow, these people know what they're doing." My job, as an SRE, is going to be to identify the areas of where we can improve some things. Where we can reduce some latency in this thing because of some operational process that was designed a few years ago.

Johnny Boursiquot:
And now, some updates have been made and we need to identify where those friction points are and grease the wheels a little bit, make this thing a little faster. Or maybe we have some written processes and procedures that have fallen out date. And whoever was in charge of them, whatever team owned that process or set of services, maybe they've moved on, maybe they got re-allocated and sometimes people leave companies and things. So, my job was to, basically, make sure that the center of excellence that we have at Heroku basically continued to be excellent. So, basically providing my input where it made sense and improving things where it made sense. Not really to blow the whole thing up and start over, really, to identify areas of improvement.

Johnny Boursiquot:
And I learned a ton from that experience. And that actually led to me writing some articles about it, presenting at QCon, I think, was that last year? Man, the pandemic's throwing my time thing. Yeah. I'm super grateful I had the opportunity to talk to a QCon audience about my experience there. And it's been an incredible journey. These days, I'm doing more observability work. Right now, I'm in a platform observability team where basically... Again, this is a continuation of that SRE journey that I've been on at Heroku.

Johnny Boursiquot:
Whereby, now I'm identifying... My team and I, we're trying to provide teams visibility into every nook and cranny of the platform. Identify where the bottlenecks are, identify where there's room for improvement. Setting up SLO's for certain things, making sure that we're delivering the best possible experience for our customers. So, it's a continuation and man, that spectrum... There's so much to do every day, it's amazing.

Paul:
You really must got to be intimately familiar with how the bones of the system [crosstalk 00:21:48].

Johnny Boursiquot:
Not even close. I mean, Heroku is a giant machine of [inaudible 00:21:54] parts. And if I'm lucky, on any given day, I may interact with one, two, at best three pieces of this giant machine. There are a lot of things that work like clockwork to bring the experience that we bring. And sometimes, we don't get it right. [inaudible 00:22:11] just still happen. Or when AWS is having problems, sometimes that cascades and then we have issues too.

Johnny Boursiquot:
So, a lot of times something happen because of the primitives that we run our software services on top of. Other times, it's internal processes that need to be improved for us to catch a particular problem that we didn't anticipate. Or a NOB we need to tweak here because there's more pressure on this service than we anticipated. Now, we need to throw more hardware added or something like that. So, it's basically identifying, as the truck is rolling down the highway, trying to figure out, "Okay. Which tire needs more air pressure? Which tire completely blew off? Now, we got to replace it." As the truck is rolling down the highway kind of thing. So, it's an amazing journey.

Paul:
So, you're really having a good time and you're learning a lot.

Johnny Boursiquot:
I am learning a lot. Every day there is something new to learn and my team, they tolerate me asking all kinds of silly questions and saying, "Where do I find this thing?" And they're very gently and say, "Oh, yeah. This is the thing you worked on last week that connects to this and this and that." I'm like, "Oh, okay. I get it." So, I'm learning a ton every day.

Paul:
Nice.

Kate:
So, I'm going to talk more about the community stuff. So, I actually just listened to a Go Time FM episode. You were talking about where you created a meetup in Baltimore when there was already a meetup and they merged together. I guess I'm curious, what does that meetup look like? And what do you have planned for the future?

Johnny Boursiquot:
So, the meetup story. Me and meetups, we have an interesting relationship. Back in Boston, and this was the Boston meetup, by the way that. I started the Go meetup in Boston and come to find out that there was one. Well, I did my research. I'm like, "Okay." I'm looking around. This was... I can't even remember, this is a long ago. But I'm looking around and saying, "Hey, I want to meet other people who are also enthusiasts of Go. Where do I go to do that?"

Johnny Boursiquot:
And I couldn't find any active boards or meetups or anything like that. So, I'm like, "Okay." I found one, but it hadn't had a meeting in, I don't know, eight months or something, I'm like, "Okay, fine. I'm just going to start one." I started one. And then, within about, I don't know, a month or two, I heard from somebody, the organizer of the other meetup that was seemingly dormant. And he is like, "Hey, we had a meetup." I'm like, "Oh, okay. Cool." I'm like, "Well, I'm not going to shut mine down because yours was inactive." So, how about we team up and revive this whole thing and get it going again? And that's what we did.

Johnny Boursiquot:
We got together and we create a game plan for what I'm going to do, how we're going to have talks and speakers and things. And at the time, the Go community was actually quite smaller, relatively speaking, to what it is now. And there weren't a ton of people who could give talks about Go and things. The first GopherCon, which is our big industry conference, hadn't even occurred yet. It hadn't even happened yet. So, it was still very early days. And basically, we were like, "Okay. Well, let's still get enthusiasts together and talk about Go." And that's exactly what we did.

Johnny Boursiquot:
And fast forward a few years, I relocate from Boston down to the Washington DC Metro area, where I currently reside. And my closest Metro area is Baltimore. And there was no Go meet up there either. I found some for JavaScript. I found some for Ruby, all the other languages and stuff in communities I was familiar with, but there was nothing for Go. And I was like, "Okay. Then I guess I'm going to start one here, too." So, I did. And it's been five years. Yeah. It's been five plus years now and we still keep it going.

Johnny Boursiquot:
The pandemic definitely changed our approach to running these meetups. It used to be that in the first [inaudible 00:26:34] of every month, we had 10, 12 people at a minimum show up and we'd talk about, in the same room together and everything. Gosh, I can't remember last time we did that. And we'd talk Go. And whenever we didn't have speakers, I'd go up there and say, "Hey, this is the code I've been working on. Anybody care to ask questions?" So, I started making it something... Especially for new speakers, which is something that's important to me.

Johnny Boursiquot:
A lot of times you go to meetups or you go to conferences or you attend online events. It's always the same set of people. If you spend six months to a year within a technology community, you're always going to find it's the same set of people producing most of the content. It's the same faces you see at the podium. It's the same faces you see creating YouTube videos. It's the same group of people. And I'm like-

Kate:
On podcasts. Yeah.

Johnny Boursiquot:
And podcasts and things. As I said, I'm realizing, "Okay. I'm one of those same faces." So, I'm like, "This is a problem." So, I'm like, "Okay. We need fresh blood. How do we get fresh blood into the community? How do we get more voices? How do we get diversity of opinions and approaches and things like that?" And to me, basically creating an opportunity within the meetup context, that says, "Hey, if you'd like to give a talk, I will sit down with you and I will help you come up with a talk. If you have fear and hesitation and trepidation and you don't want to go up there, even if it's in front of your 10 closest peers or whatever it is, we will get through this together. I will help you fashion something. And it doesn't have to be long. It can be five minutes, 10 minutes, 15 minutes. And you can work your way up to a conference talk."

Johnny Boursiquot:
And we were successful with that model. We'd have a combination of talks, a beginner oriented and a more advanced talk every time we got together and met. And it's been a very rewarding experience, both when I did it in Boston and when I'm doing it now in Baltimore. Obviously, the challenges of the pandemic have made attendance in these things... As a meetup organizer, you're going to run across these things. Some months attendance is high, some it's low. But you ride that wave. And leading up to conferences like GopherCon, I mentioned earlier, is the big [inaudible 00:29:00] we used to have it Denver. I think, recently it was online. The last two years it's been online. Obviously, again, because of the pandemic, that pandemic.

Johnny Boursiquot:
Helping people. As a chair of that conference, finding the speakers, giving people who've never spoken before an opportunity to get in front of a large audience and speak and things. So, this ties into my personal mission within the Go community, which has always been to try and open doors for people. Try and open doors for those that are new to the language, new to the community. Trying to make it a welcoming environment. That if you are interested in this technology, that you are going to find people that are helpful and welcoming. It's not like going on SAC [inaudible 00:29:46] question, somebody comes in and slaps you in the wrist, "Why did you not read the docs?" Or something like that. So, basically, trying to take a slightly different approach and trying to make it a bit more welcoming of an environment, which is something that's definitely important to me.

Paul:
Making the social engagement is awesome. The best way to learn programming is just sitting down with somebody and talking.

Johnny Boursiquot:
Yeah.

Paul:
I feel like it's very common for learning languages. I know I do. You sit in the chair by yourself and you just read stuff. But yeah, going to a conference sounds awesome. I've never been to a programming conference. I got to check yours out when it comes by. Yeah.

Johnny Boursiquot:
Yeah. You got to do it. I mean, to me, you can pick up a new technology and sit down and learn it and read the docs or whatever it is, and become effective. Heck, even become great at it. But you're missing out if you're not connecting with other people. Because we don't do things [inaudible 00:30:40]. At least I'd like to think that most of us prefer not to be isolated, in one way or another, with the greater community in which we are attached through these technologies.

Johnny Boursiquot:
So, I think a lot of times it's the hesitation that comes from basically... Maybe you were part of a community before, and maybe you raised your hand and somebody slapped your wrist down because you asked a, quote unquote, stupid question or something like that. Or maybe you went to a conference and you were in the corner, a little timid and nobody came in and approached you and said, "Hey, how are you doing? Welcome. I'm Johnny, what's your name? What do you do for a living?" Things like that.

Johnny Boursiquot:
So, to me, I place an emphasis on that level of detail. To me, it's going to a conference or going to a meetup, even if I'm not the organizer or whatever it is, it's going there and trying to spot, "Okay. Who's shy, who's timid, who has taken a huge leap and actually being present and in the room but needs a hand, needs a little bit extra help to more fully ingrain themselves as part of the community. Who are those people? Who can I talk to and make feel welcome here?"

Johnny Boursiquot:
So, to me, these are the things that matter, because at the end of the day... I have friends that cross technological boundaries. I have friends from the Ruby world. I have friends in Java world. I've nurtured and kept those relationships because it's always been about the people, not about the tech. Over the course of your career, you will do more than JavaScript. You'll do more than Ruby, more than Python, whatever the next hotness is.

Johnny Boursiquot:
If you happen to be as lucky as I am and have a 25 plus year career, you will use a lot of different technologies. But the relationships, the people you meet along the way, those relationships you invest in, you got to do it. Which is why you got to go to a conference, man. You got to show up and mingle and get to know people. You got to do that stuff.

Kate:
Especially the GopherCon because they have a gopher. I love that. I love that branding. Yeah

Johnny Boursiquot:
Yeah. Gopher plushies and all that stuff. You can get one of those, those are cute. Those are always a hit, especially around kids. My kids love those things.

Kate:
Awesome. I guess one more question before we go. I'm curious... So, I know Go has come up, when we're coming up with topics for our blog, podcast. It seems like that list is getting longer each year. And when we ask our engineers, is this a good topic? Everyone's like, "Oh, this looks awesome. I need to check it out." Growing this meetup, this community, do you feel like getting bigger and more popular? Or is that just because I'm on the outside?

Johnny Boursiquot:
Are you saying in terms of the sheer volume of content available now for people to learn?

Kate:
Yeah. Just content and I guess projects specifically.

Johnny Boursiquot:
Well, certainly there is no shortage of projects born every day, within this community. And obviously, that's a good sign of a thriving community. You have more people coming in, more adoption and lots of different ideas, that those of us who've been doing it for a while, are probably busy with our day jobs and things. And a lot of people are coming in with brand new ideas and fresh ideas and implementations and I'm like, "Okay." I have a Google alert for the word Golang. So, anytime, anything Golang shows up, I get an email about it. And I see a lot of blog posts, a lot of articles, a lot of people talking about, "Hey, Go's great for this, Go's great for that." Whatever it is.

Johnny Boursiquot:
So, I get to see a lot of that stuff come in. Maybe I'm a [inaudible 00:34:37] of punishment. I'm getting all those emails, I'm going through all those things. But this is my way of keeping a pulse on the thriving community and how much it's grown over the years. And know that you mentioned it, one of the things that newbies to the Go community find intimidating is, as you say, the sheer volume of projects and content and learning that they feel like they have to do because there's just so much out there. Six, seven years ago, I didn't have that problem because there was a handful of reliable sources I could go to to learn.

Johnny Boursiquot:
Other than reading the documentation, reading the spec, whatever it is, reading the docs on golang.org, that was enough to get me going. But these days you come in and there's YouTube channels, there's free code camps, there's this and that. It's just so much stuff. And it's like, "Okay. Where do I start?" And I get folks in my Twitter DM's, virtually every week, saying, "Hey, thanks for the podcast. I came across you on the podcast." Or something like that. "Oh, you gave a talk at this and thank you so much." Or whatever it is. "I know there's a lot of stuff out there and I know I shouldn't be coming to you and asking, where do I start? Because there's so many things out there." But it is that very thing that has made it intimidating to get started.

Johnny Boursiquot:
Getting started is always the hard part because you don't know where to get started because there's so much stuff out there as a beginner. So, if you are a beginner and this is me speaking to your audience, if you are a beginner and you do want to get into Go development, I'd say the first place to go is to go to Go.dev. That's going to give you a starting place. That's going to give you a sense of, "Okay. This is what the language is like." It's going to link you off to the Go tour, it's going to link you off to some material, popular bloggers and I think it even links to some YouTube channels or something like that.

Johnny Boursiquot:
But it'll also link you to a ton of books that you can get through. And again, the books can be intimidating. The way I learn anything is a mixture of books, YouTube videos, blog posts, and I'm jumping between all of them. I've never started and finished a book, completely front to back in Go and any other tech. I'll read the first chapter, try some code, go watch a YouTube video, find another blog post, go to stack overflow. I'm bouncing all over the place because any one medium for too long and I get bored and I need something, I need a different way to consume the material. So, if you're in that boat, there's nothing wrong with you. That's just the way we learn. We learn a little differently.

Johnny Boursiquot:
So, the idea is that you have that as a starting point. And then, once you bounce around a little bit, don't try to make sense of it all at first. Just get a feel for the different places you can go and learn and Go. But once you're ready to take a leap now, find... On the Golang website, there's an article called Effective Go. Read that first, okay? And then, once you're done reading that, you need to start actually writing a little bit of Go code. There's another site called gobyexample.org, or is it .com? Something like that, search Google or something like that or Bing, whatever your free search engineer is.

Johnny Boursiquot:
And Go by example, you're going to come across that site. It's going to give you a list, a nice long list, a two page list of different concepts of the Go programming language. You want to know what doing concurrency in Go looks like? There's a few very short examples that show you that. You want to know how types work? There's a few examples you can try that stuff on. So, you're going to get a sense to see snippets of code. And what does writing these things in Go looks like. And it's very idiomatic. If you learn how to write, Go from these sources, you're going to be in a very good position to be able to write Go like Gophers actually do.

Johnny Boursiquot:
But once you're there, though, nothing cements your learning than actually doing. So, maybe it's a small project, side project you have where you want to build a command line tool for it. Go is exceedingly well suited for building command line tools. Build a small CLI project. Nobody has to it. Yeah. I know sometimes we don't want to show our stuff out into the world, we're afraid somebody's going to stumble on it and criticize us to death. That's okay. Nobody has to see it. You should build your own side project. Build yourself a command line tool, build yourself a REST JSON service that runs locally. You can just run local whole [inaudible 00:39:13] at 8080, and then hit it, see if you can get some information back.

Johnny Boursiquot:
And then, you're going to start to get a feel for how you write Go code. That's the most important thing, get a feel for how you write Go code. And then, from there, you're going to say, "Okay. I need to solve a more complicated version of this particular problem." Then, when you start searching, then the things that you're landing on are going to make more sense because you have some exposure, you know what good Go code should look like. You have some foundational learning there. Now, your searches become very specific. How do I do this very specific thing? And a lot of times you're going to end up on stack overflow, you're going to end up on some popular blog posts. You might end up on a YouTube video, but you're learning very specific things.

Johnny Boursiquot:
If you try to learn too much, at all at once, you're going to do yourself a disservice, because like you said, there's so much content out there. You have to, basically, start from trying to solve a very specific problem. But before that, get that foundational stuff. Read Effective Go and you might come across... Another resource of mine that I always recommend, it's called the code review comments. It's maintained by the Go team. It's under the actual going on GitHub, github.com/golang. The Wiki has a section there called code review comments. If you want to know how the core team on Go, the people who write Go and write the language itself, how they recommend you actually write your Go code, that's also a great source.

Johnny Boursiquot:
So, once you get that foundational stuff, you're good. The rest is going to be, "Okay. Add a little bit of knowledge to what I know over time." Don't try to learn all of it at once. Get that foundational stuff first and have a problem you want to solve.

Kate:
Very cool. Awesome. Yeah. And we'll include all those links in the show notes. So, definitely check those out.

Johnny Boursiquot:
Yeah.

Kate:
Johnny, it's been a pleasure. Thank you so much for coming on PodRocket. We'd love to have you back at some point.

Johnny Boursiquot:
Yeah. Sure thing.

Kate:
See you around.

Johnny Boursiquot:
All right. Awesome. Good to be here.

Brian:
Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter or you could always email me, even though that's not a popular option. It's Brian at LogRocket.