Transcript

[Radio channel adjustment]

Announcer: Today, on CodePen Radio.

Marie Mosley: Hey, everybody. It's time for CodePen Radio. This is Episode #274, and this week we are going to be talking about Go, or also known as Golang. It's a programming language that we've been working with a bit here on team CodePen.

I'm Marie Mosley. I'm the support lead here at CodePen. And with me today to talk about Go is one of our co-founders, Alex Vazquez. Hey, Alex.

Alex Vazquez: Hey there. Thanks for having me.

Marie: Hey. No problem. Thanks for coming on. You and Dee are the two people who know Go the best, so I had to have one of you.

[Laughter]

Alex: To qualify that. On this team, not in the world.

Marie: Well, you know what--

[Laughter]

Marie: We don't know that do we?

Alex: I didn't check with everyone else, but I'm pretty sure that's accurate.

Marie: Yeah, so I called it Go and Golang, but the real name is Go, right? That's what it's--

Alex: Yeah.

Marie: That's what it goes by.

Alex: Yeah, Go. Whenever you look at the docs, we refer to it as Go. Golang is far more searchable or Googleable, as the kids say.

Marie: Yeah. Yeah, I guess the word "go" is a little tricky to look up.

Alex: Yeah. Yeah.

Marie: Yeah.

Alex: Definitely don't name something two letters. That's super common. But you can do it if you create something like Go that I think you can pretty much name it whatever you want and we'd still use it.

Marie: It seems so. Based on what you have been telling me about it, it is incredibly exciting. They could have called it anything. [Laughter] It's so useful and so helpful.

Alex: [Laughter] Yeah. Yeah.

00:01:39

Marie: Actually, I'd really like to just start off with just talking about what it is in the first place. What is Go? When you talk about the Go language, what do you mean?

Alex: We use other languages at CodePen. The other ones we use are JavaScript and Ruby. We run everything on Ruby on Rails for Web servers and have some processes in JavaScript, Node.js, and things like that. Adding another language to CodePen is a big deal. It's something we don't take lightly.

For a long time, I've heard about Go. Played with it a few years ago. Started learning about it slowly over time. Golang itself, it's an open-source programming language designed by a few folks at Google who are incredibly talented. They have built other languages, Rob Pike and Ken Thompson. Ken Thompson built a big part of why Unix exists in the world.

Marie: Oh, wow.

Alex: Hence, computers exist.

Marie: Okay. [Laughter]

Alex: It has a really amazing pedigree and it comes with a lot of, I'd call it, wisdom (from my perspective). And so, it's this open-source programming language that was built in 2009. It's a little younger than JavaScript and Ruby.

The intention when they built this new programming language was to create a language that's simple for developers to develop in and where they can be productive very quickly but without a lot of magic, confusion, and complexity. Go is really interesting because it's one of the languages that is known for what it doesn't have. Yet it's an extremely popular language. There are at least a million code developers at this point.

It's very mature. There are a lot of really great flagship products that are written in Go. Kubernetes and Docker are written in Go. And so really, to me, I see it as a programming language that's built for the Web and the cloud of today.

Its goals are simplicity, to be non-magical, and be very easy to follow and understand. And so, it achieves that. But the beautiful part is it also achieves a lot of speed and capability that kind of hides beneath the surface.

That's been the number one thing. It's the ability that I can pick up another programming language, endorse it to the rest of the team where I can say, "Okay, you can learn this. You can invest time in this, and there'll be an almost instant benefit when you do pick it up. Know that it's going to make you very, very productive."

Other languages that I've played with -- because I love programming languages and tech, in general -- are things like Rust and Swift, which are great and they're really powerful, but they also have a steep learning curve. Even though I love playing with them, learning about them, and trying to develop apps or little CLIs for myself, it's not something that I could endorse to the team and be like, "Hey, spend six months of your life on Rust." For a small team, we don't have a lot of ability to spend a ton of time learning new tech. And so, that's where Go just fits all the right attributes of what it would take for us to literally add another programming language. You know?

Marie: Yeah.

Alex: Yeah, it's been great so far. It's really exciting.

00:05:22

Marie: You mentioned non-magical as one of the attributes of it. I'm curious about that. What does that mean, exactly, non-magical? [Laughter]

Alex: [Laughter] Oh, man. Yeah, so to an old dev like me, there's just this point where something like Ruby on Rails is fairly magical, and it's great once you know it, once you know where that magic comes from. Sometimes things that are being created for you dynamically, you just simply have to know and understand by reading documentation. But if you're looking at the code itself, you have no idea where that method or attribute came from because it was created at runtime by the framework.

For example, there's a method in Ruby on Rails where you can say, for example, "Find by username." Right? That attribute doesn't exist at compile time.

Marie: Mm-hmm.

Alex: It doesn't exist until -- that method that you're calling on your code, it's not defined anywhere. You couldn't go look it up. Ruby will dynamically see that you wrote a method that starts with find_by and then an attribute, and it will magically try to figure out if that object that you just called the method on has a username object and then do things in the database to go get you that object. That's amazing for the amount of typing that you have to do and being really productive when you learn the framework and you learn all the little nuances of Ruby on Rails.

But when it's 3:00 in the morning and there's something magical and it's not obvious where it's coming from, you want to get rid of all the magic. You wish you typed every little thing out and you could follow that piece of code. Go follows the principle of trying to be non-magical because you will see those things typed over and over again in Go.

There are moments where you will feel like it's a little painful that you're doing something over and over again. But the benefit ends up being that when you look at your file and you're trying to debug a problem, it's all right there. There's nothing hidden.

The language and the community itself tries to make things that are really obvious, even if you have to type a bit more. There's a balance to having to type way too much and making tons of mistakes because of it and not having to type hardly at all but then also being confused when you go back to figure out what you did. I think part of it is being on the Ruby side.

Marie: Yeah, and you're more hands-on with Go, in a way. You're having to write everything out yourself. It makes you more intimately familiar with what's happening. [Laughter] I like that.

00:08:25

Alex: Yeah. Yeah. There's some of that. Part of it is just having been on Rails for so long and having had that magic, you kind of go, "Okay, well, I know how I've been bit by this before. It'd be nice if we had a language that enforced that we didn't do those things." It's almost like a reaction.

I love Rails. I love Ruby. I think it's a beautiful language and it's enabled us to build CodePen. I love that.

Marie: Yeah.

Alex: But at the same time, I'm at the point where -- this is a good problem to have -- so many people use CodePen. When I fat finger something and then find out about the mistake, a dumb little mistake that went out to production, I get frustrated where I'm like, "I wish I had a typed language to just tell me." Because at this point, it's far worse to release that change and piss everyone off because you broke the editor--

Marie: Mm-hmm.

Alex: --in some way than it is to be forced to do a little bit more work up front (in that case). To me, it's telling of where we are and why we're choosing this thing. I would still choose Rails for a lot of reasons. But I absolutely love Go for working with it and trying to solve the problems that we have today.

It's very much, I love purpose-built languages, languages that have a very ideal spot when you're trying to solve a specific problem. I love the idea of being able to have a good set of tools in my toolbox. Go just really fits into what we're doing right now.

00:10:03

Marie: Yeah. It's been kind of a theme lately on the podcast and just in doing CodePen, just that we're at this scale now where we really need to be working with new things that can handle that scale. [Laughter]

Alex: Yeah.

Marie: Based on what I've seen you and Dee do with Go, it's been a huge help to manage our simply massive scale. I mean it's massive to us, anyway, the scale.

Alex: Right. Yeah. Definitely. Yeah, we've been moving a lot of data around internally. Hopefully, you didn't notice. If you did, I'm sorry.

We've been moving data around, cleaning things up to make CodePen easier to determine whether or not we're in a good state and cause fewer bugs because of bad data. When we have these data problems, they tend to bubble up through the entire codebase. You end up seeing Ruby that's trying to figure out if it has the correct value or if it's nil. Then JavaScript does the same thing. It just bubbles up through the entire codebase.

It used to be that we could just be like, "Oh, this is a one-off," and you do enough one-offs, and you're like, "I can't believe how many places we have to do this. We have to check to see if we have the good data."

And so, we've been trying to clean all those things up, which requires us moving millions of records around in our database. Not only is it to scale, but it's also we've been around eight years.

Marie: Mm-hmm.

Alex: We want to hold onto the eight years' worth of data. That's quite a bit of data. And so, along with using obvious tools like SQL for what it's meant for, there are times where it's just cleaner, easier, and more intelligible to write it in a programming language.

The way we started with Go is we started writing a lot of scripts to clean things up in the database and move things around. That allowed us to run things literally from our computers against our databases and not have to worry about if we were configuring everything correctly because these were one-off scripts.

Normally, we'd write these things in Ruby rake task and things like that. Just this past Sunday, I was moving data out of FireStore into our MySQL database. The way we stored the data in FireStore was terrible. It was very difficult. We had to do a lot of munging to get it to finally become a record in our database.

I wrote the script in Ruby, and I was literally only moving 675,000 records. This isn't some massive number. We should be able to do this. I wrote a really simple, dumb Ruby rake task, just linear, now parallelism, nothing. You know?

Every request seemed like it was taking about 0.5 seconds, and I started running numbers as my little rake task is running and start figuring out that this rake task that I expect to finish sometime today is going to take 3.8 days to finish.

Marie: Oh... [Laughter]

Alex: And so--

Alex: Yeah, that's not good. [Laughter]

Alex: Yeah. That's a really bad feeling. By the way, mind you, it's Sunday and I'd really like to finish by Monday.

Marie: You'd rather do something else, yeah, on your Sunday.

00:13:36

Alex: Yeah, literally do anything else. And so, at the end of the day, I had to give up on that rake task.

We'd been doing Ruby and things for a long time, so we have things that we can do; run things in parallel, cache things, exit early, all the little things that you would do. But that adds a certain level of complexity verifying that that script ran correctly and things like that.

And so, instead of spending my time trying to optimize my Ruby, I was like, "You know we're doing Go all the time. I'm trying to use it for as much as possible." I spent the next five hours or so porting some of that stuff to Go because we don't have as much that we can rely on in that world. There are still things that we have to rewrite that are already written in Ruby for us, libraries and things. But I wrote it, got things going, verified that it was moving the data correctly and, in the end, it ran in one minute and ten seconds.

Marie: Whoa! Okay.

Alex: Yeah, and I'm not some amazing Go programmer. I'm literally at the entry-level of Go. I was like, I know I'm writing incredibly basic, simple Go, but it is incredible and really empowering for us to be able to write something like that. It runs extremely quickly.

If I have to rerun it because I made a mistake, I am not scared. I don't have to be like, "Oh, my gosh! On day three of that rake task, if I realize I made a mistake, I would have to wait another three days."

Marie: Oh, yeah. Oh, yeah. That would have been a nightmare for sure.

Alex: Yeah. Yeah, and granted. We're a moving target. CodePen, we do our best. We don't intentionally take down the database (if we can avoid it). If I'm moving data around, people are still writing to that old table. I have to make sure I grab that old data, the data that the users have written before I did my initial export, and things like that.

Yeah, it was very, very powerful. I've had enough moments like that with this new language, this new tool that we're adding to our toolbox. It becomes almost you feel negligent if you're not using it, if you're not exploring that because what we can give our users is a far, far better experience.

Speed really matters to our users, and so we want to give that to them. Adding this tool has been really amazing.

Marie: That's awesome.

00:16:07

[Guitar music starts]

Chris Coyier: Hey, hey, CodePen Radio listeners. This episode is sponsored in part by Jetpack.

Jetpack has just been on a tear this year releasing great stuff. It's a plugin for your self-hosted WordPress site, a lot like blog.codepen.io is. In fact, we totally use Jetpack in almost every feature of it, things like making sure your images are on a CDN and being able to do stuff in Markdown.

One of the big ones that we did recently on blog.codepen was turned on their instant search, which has just been great, and customized it so it just searches the documentation because chances are if you're on that site, that's where we keep our docs. That's what you're searching for. That's what we want to get you to. I think the search experience, which they call Jetpack Instant Search, has just been tremendous on the CodePen blog. Loving that.

But here's another thing that they just released, which is like their backups feature, too, which is a la carte if you want backups of your site (either daily or instantly, as things happen on the site, which is awesome). You can just be like, "I just want that feature only," and just buy it.

They also just released Scan, which is just like that. It's security for your WordPress site - super good security. It's like WordPress themselves looking at your installation to make sure it's all good, there are no files being weird, nobody is trying to mess with anything. It's just like from the horse's mouth security audits of your site. If you just want that feature, you can just buy that. If you want to pair it with also buying backups, you can do that. Of course, we do all that because I just think that's important stuff. You know? It's about as important as it gets. To keep your WordPress secure, check out Jetpack Scan.

[Guitar music ends]

00:18:06

Marie: So, another really good example of something that we've sped up with Go, and this is one that's very dear to my heart because it's my newsletter (The Spark).

[Laughter]

Alex: Yep.

Marie: The Spark used to take almost two entire days to go out. We would send it on Monday morning and then by the beginning of Wednesday morning it would have completely sent out--

Alex: Wow!

Marie: --to the almost two million people that read it. So, I just took that as "this is how it's going to be," and just understood that it would be rolling out continuously throughout a period of two days. People were getting it at weird times a day and stuff like that, and it just really wasn't ideal.

Now, when I send it out, it's out. All of it is out in like 20 minutes, which is just an incredible, incredible change.

Alex: Yeah.

Marie: I just figured with the volume that we were sending, that was just how it was going to be - always. It's amazing to see this change. I'm curious about how that came to be.

Alex: Yeah, that's interesting because that's one of the first things where I was like, "Wow! That's incredible!" That change actually ended up being a combination of a few things. It's realizing that Spark posts, our email sender for that newsletter, could handle that load in that small amount of time without freaking out on us as trying to spam, and so they had their own internal queue. But then it was replacing the queue service that would gradually and slowly send these emails out to our service. That was a Ruby-like sidekick queue service, and so replacing that entire thing with just one simple Go script.

We've since upgraded it from running on my desktop where I hit return and execute the little script to something that runs on Lambda in Go. But it really was, I think, my personal biggest ah-ha moment like, "Wow. Not only do our users all get the email at the same time. They get it on the same day."

But it's actually far simpler for us. The difference between having to manage a queue where there are servers, data, state, and all these things versus running a simple script that it takes 20 minutes or so but it's still one simple run through, makes it incredibly easier for us to manage that entire process. If we mess it up, we can stop it and try again.

Marie: Mm-hmm.

Alex: Whatever it is that we're doing, we're finally at the scale where, if we don't start changing what we're doing and how we're doing it, everything is going to take longer. Then that just has an impact over every single thing we do, our willingness to send out other emails like feature level emails, feature announcement emails that we've been doing lately. Not being scared of that is just empowering for the whole team.

What I can see happening, at least for myself (and I hope that we all start to feel this way) is that we can take on these problems. I had taken a lot of the data problems that we've had as just like, "That's just the way it's going to be."

Marie: Mm-hmm.

00:21:42

Alex: It'd be far too painful to try to clean all that up. Like, are you really going to wait four days for a simple script? You know 675,000 records is one of the smaller tables.

Marie: Yeah.

Alex: We're not -- you know some tables have 20+ million records, and so I just take it as, like, we'll live with it. Someday we'll figure it out.

Having this really dumb, little tool where I was like, "Oh, this is something that I'm just technically interested in to understand how it works and kind of keep up with the industry and see what people are doing," to, like, "Holy crap! We can do these things that we've been sitting on that we've known that are a little painful. We can alleviate that pain. Then we can start--

When we clean things up or we send emails out in 20 minutes, it enables us to do things that we've wanted to do for ages. And so, it's really great and really shows how much you have to think about the problem and choosing the right tool to solve that problem with versus just taking your hammer and seeing nothing but nails. You know?

Marie: Yeah.

Alex: Which is kind of like what we've always done. You know?

00:23:00

Marie: Yeah. Having this, just reducing the time, like you said, it frees up the ability to send email more often. For example, when that was taking two days to send, we would literally run out of days of the week to send stuff.

[Laughter]

Alex: Right.

Marie: If we wanted to highlight a feature, we would want to wait to make sure that all of this was completed because you're not going to want to hit people with two emails on the same day. You know?

[Laughter]

Marie: You've only got five business days in a week, so this gives us the ability to actually use every single one of them because we also have, on Monday, the challenges that go out. We also used to have to be super careful to make sure.

I would leave. If I was going on vacation, I would leave notes where it's like, "The challenges must go first!" in the biggest fonts I could possibly do.

[Laughter]

Alex: Right.

Marie: Because it was a much smaller list. If we put that after The Spark, people wouldn't get the challenge prompt until Wednesday.

[Laughter]

Marie: It was definitely something that was very, very brittle and had all kinds of requirements around it. Now, if someone accidentally sent The Spark first on Monday, it's okay. Just send the challenges. It's fine. It's only been 20 minutes.

Alex: Yeah. Give it 20 minutes. You'll be okay.

Marie: Yeah, so it's a huge difference.

Alex: Yeah.

Marie: And it is fun to know that we can bring this flexibility in, and it's nice to know that it's with a language that everybody is liking working with, which is really cool.

Alex: Yeah. Yeah, the way I see it is, I don't see it as, "Oh, I'm obsessed with performance." We want reliability and a really good experience for our users. Part of that is performance, but it's not like we're obsessive about it.

Marie: I don't know. I've seen some charts. The dev team has been making some charts lately. [Laughter]

Alex: Things are changing and we're getting a little addicted to speed, to be honest with you.

Marie: I'm noticing.

[Laughter]

Alex: But the way I see it is, if I have something that is 30 times faster than what I was using before and I'm using it for the same reason, I feel like, personally, I can be 30 times as dumb and still be better than I was before with the previous tool. And so, I get to just write really simple. I don't have to be clever about what I'm trying to accomplish when I know I have this thing to rely on.

I get to appear like I really know what I'm doing because, hey, I took the email send from two and a half days - or whatever - to 20 minutes. You're like, "Wow! That's really impressive," but you just are able to use that tool that makes you look really good. I love that. It's just such a fun part of technology that you can pick up these new tools, languages, and things and, with this discovery, be able to really amplify yourself.

On a small team, it's all about that. How much can we do with the small team that we are? We're only seven developers, you know, a team of seven.

Marie: Yeah.

Alex: And so, the more that we can do with a small team, great. That's our goal. Let's be as effective as possible. And so, this has just been a big revelation, so it's allowing us to do more. So, it's really exciting.

00:26:22

Marie: Yeah. It is always the balance of the tininess of the team and the scale of the product and the scale of the community.

Alex: Yeah.

Marie: It's great to find things like this that can really make us superpowered. I love that it's called Go because it just has that feeling of momentum behind it. You know?

Alex: [Laughter] Yeah. Yeah, maybe that was the intention is you can just go with it. It takes a very short amount of time to get going with it. I would encourage anyone to start playing with these technologies. It's really awesome.

Even if you don't end up using it for work purposes or anything, you do learn something. You learn a new way to solve things and you get just a different perspective on things. I love it for that purpose. That's why I love reading about languages and things like that just to get another community's perspective on how they approach problems, how they solve.

They're really sweet, as far as I've seen. The Go community itself is very inclusive. They are very much about keeping the feel and vibe of a small community that is very inviting. That's been really nice to see as well.

Marie: Nice.

Alex: It has a really good community around it. If you're interested, if you're a front-end dev and you're thinking, "Hey, I should play with a back-end technology," this is a very approachable back-end technology (in my book).

You don't have to manage memory. It has static typing, but it's very lenient with the way it handles it. It doesn't feel overly verbose. I think it just hits a really nice sweet spot for someone who is transitioning from dynamic languages. It'll add a little something to your repertoire. If you're ever faced with a long-running task you feel like you can get it done faster, it's really amazing.

Marie: It ties in with things like you mentioned earlier with Lambda and stuff, which is something that front-end devs do dabble with from time to time. [Laughter]

Alex: Right. Yeah, that's a really great way to get it into production, should you need to. You get charged by the amount of time your Lambda runs, so it's not a bad deal to also save a little money--

Marie: Hmm. Yeah.

Alex: --if your script runs at faster speeds, so a lot of benefits. It's a really pleasurable language to work with. I find it really easy to learn and get going with.

Marie: That's great. Yeah, and Go is the one with that cute, little gopher, right? That's their mascot?

Alex: Yeah.

Marie: I love it. [Laughter]

Alex: Yeah. Yeah, the gopher. A lot of people got upset because they came up with a new logo, and people thought they got rid of the gopher. The gopher is the mascot, but he's not the logo.

Marie: I see. Okay.

Alex: Yeah, that's a common misconception in the Go community.

[Laughter]

Alex: No. They have this cute gopher. Everybody uses it. It's just universally loved.

Marie: That's great.

Alex: They have a logo, but it's barely recognized next to the gopher.

Marie: Wait. Okay, so we have a logo, but we do not have a mascot.

Alex: We don't.

Marie: This opens up a lot of possibilities for us here at CodePen.

[Laughter]

Alex: I'd like to nominate myself as the mascot.

Marie: I don't think that would fly.

[Laughter]

Marie: I don't think you get to make one of the co-founders the mascot, but maybe. I don't know. I don't know. If someone could draw a very cute cartoon of you, I guess we could consider it. [Laughter]

Alex: Ah, that's going to be tough. We're probably going to look for something less difficult to make cute.

Yeah, well, we actually should get a mascot. That's what we've revealed.

Marie: Yes, it has opened up--

Alex: Another thing Go has enabled us to do is figure out that we need a mascot.

Marie: Granting possibilities for team CodePen. We have learned so much from Go, it's incredible.

[Laughter]

Alex: Yeah. Every lesson.

Marie: All right, well, we actually have more even to say about Go. There is so much to talk about. Next week, I'm going to be talking to Dee about her work with Go and her experience with learning it, so stay tuned for that.

But until next week, take care of yourselves. Be safe out there, everyone. We will talk to you soon. Thanks for listening, everyone.

Alex: Bye, everybody.

[Radio channel adjustment]