The Go Programming Language

The "Talks and Videos" page ( [link] ) is outdated as well. Here's my personal list: Why Learn Go? [link] Short interview with Rob Pike, OSCON 2012 Get Started with Go [link] Andrew Gerrand A Tour of Go [link] Russ Cox Go Concurrency Patterns [link] Rob Pike, Google I/O 2012 Goroutines, Channels Meet the Go Team [link] Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012 Computing Map Tiles with Go on App Engine [link] Chris Broadfoot, Andrew Gerrand, Google I/O 2012 Go in Production [link] Gustavo Niemeyer, Google I/O 2012 Go: Code that grows with grace [link] (Contains some audio glitches) Andrew Gerrand Interview with Rob Pike [link] Rob Pike, GOTO Conference Lexical Scanning in Go [link] Rob Pike Cuddle, A Go AppEngine Demo [link] Andrew Gerrand Building Integrated Apps on Google's Cloud Platform [link] Andrew Gerrand, Google Developer Day Japan 2011 Real World Go [link] Andrew Gerrand, I/O BootCamp 2011 Go: it's that simple?! [link] Andrew Gerrand, OSDC 2011 Practical Go Programming [link] Andrew Gerrand, FOSDEM 2011 Writing Web Apps in Go [link] Andrew Gerrand, Rob Pike, Google I/O 2011 Go Programming [link] Rob Pike, Google I/O 2010 Another Go at Language Design [link] Rob Pike, Stanford University Public Static Void [link] Rob Pike, OSCON 2010 The Go Programming Language [this video] Rob Pike, Google Tech Talk

> The only things I can think of which Go did that seemed blatantly wrong in that era would be the lack of generics and proper enums. Typescript added "improper" enums several years later. Which is especially interesting as it is the one feature in Typescript that doesn't map directly to Javascript. I'm not sure even that one was the settled science back then. Generics were well established at that time, but that one didn't escape the Go authors. From day one it was explicitly called out as a feature Go should have, but that they hadn't figured out how to integrate it. [this video] Despite Taylor's admirably insistent efforts to find a solution (with 8+ proposals to his name, dating back to before Go was released to the public!), it ultimately required convincing an outside expert to lend a hand. > I know others find the type system lacking It may be lacking by today's standards where types are all the rage, but at the time we should also remember that it was the case that types simply weren't cool. People had grown tired of "doing XML sit-ups" and had fully embraced dynamic languages in reaction to that. Go was built in that time, for that time, explicitly intending to be a language that felt like a dynamic language but with the performance advantages of a static language. [this video]

Keep in mind that the 2012 presentations dates to 10 months after Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention. I'd argue the definition was already changing by this point. It's also possible that Go was already discovering their version of "Memory Safety" just wasn't safe enough. If you go back to the original 2009 announcement talk, "Memory Safety" is listed as an explicit goal, with no carveouts: "Safety is critical. It's critical that the language be type-safe and that it be memory-safe." "It is important that a program not be able to derive a bad address and just use it; That a program that compiles is type-safe and memory-safe. That is a critical part of making robust software, and that's just fundamental." [this video]

True, "have a garbage collector" was never the formal definition, it was more "automatic memory management". But this predates the work on Rust's ownership system and while there were theories of static automatic memory management, all practical examples of automatic memory management were some form of garbage collection. If you go to the original 2009 announcement presentation for Go [1], not only is "memory-safety" listed as a primary goal, but Pike provides the definition of memory-safe that they are using, which is: "The program should not be able to derive a bad address and just use it" Which Go mostly achieves with a combination of garbage collection and not allowing pointer arithmetic. The source of Go's failure is concurrency, which has a knock-on effect that invalidates memory safety. Note that stated goal from 2009 is "good support for concurrency", not "concurrent-safe". [1] [this video]

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions. As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet" What was surprising is that after Go was released as an open source project, nobody across the whole wide world ever came up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics. [1] [this video]

> Am I the only one who’s absolutely shocked that Go finally is embracing generics? Yes. Everyone else knows that they were always expected to be included at some point, as told when Go was first announced to the world: [this video] > So what changed? Philip Wadler, of Haskell fame, decided to help? This was well publicized on HN at the time. > I’m not buying the “it took us 20 years to understand how to do it correctly” argument If I recall correctly, Pike suggested that they never did come to that understanding without the outside help. I can understand why you are surprised that it took 20 years for someone with the right expertise to show up. You can get the sense in the above announcement that even the Go team thought that open sourcing the project would attract the right talent far, far earlier. But, now that we have hindsight, we can see that all the experts on HN who could have been the missing positive contributor were too busy complaining that Go didn't have generics. There wasn't enough time left for them to lend a hand. There are only so many hours in the day.

I would like to add on to this: Generics may not be the correct solution, but I would really like a way to make collections which are general enough to be used by any datatype. As of now, I cannot do that without doing the typical `interface{}` approach. The built-in data structures + channels are able to handle this, but if I just want a set of elements, what do I do? Make a `map[foo] bool`? If I see such a piece of code in an unfamiliar code base, I have no idea whether to test for key existence or whether I have to test whether the bool is true. A generic set would leave me puzzled and type unsafe[1]: What types could possibly exist in this set? A set of foos is not that hard to comprehend, and is in fact very much more straightforward to understand than a generic set, which in unfamiliar code may contain anything, or a mapping from foos to bools. [1]: Rob Pike mentions in [this video] that type safety is of high importance for Golang, but how does one achieve that if all the different datatypes I implement/need use `interface {}` where I have to cast all values afterwards? That seems very type unsafe, from where I stand.