Jay is serious about teaching others to code. Before Head First Go, he wrote a book about Ruby called (wait for it...) Head First Ruby. Jay believes everyone should know how to code, and has four years of experience teaching coding online.
Your first book was about Ruby. What prompted your interest in Go?
Ruby's a great language but it's hard to distribute finished applications. Not only do your users need to have a Ruby interpreter installed, they also need all the gems (libraries) installed that your app relies on. People have created solutions for this (like Bundler), but those solutions are still complex. Contrast this with Go, which compiles your code and all its dependencies down to a single executable. Give your users that compiled program, and they can run it even without Go installed. That's incredibly attractive if you want to create programs for distribution.
Is Go a suitable first language for new developers?
Simplicity is a primary goal in Go's design, so I think it's one of the best languages for new developers! For example, Go has only 25 keywords. Contrast that with Python (33 keywords), Ruby (39), or JavaScript (64). There's more to measuring a language's complexity than just keyword count, of course, but so many other aspects of Go are easier, too. You don't have to figure out class-based inheritance, or control flow with exceptions. Go code is just so much simpler and clearer.
What strikes you as the most difficult aspect of Go to learn?
Goroutines and channels. Go makes concurrency easier than many other languages, but it's an inherently difficult topic that can't be simply glossed over. The concurrency chapter for Head First Go had to spend a great many pages demonstrating potential pitfalls and their solutions. Fortunately, that comes late in the book, after we've already given readers the tools they need to make sense of it all.
What excites you most about Go 2.0 and beyond?
This might not be the most exciting answer, but I like the careful, thoughtful way the Go team is handling the introduction of new features. They're requiring lots of experimentation and feedback before anything makes it into an official release. I want future Go versions to have the same simplicity and ease of use that the early releases had. Thankfully, we seem to be on the right track to make that happen!
