"While we could usually write the specific code we needed for a particular program, before Go generics it wasn’t easy to write functions on arbitrary container types, such as slices.
For example, we couldn’t write a function that takes a slice of arbitrary type and determines whether the slice contains a given element. Instead, we had to write a function that takes some specific type, such as []int, or []string.
But this is dull, because the logic is exactly the same, whatever the type of the slice element. And now we can write that function just once, for all types. Let’s try."
What problem does 'defer' solve? When should we use it? How does it interact with named results? What's the use of deferring a closure? Is it okay to write naked returns?
Tests communicate a lot of information, to readers, other developers, and even our future selves. Well-written tests focus on a single unit of behaviour that can be described in a brief sentence, and we can use that sentence as the name of the test.
“If you get fired as a result of applying the advice in this book, then that’s probably for the best, all things considered. But if it happens, I’ll make it my personal mission to get you a job with a better company: one where people are rewarded, not punished, for producing software that actually works.”
"First, it's really important to say that both Go and Rust are absolutely excellent programming languages. They're modern, powerful, widely-adopted, and offer excellent performance. You may have read articles and blog posts aiming to convince you that Go is better than Rust, or vice versa. But that really makes no sense; every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it.
In this article, I'll try to give a brief overview of where I think Go is the ideal choice, and where I think Rust is a better alternative. I'll also try to give a flavour of the essential nature of both languages (the Tao of Go and Rust, if you like)."
‘For the Love of Go’ is a book introducing the Go programming language, suitable for complete beginners, as well as those with experience programming in other languages.
This completely revised and updated edition includes the four mini-books previously released as ‘Fundamentals’, ‘Data’, ‘Behaviour’, and ‘Control’, plus for the first time complete solutions (with tests) to all the coding challenges in the book.
Throughout the book we'll be working together to develop a fun and useful project in Go: an online bookstore called Happy Fun Books!
Each chapter introduces a new feature or concept, and sets you some goals to achieve, with complete, step-by-step explanations of how to solve them, and full code listings with accompanying tests.
There are 24 chapters, and 215 pages (depending on the screen size of your ebook reader).
By reading this book and working through all the challenges and exercises, you'll learn:
How to write tests in Go and how to develop projects test-first
How to manage data in Go using built-in types, user-defined struct types, and collections such as maps and slices
How to use objects to model problems in Go, and how to add behaviour to objects using methods
How to use pointers to write methods for objects, and how to use types and validation to make your Go packages a delight to use
How to build powerful, flexible programs using control structures like loops and functions
Even more importantly, you’ll learn a simple, fun, and effective way to approach software engineering projects in Go. Even though the material is beginner-friendly, you’ll be mastering intermediate and advanced techniques such as test-driven development (TDD) and learning to design modules, packages, and APIs. These are essential skills in any modern software engineering role.
Interview by Bill Kennedy of Ardan Labs, for the Ardan podcast:
"John Arundel is a software consultant, mentor, and author of the book “For the Love of Go”. We talk about his early fascination with computers, the role his mother played in planting these seeds, and the steps he took in his younger years to follow his passion. We then explore John’s indirect job path, having to settle for work as a technical writer out of college and stumbling into IT and system administration. But the major lesson that comes out of this is that these 'detours' actually served John's later work, developing parts of his expertise that would aid him in his writing and mentoring."
It's tempting to think that 'speed' (actually acceleration) causes time to flow at different rates for observers in different frames, but this isn't really the case. Time flows at the same rate for everybody: one second per second. However, if I meet you at an agreed rendezvous next week and one of us has accelerated in the meantime, we'll find our clocks no longer agree. We took different trajectories through spacetime to reach the same event, so our histories are of different lengths.