- Description
- Curriculum
- Notice
- Reviews
- Grade
I’ve always had a love-hate relationship when it comes to learning new languages. On the one hand, languages are so fundamental to what we do that even small changes can have a measurable impact. That aha moment when something clicks can have a lasting effect on how you program and can redefine your expectations of other languages. On the downside, language design is fairly incremental. Learning new keywords, type system, coding style, as well as new libraries, communities, and paradigms is a lot of work that seems hard to justify. Compared to everything else we have to learn, new languages often feel like a poor investment of our time.
That said, we have to move forward. We have to be willing to take incremental steps because, again, languages are the foundation of what we do. Though the changes are often incremental, they tend to have a wide scope, and they impact productivity, readability, performance, testability, dependency management, error handling, documentation, profiling, communities, standard libraries, and so on. Is there a positive way to say death by a thousand cuts?
That leaves us with an important question: why Go? For me, there are two compelling reasons. The first is that it’s a relatively simple language with a relatively simple standard library. In a lot of ways, the incremental nature of Go is to simplify some of the complexity we’ve seen being added to languages over the last couple of decades. The other reason is that for many developers, it will complement their existing arsenal.
Go was built as a system language (e.g., operating systems, device drivers) and thus aimed at C and C++ developers. According to the Go team, which is certainly true of me, application developers, not system developers, have become the primary Go users. Why? I can’t speak authoritatively for system developers, but for those of us building websites, services, desktop applications, and the like, it partially comes down to the emerging need for a class of systems that sit somewhere in between low-level system applications and higher-level applications.
Maybe it’s a messaging, caching, computational-heavy data analysis, command line interface, logging, or monitoring. I don’t know what label to give it, but over the course of my career, as systems continue to grow in complexity and as concurrency frequently measures in the tens of thousands, there’s clearly been a growing need for custom infrastructure-type systems. You can build such systems with Ruby or Python or something else (and many people do), but these types of systems can benefit from a more rigid type system and greater performance. Similarly, you can use Go to build websites (and many people do), but I still prefer, by a wide margin, the expressiveness of Node or Ruby for such systems.
There are other areas where Go excels. For example, there are no dependencies when running a compiled Go program. You don’t have to worry if your users have Ruby or the JVM installed, and if so, what version. For this reason, Go is becoming increasingly popular as a language for command-line interface programs and other types of utility programs you need to distribute (e.g., a log collector).
Put plainly, learning Go is an efficient use of your time. You won’t have to spend long hours learning or even mastering Go, and you’ll end up with something practical from your effort.
-
1
Set-upIf you're looking to play a little with Go, you should check out the Go Playground, which lets you run code online without having to install anything. This is also the most common way to share Go code when seeking help in Go's discussion forum and places like StackOverflow.
-
2
OSX / Linux
-
3
Windows
I recently heard Go described as a boring language. Boring because it's easy to learn, easy to write and, most importantly, easy to read. Perhaps, I did this reality a disservice. We did spend three chapters talking about types and how to declare variables after all.
If you have a background in a statically typed language, much of what we saw was probably, at best, a refresher. That Go makes pointers visible and that slices are thin wrappers around arrays probably isn't overwhelming to seasoned Java or C# developers.
If you've mostly been making use of dynamic languages, you might feel a little different. It is a fair bit to learn. Not least of which is the various syntax around declaration and initialization. Despite being a fan of Go, I find that for all the progress towards simplicity, there's something less than simple about it. Still, it comes down to some basic rules (like you can only declare variable once and := does declare the variable) and fundamental understanding (like new(X) or &X{} only allocate memory, but slices, maps and channels require more initialization and thus, make).
Beyond this, Go gives us a simple but effective way to organize our code. Interfaces, return-based error handling, defer for resource management and a simple way to achieve composition.
As I think about the paragraphs and chapters that lie ahead, I know that I won't be able to make those same assumptions. How much time do you spend talking about interfaces, knowing that for some, the concept will be new, while others won't need much more than Go has interfaces? Ultimately, I take comfort in knowing that you'll let me know if some parts are too shallow or others too detailed.
I've hesitated writing this book for a couple of reasons. The first is that Go's own documentation, in particular Effective Go, is solid.
The other is my discomfort at writing a book about a language. When I wrote The Little MongoDB Book, it was safe to assume most readers understood the basics of relational databases and modeling. With The Little Redis Book, you could assume a familiarity with a key-value store and take it from there.
Google