Mastering Go

Yes, yes, it is indeed Go Time. I will be your host today. I’m Johnny Boursiquot, and joining me is the author of the book “Mastering Go”, Mr. Mihalis Tsoukalos. Hopefully, I’ve done your name justice…

Yes.

Awesome, awesome. So I became aware of your book - or rather the first edition of your book, maybe a year or two ago. And then it seemed like one of those very thick reference manuals. I was like, “Okay, this is one of those things you’ve gotta get on your shelves”, like old-school, those giant tomes that you’d put on your shelves and you’d use them as reference every once in a while… Because nobody reads a book front to back these days. So I’m thinking, “Okay, maybe I’ll put this book on my shelf.”

Lo and behold, I never happened to do that, and then the publisher reaches out to me and says “Hey, would you like a review copy of this book? And I’m like “Sure, yeah. It’s not like I don’t have a dozen other things to do”, but hey, I’m a sucker for reviewing Go books, and I was looking forward to this one as well… And I got the book in the mail, started going through it, and I was basically nodding in few places, I’m like, “Yup, yup, that’s how I would explain that.” In other places I’m like, “Okay, yeah, that’s a different way of explaining it.” But the thing is, as I was flipping through the book - and I certainly looked at different areas of the book to see how you explain things, and see “Are there some tricks and tips and things that I can steal from you to explain certain things as well in teaching people Go?” And when the opportunity came up for – I think I was talking about it on Twitter or something, and you chimed in… I’m like, “Okay, so he seems friendly enough. Why don’t I just have him on the show, so we can actually talk about the book?” But not just about the book, but really – the title, basically, I find intriguing, and I wanted to talk about what it is like to master Go. We’ve gotta go meta with this, right?

[04:09] But yeah, for those who don’t know who you are, who you are on Twitter, the Twitter handle is @mactsouk, and you’re a systems engineer and technical writer. So obviously, the writing is important. You’re writing books, and everything. This is the third edition of your book. I wanted to start out with basically – well, I’ll give you a chance to sort of add any flavor you want to your intro. Like, what else have you been up to?

Okay, so hello everyone, thanks for listening to us, and Johnny, thanks for the opportunity to come to your podcast. I’m a Unix passionate, I like Unix. I don’t know why, but I like Unix, so you know… And systems stuff. I used to be an Oracle DBA, and I used to work with Cisco IOS… You know, the operating system of Cisco, not the Apple version of iOS. And Unix, and setting up SendMail DNS, with BIND, all these things that some people find miserable, but I really like them.

Yeah, it used to be a rite of passage, you know? Set up your own mail server, and everything, your own DNS…

Yeah, SendMail with m4 configuration files, and those things. And working with versions of Unix other than Linux, like the IBM version AIX, or the Hewlett Packard version of Unix, HP-UX, and Solaris, my favorite one… So I’m a systems person, I like Unix, and I like writing software… So every time I see a systems programming language, I like to try it. I like C very much, but C is not perfect. I don’t like C++ though… It’s too complex for me.

So the idea was to find something that I can write systems software, but without having to worry about C stuff. That’s how I started getting interested in Go. And when I learned that Rob Pike was involved - that was a big plus.

So I started working more with Go, and learning Go more, and after some time I just wanted to write a book that I would like to read when I was learning Go. But the thing is that first I wrote a series of articles for Computer Magazine in the U.K. Ten, or maybe twelve, I don’t remember… A series of articles that at the end became something like the table of contents of the book. Because you know, you have to prepare.

And that’s how I started getting involved with Go. You know, you can’t trust a programming language too early, but you have to work with it, see how it goes, and see if you want to keep working with it.

Yeah, I definitely agree with that sentiment. The fact of the matter is when you say you want to write a book that you would have liked to learn Go with, the approach you took with the book - I definitely didn’t think this was a beginner book. I think that’s something that usually when I give references to people for learning material, I usually ask them “What level are you at? Are you an existing programmer who is learning to pick up a new language, or are you brand new to programming? Or are you basically a die-hard functional programming developer?” We analyze your preferences. And when I picked up this book, the first place I went - in the intro it basically says who this book is for. And right then and there, it says “Hey, this is an intermediate book.”

So then I was like, okay, great. That means when I start going through that book, I’m not going to see things like “This is what a conditional is.” It’ll just say “This is how Go does conditionals.” Or things of that nature.

[07:56] So when I went through the book, once I understood sort of the frame of reference that you were using to actually write the book, then the gripes I might have had with it, I started basically saying “Well, okay, so if Mihalis is making these assumptions about the reader, then this is the lens with which I have to look at this book and ingest some of this book.” So I think definitely something I wanna put out there - a lot of times folks just pick up a book, and they’ll give a review, and not really understanding basically who the book was targeted for… If you’re a beginner and you’ve picked up this book - yeah, you’ll still learn a lot. But there are some things that you’re not gonna go deep into. There’s some language features that you already ran to without having to explain the background on them, because you assume that the reader is coming in with sort of a basic understanding of at least what Go is, and what Go does.

So that was the approach I took with the book… And for those who are looking to pick it up as well, that’s what they should expect. That said, I kind of wanted to give you a chance to narrate a little bit on – yes, this is a book you would have liked to have had, but you’ve been working with Go for a while; obviously, you’re gonna have a biased answer for this, but do you believe a book like this - maybe not necessarily your book, but a book like this - is the right entry point for somebody who’s maybe coming from another language and looking to get into Go? Is this a book for just learning Go, period, or are you targeting one level deeper? …not just for the person who’s starting to learn to pick up Go, but as you mentioned, you like systems programming, right? Will a systems programmer find this Go book in particular a lot more their speed, or should they look at something else more targeted at systems programming?

It depends. Generally speaking, if you have some experience with programming, you should pick up Mastering Go very quickly, because you have to have some experience. If you have the experience, then you can work with it very easily… Because programmers know that the key point to learning something is practice. Some things we find them difficult, and we have to look again, and other people find other things difficult, and they have to look at them multiple times to understand them.

With Go – I mean, one thing that surprised me with Go is that you didn’t have the tilde, and fork, and things that you do in C. It took me a while to understand it, and understand that I have to work with goroutines instead. You have to practice to understand that, but in order to look for a fork, you have to know about fork. So if you know fork, then you can understand what is going on there.

Again, I think that the key point is practice. If you want to practice, then you will be okay. And the cool thing with the book is that even I use it as a reference sometimes, many times. Because you can’t remember everything.

God must give you some special kind of pride to be using your own book as a reference.

Yes, yes, yes. This is a good point, not as a pride, but as a thing that you can – you know, it is useful. It’s not pride, because I have read many books, and I have used them as a reference as well. Many people have done that. But it’s good to find it useful, because you cannot remember everything. You can’t have everything in your mind.

Right, right. Yeah, Google-driven development is a thing… I partake in Google-driven development myself, so no shame in my game. Nobody can remember everything, and the nuance of everything. Every once in a while I’ll still go to – you know, my favorite resource in the Go community is gobyexample.com, for example… For example, for example. Gobyexample.com is a great resource that I regularly reference, even to this day, after having been doing Go for like five years, or something. I’ll be like, “Okay, how do I initialize this again? What’s the technique for doing this again?”

[12:00] One of the things I constantly refer to is “How do I properly seed for randomization?” I always have to go look up “Okay, what’s the package duran something?” These things, even though you use them frequently – like, sometimes it’s “Okay, what’s the syntax? What is this type that I use all the time, that I need to learn a little bit more about? What is this package in the standard library that I have used a dozen times and I’ve only ever tried one or two functions from this package? What else does it offer?”

So this is sort of a continuous journey of mastering Go, which is something I definitely wanna get into and talk about in a bit… Sort of at the philosophical level, what does it mean to master Go. But this is a 750-page book, so it’s a chunky book. Lots of topics covered. What do you think was the most interesting parts for you to research and write about?

The Go garbage collector.

Ooh…

I really enjoyed reading about that and learning about it, and then writing about that. I really enjoyed it. And I also enjoyed lots of external libraries like Viper, and Cobra, and [unintelligible 00:13:06.02] and Gorilla. Because they extend the language in a good way. Especially Cobra and Viper are really helpful. As I’m working with some REST APIs, I use gorilla/mux, and I’m trying also to learn [unintelligible 00:13:24.24] to understand what their differences are, and which one is better for what job.

I mean, that’s the experience part. It’s one thing to learn about something, but it’s another thing to be able to choose based on facts. That’s the difficult part.

Speaking of the research and writing process, how long did the – at least the first edition; I’m assuming with each edition you’re not rewriting everything, you’re just updating a few parts, some things that have changed, maybe some idioms have changed and whatnot… Roughly how long did it take you to write and publish the first version?

Given the experience that I had with the articles, and another book that I have written for Packt is the Go Systems Programming, which helped a lot; it’s one edition, it’s the first book… It took me - and a lot of preparation though - six to eight months. But with a lot of preparation. You know, you cannot start from zero and expect to have the book ready in six months. But a lot of preparation, and a lot of code. You have to have some code ready.

[16:07] So did you enjoy – like, in my mind, having collaborated on book projects and things, in my mind there’s the thing that I’m writing about, and then there’s the writing about the thing that I’m writing about. Those are very different disciplines, very different skillsets. Writing about something you know and doing the thing you know are very different things. I can go all day and feel like I know what I’m doing, but the process of writing, even if I’ve written before, writing a book and working with an editor, working with people that are gonna give you feedback on the writing process, the tools and resources that you use as a writer - these things are not your day-to-day typical programmer tool. There’s always sort of a learning process that’s also taking place with regards to the act of writing a book, or the act of creating a training, or a course, or the act of creating something for relaying and conveying information to another human being. That in itself is a separate skillset that you have to develop. I wonder how you feel about that skillset, having gone through it a few times. How do you feel about that?

For this skillset, the articles that I’m writing for Computer Magazine have helped me a lot, because for the article you have to present something, and you have a limited space. So you have to have a beginning, a middle and an end, and that helps a lot. So I’m trying to follow the same approach. As I’ve told you before, you cannot remember everything. If I read something afterwards, I try to be sure that it makes sense, at least to me, and then to the readers. Because you know what they say, “Write for your friends, but edit for your enemies.”

[laughs] I’d never heard of that one before. I’m gonna use that.

So when I’m editing, I’m trying to edit and be a hard judge for my own writing. And I think that helped me a lot with magazines, but also for the books. But have in mind that I have written some articles for magazine that I’m not very proud of. [laughs] It’s not perfect, it’s a process.

Right, right, right.

You don’t begin perfect, it’s a process. You learn, and you make mistakes, and then you make more mistakes, you correct something, and you try. We’re not perfect, we’re just – you know, work in progress.

Don’t expect to have something good, ready to ship the first time around, the first go-around, right?

Yeah.

…which sounds very much like the engineering process as well. You never quite get something right the first time. That’s why we have even idioms around the act of writing software. You write a test, you get a failure, we make the test pass, and rinse and repeat. We often have mnemonics and things around these things, so I think we shouldn’t expect any different from a different kind of creative process. It’s just ones that you’re not writing code. Although, I must say, I’m envious a bit, because – I’m sort of picking your brain in this whole thing, because I too wanna write books on Go and whatnot, and I’m picking your brain and saying “Okay, what should I run away from?” [laughs] If I were to take on such a project, what should I run away from, or watch out for? What are the pitfalls to taking on a writing project? …not necessarily exclusively about Go, but really about any task of this nature. Basically, you’re teaching people about how to use a tool, this tool being a programming language. What do you think the biggest takeaways for you were about writing this book and creating this project?

The key to writing the book is to enjoy the process first. Because if you don’t enjoy the process, it’s difficult. The second is that you have to think of the reader as a friend; not as money, but as something that you’re trying to help… You know, just help. Try to explain and don’t assume that something that is easy for you should be easy for the other people, and vice-versa. Sometimes you have to explain something twice maybe… It’s a process. You have to enjoy the process. Once you enjoy the process, then everything becomes easier.

[20:22] The other thing that I told you before - write for your friends, edit for your enemies. You should be edit hard, for your own good. That’s the way to do – you have the skeleton, you have the text, but you have to edit hard. I’m still learning that. I really enjoy books like The C Programming Language, or The Unix Programming Environment - they have the necessary thing only.

Right, right. Everything you need, nothing you don’t.

Yeah. And they have written these books with troff and Unix tools, and that’s really amazing. [laughter]

Yeah…

Not even latex

Yeah, not even modern tools that we have. That is amazing.

And they have created classic books, just for the love of it.

Indeed, indeed. Yeah, I always tell folks that based on all the publishers that I talk to, and having been part of book projects and everything else, I’m like, “Okay, people who do this - it’s not done for money.” This is definitely a labor of love, the advance that you get really is not – if you were to map that to your hourly wage, whatever you’re getting out with your employer or consulting, whatever it is, the amount of time you put in, it wouldn’t even come close. When you do this because it’s a labor of love, it’s not something that – unless you have a book that’s immensely popular, whatever it is, and you make bank, and that’s fine… But the vast majority of people writing technical books like this - you’re really just sharing something with the community, for the love of it. I can definitely appreciate that.

So again, the book is called Mastering Go, and I wanted to talk about what we believe mastering Go today looks like. If somebody started out saying, “Hey, you know what - I’m gonna pick up this language, and I wanna master it.” What does that journey look like for somebody who’s basically starting today and saying “I wanna master this language.” What are the things they need to look out for? What are the approaches that they should have? What should they expect?

Look, my book is here to help people - not master Go, but like Go. If you like Go and you use it, you’re going to master it. The thing that mastered everything is the marketing stuff mainly. You cannot master something, but…

Right, right, right.