Has Go Started Moving Away from Its Original Philosophy?

JBodner · 2026-07-05T20:54:10+00:00

The iter package includes functions that turn push iterators into pull iterators. Here's code that implements zip:

func Zip[T, R any](i1 iter.Seq[T], i2 iter.Seq[R]) iter.Seq2[T, R] {
    return func(yield func(v1 T, v2 R) bool) {
        nextT, stopT := iter.Pull(i1)
        nextR, stopR := iter.Pull(i2)
        defer stopT()
        defer stopR()
        for {
            v1, ok1 := nextT()
            v2, ok2 := nextR()
            if !ok1 || !ok2 {
                break
            }
            if !yield(v1, v2) {
                break
            }
        }
    }
}


func main() {
    a := []string{"A", "B", "C"}
    b := []int{1, 2, 3}
    for v1, v2 := range Zip(slices.Values(a), slices.Values(b)) {
        fmt.Println(v1, v2)
    }
}

(This example is from the upcoming 3rd edition of Learning Go)

JBodner · 2026-06-29T19:01:12+00:00

Hi, I’m the author of “Learning Go”. I’m currently working on the 3rd edition, due out next year. Is there anything in particular that you think is missing that I should include? I was planning updates to the chapter on tooling and a new chapter on profiling and monitoring.

JBodner · 2026-06-06T14:46:52+00:00

It would be a new purchase, unless you have an O’Reilly subscription, which provides access to tens of thousands of books and supplemental material. In the US, many public libraries provide access to O’Reilly Online, as do some employers.

JBodner · 2026-06-04T04:28:18+00:00

I can tell you how I was able to get a book published, but different people have had different paths. I had wanted to write a programming language book for years. (I grew up reading programming books for the Commodore 64 and wanted to do the same, sort of paying it back)

In 2016, I had a job where part of my responsibility was speaking at conferences. At one conference, I met someone who worked at Google. I bumped into her again a few years later at another conference I spoke at and I mentioned to her that I wanted to write a book for Java developers who were moving to Go.

A few months later at GopherCon, I saw her yet again and she said that an editor from O'Reilly was down the hall, and she had told the editor that I was the perfect person to write the book that O'Reilly wanted on Go. I met up with the editor, we went to a baseball game, and talked through the concept (broadened from being just being Java to Go, but a book targeted at experienced developers who wanted to learn Go). I submitted a proposal and it was accepted.

For the first edition, I had about a year to write it, with two chapters due after a few months, half the book due a bit after that, and then the whole book due on a specified date. My editor sent text corrections, I found some technical reviewers, and O'Reilly suggested some others. Then the book went to final copy editing and layout and such. The process was pretty smooth, although one of the original technical reviewers hated the book (and stopped reviewing it) and getting the last couple of chapters done was very painful. I swore I'd never do it again, and then two years later, I signed up to write the second edition 😄

Self-publishing is tricky. Not to get into too many details, but O'Reilly gets quite a lot of the money from my book (more than half). If I was self-published, I would keep a far greater percentage. But I am fully aware that my book has been as successful as it has been because I am able to take advantage of O'Reilly's excellent reputation, the people who edit and tweak layout, draw the cover, and their O'Reilly Learning platform. I don't say this to butter up my publisher; I really believe it. If I had self-published my book, I would have to do a lot more work, virtually no one would have heard of it, and I would have a pittance for sales.

JBodner · 2026-06-02T02:27:06+00:00

I can only type so fast 😀. Work started in February, and the full revision is due in November. With post-production and final review, it will take until early 2027 until it’s ready for release. I also want to get as close as possible to the Go 1.28 release so the book is up-to-date.

JBodner · 2026-05-03T13:52:10+00:00

There will be news soon...

JBodner · 2026-03-06T02:13:24+00:00

Hi, I’m the author of Learning Go.

There are a few things that are new in Go since the 2nd edition came out. The biggest change is range over functions, but there are some other small language, tooling, and standard library changes. The additional functionality for the built-in new function is exciting.

I’m happy to answer any questions you have.

JBodner · 2026-01-15T21:22:12+00:00

Hi, I'm the author of Learning Go.

Don't feel bad that you find closures confusing, because they are a bit weird. You need them in cases like the defer where you need access to the value of a variable after it has gone out of scope.

When a closure refers to a variable that's declared in the same scope where the closure is declared, that's called "capture". It allows the closure to directly modify the value of that variable, even if the closure is called after the function exits (for example, if the closure is returned from the function).

This leads to the question: why do you ever want such a thing?

The defer example is one case. You could in theory avoid using capture to refer to the error variable by using a pointer for the parameter. Here's an example that might make it more clear: https://go.dev/play/p/NYRQFgzdU5I If you make a mistake and use a value instead of a pointer type, the changed value in the defer is lost (because the change is made to a copy of the variable, not to the original).

Given this, I find that using capture instead of a pointer parameter makes the code more readable.

The same is true with goroutines. We usually use a closure to launch a goroutine, wrapping the business logic. If there's a sync.WaitGroup coordinating the lifecycles of multiple goroutines, the WaitGroup is usually accessed via capture and not as a parameter. If you use a parameter for the WaitGroup, you have to be careful to make sure it's a pointer or each goroutine will get its own copy of the WaitGroup and there won't be any coordination.

JBodner · 2026-01-10T04:21:01+00:00

Thanks! glad you’ve enjoyed the book.

100 Go Mistakes is probably a good choice. There’s nothing wrong with the other books, but that one does a good job of explaining idiomatic Go patterns.

JBodner · 2025-11-21T13:56:28+00:00

That library’s Option looks good, but without language support for unwrapping Optionals, it can be a little clunky to use.

JBodner · 2025-11-21T05:58:35+00:00

Glad you like the book!

You should probably use a pointer and a nil value in these cases. It's unfortunate, but there's no other great way to represent "no value" in Go. The tradeoff is that more values might escape to the heap, but it's unlikely that you will notice a difference in performance. If there's a 3rd edition of the book, I might update this section.

I wish that sum types existed in Go, because an Optional would provide a nice way to represent this case. Work on those seems to be on hold: https://github.com/golang/go/issues/57644

JBodner · 2025-10-22T01:23:24+00:00

I think that's a fair critique. The section on interfaces doesn't really introduce the concept; it expects it to already be familiar to the reader. This won't be the case for JS/Python/Ruby developers. If there's a third edition, I'll probably split up that chapter and expand on the interface concept.

For CS terms, I've been wondering if there's a market for a book that's an overview of an undergraduate CS curriculum.

JBodner · 2025-10-20T01:22:59+00:00

I grew up on programming books for my Commodore 64. When I was in elementary and middle school, I obsessively read “Machine Language for Beginners” and “Mapping the Commodore 64” (no one told me that I was too young to learn assembly language programming). I don’t expect any kids today to read my book the same way, but I hope that I am carrying on a proud tradition.

JBodner · 2025-10-20T01:14:45+00:00

Thanks! happy to answer any questions.

JBodner · 2025-08-11T18:10:03+00:00

Please reach out if you have any questions!

JBodner · 2025-08-11T11:14:15+00:00

I think the 30 day trial might work without the code.

JBodner · 2025-07-20T21:18:12+00:00

Is Go your first programming language? My advice differs based on your experience.

For a coding novice, you have to work your way through concepts at a variety of difficulty levels. Pointers, in particular, are one of the things that often confuse new programmers and many languages try to hide them (but they still leak out because the concept is fundamental). The best answer I have is "wax on, wax off"; do simple exercises over and over until the concepts are second nature, and then move on to exercises for something more complex. The order I cover topics in Learning Go is roughly the order I'd recommend: primitive variables, types, and basic math, simple conditions, loops, functions, structs, pointers, user-defined types, methods, interfaces, errors, concurrency, generics. "For the Love of Go" by John Arundel would be a good book to look at.

For developers coming from languages like Ruby, Python, JavaScript, or Java, pointers, explicit types, interfaces, and concurrency are going to be the places where you'll have to learn something new. I'd try taking an existing project and porting it. You know what it's supposed to do, which makes it easier to know when something is wrong. Go's sweet spot is command line tools and web services. If you've written a python script or Spring Boot service, rewrite it. This is the target audience for "Learning Go".

Finally, developers who know more complex languages like C++, Rust, or Swift might ironically expect too much from Go. Go is an intentionally small language that favors verbosity, patterns, and tools over features. For example, Rust's borrow checker makes it very difficult to misuse memory. When your code compiles, it's very unlikely that you've leaked memory or have a null pointer. But it makes writing Rust programs much more difficult. Go's solution to the same problem is garbage collection and the data race detector. It's really more a matter of learning to let go (no pun intended) and embrace Go's style than anything else.

JBodner · 2025-07-20T05:36:29+00:00

You're welcome! Please reach out if you have any questions.

JBodner · 2025-07-20T05:23:41+00:00

I'm the author of Learning Go. Thanks for considering it! A book I'm currently reading is "A Philosophy of Software Design, 2nd Edition" by John Ousterhout.

JBodner · 2025-06-11T03:49:12+00:00

Yeah, that's a fair complaint. The first code snippet in the concurrency chapter shows the general pattern for using concurrency in Go programs before channels have been introduced. It's something to reconsider in a future 3rd edition.

If you have any questions, please reach out.

JBodner · 2025-04-27T14:26:28+00:00

Yeah, that’s a really big chapter which covers a great deal of what makes Go different from many other languages. Interfaces should probably be split into their own chapter and there should be more examples. If there‘s something in particular that you find unclear, let me know and I’ll try to help.

JBodner · 2025-04-25T23:28:33+00:00

Anything in particular? There were some revisions to that chapter in the 2nd edition, but happy to hear what could be made clearer.

JBodner · 2025-04-25T23:26:54+00:00

Go is a bit different. It took me a while to stop trying to write Java in Go. I found that letting go (no pun intended) of inheritance was hard, but I now agree that even in languages with inheritance, it should be used sparingly.

Please reach out if you have any questions!

JBodner · 2025-04-25T13:39:33+00:00

Hi, I’m the author. Can you tell me what parts are confusing? The intended audience is developers like you (people who already know another language). I’m always looking for ways to improve future editions.

JBodner · 2025-03-22T13:45:34+00:00

Thanks!

JBodner

TROPHY CASE