Folks, we love that you comment, but as a reminder, please keep your comments civil, and always aim to add to the discussion. If you have nothing to add to the discussion, please refrain from commenting. Otherwise it takes a lot of effort to moderate the comments.

So I went on Wikipedia to refresh my knowledge of all the amazing things this man did for the software industry, and I realized he looks two decades younger than he actually is. Way to efffin go, Rob!

After my firm moved a not so trivial sized code base from C++ to Go, I can say that in my very humble opinion Go got a whole more right than wrong. the team that created Go (including, but not limited to, Rob Pike and Ken Thompson) are the giants that we stand on the shoulders of. When designing the language, it appears to me that they made design decisions based on first principles. Taking influences from C and Modula-2 was (again, in my very humble opinion) as opposed to object oriented languages created a language that didn't have the baggage that comes along with it.

Love listening to Rob.

Great talk. Thank you Rob.

For me, the major bloopers are allowing naked returns and weak enums. Had my share of bugs mostly due to those two things.

33:26 Rob Pike describes telemetry of google chrome.

Great talk, 14 years of progress

Nice to see a shout out on the gofmt slide

In the concurrency example at 13:20 if timeout happens, goroutines that didn't complete will be stuck, as writing to the channel will be blocked forever.

Lack of generics early on has created a lot of undesirable legacy code in the Go projects I encountered: * Excessive `reflect` package with `any` * Using text template to generate Go code * Using AST to generate Go code All of these should be rewritten with generics, but there are 50,000 lines of them.

Great Talk

When seeing "Gopher" and and greybeard like "Rob Pike" in the title, I thought of the old Minnesota link-hierarchy server.

I want the wallpaper from the beginning!

Thank you!

Nice to see Rob being honest but I expected this talk to be about the Go type system. It's less than optimal. It misses Enums built-in.

if you initialize a memory arena aren't you supposed to clean it up yourself instead of GC?

I'm glad he mentioned "Go 2" is no longer going to exist.

Is there any plan to fix what they got wrong?

Would be interested to hear more about introducing sum type (ie Rust style enum, or Haskell style data declarations). Especially around error handling using Option/Result sum types to handle nil/error values, along with some syntax to “bubble up” errors out of a function like Rust ? operator. I die a little bit every time I see any non trivial go code, and > 50% of the line count is `if err != nil { return err }` “But you should be explicitly handling errors!” Is the usual go community apology. Sure, if you actually handle them. If you’re just returning them for calling code to do something with them (probably just check for nil and return them again), that’s not “handling” them. And having nil at all is just a massive footgun that could have been eliminated. Then go doubles down on nil by having typed nils, so there are a bunch of edge cases where nil != nil. It’s like they heard nil was a billion dollar mistake, and said “You know what? Let’s aim for a TRILLION dollars!”

the overly strong dependence on git has been the bane of my existence

8:50 While Go is great, I would argue that there another language which is even better at it: Zig But then again, it's considerably younger.

** Strobe light warning ** (editor: some of us need this warning)

if err != nil go 🎊

Seriously. Passed and amazing opportunity for o ask some “trivial” questions

Honestly some of the go docs are still awful. Not as bad as a lot of the package documentation for a lot of packages like the AWS SDK for Go but that's not the Go teams fault

Go's biggest sin is being only moderately better than Java. It's no wonder C++ still plays a big role at Google, because Java already took over where C++ would have otherwise been used. The remaining cases where C++ is still used would not be written in Go for the same reasons it wouldn't be written in Java. I do have to say that Go is quite a pleasant language to use when it comes to working with binary formats. Just the right amount of succinctness and type checking.

26:54 Indeed, go's module system is it's one of the worst sides of it. It's way more better how node.js and rust handles that, when i struggle to understand go's module system i've experienced very big frustration.

I LOVE GO!

The existence of a design choice is the result of a lack of specification for the problem.

The thing is, "we are boring on purpose" gets really old after a decade. Now it looks more like an excuse for intellectual masturbation or just laziness.. I really don't think it has much to do with backwards compatibility either, a lot of cool things can be done while still maintaining backwards compatibility. Theres been so much innovation in the languages world over the past decade. I'll even agree that most are bad ideas or not compatible with go but there are a few good ideas there and even some that a compatible with go.. if not copying, they should at least inspire some action or innovation..

audience is so dead and clueless. god, there are so many questions, why making and working with dynamic libraries is so broken (still, 7? 8? years and counting), why not let people use the syntax that stdlib is using (for example creating a custom map type mymap[type]type that implements an rb-tree inside), what was the reasoning behind not allowing operator overloading and so on and so forth

I don't think that the person mainly responsible for most of what Go got wrong is in position to objectively say what it got right and wrong

Odin > Go 🔥🔥🔥

I just don't like the language named Go. It's not even unique. Go? Why is it called Go? Is it because it's fast? So unusual. What a name! 😅

Please add try catch

No disrespect to Go or Rob Pike, but try running the race condition checker on many popular Go projects. Ousterhout is still right.