17 Hacker News comments link this video. Each one links back to its thread.
ypavanNov 2009Recommends
From the Tech Talk PDF, it is mentioned that Robert Griesemer, Ken Thompson, and Rob Pike started the project in late 2007. Ian Lance Taylor and Russ Cox joined in 2008. And the goal, as they mention, seems to have the efficiency of a statically-typed compiled language with the ease of programming of a dynamic language but with - Safety: type-safe and memory-safe. Good support for concurrency and communication. Efficient, latency-free garbage collection. High-speed compilation. They are aiming at a lightweight type system with no implicit conversions and no more 0x80ULL. A good starting point is their FAQ page and also the tech talk at youtube: ▶ this video
in “Google Go: A New Programming Language That’s Python Meets C++” · View on HN
win311fwgAug 2026Cites it
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
in “Golang proposal: container/: generic collection types” · View on HN
win311fwgAug 2026Cites it
> 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.
in “Go 1.27 Interactive Tour” · View on HN
phireJul 2025Cites it
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
in “There is no memory safety without thread safety” · View on HN
Show 11 more comments
phireJul 2025Cites it
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
in “There is no memory safety without thread safety” · View on HN
9rxApr 2025Cites it
> 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
in “Problems with Go channels (2016)” · View on HN
hsn915Aug 2022Cites it
When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language ▶ this video I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.
in “I like Odin” · View on HN
legutierrJun 2015Cites it
If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major aspects of its design. It shouldn't be surprising that Go blows other systems out of the water in this regard. Here he is talking about it: ▶ this video
in “Three months of Rust” · View on HN
andralexAug 2014Cites it
Go has been announced as a systems programming language: ▶ this video . After some backlash the slogan has been changed quietly.
in “D for the Win” · View on HN
mseepgoodJan 2014Cites it
> it seems initially it was meant to be those kind of "systems" From the announcement talk: "And it's a systems language in the sense that we intend it to be used to write things like web servers" ▶ this video I don't think that Google ever wanted to develop a new OS kernel.
in “Using Rust for an Undergraduate OS Course” · View on HN
dexenFeb 2013Cites it
For performance of compilation . Go compiles crazy fast -- think two seconds for complete compiler and runtime on a notebook. This provides for rapid hack-compile-debug iterations. ▶ this video
in “Google Go: The Good, the Bad, and the Meh” · View on HN
mseepgoodSep 2012Cites it
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
in “Will Go be the new go-to programming language?” · View on HN
devrimDec 2010Cites it
thinking OOP as a solution may lead to an article like this whereas it merely is a vehicle. you may or may not use it. problems of OOP is explained in Go Language video by Rob Pike*, however very intellectually stated arguments in this article are mainly false. ▶ this video
in “OOP practiced backwards is "POO"” · View on HN
allenbrunsonNov 2009Cites it
programming languages influence how you think about programming to such a degree that it's difficult to reason objectively about them. it's rare for me to watch long videos, because they are information-poor for the time investment, but i watched rob pike talk for an hour about go this evening. a lot of it is really interesting, but a lot of things about the syntax made me think: ow, that's going to be painful for me if it becomes successful. rob's talk: ▶ this video
in “Why I'm not very excited about Go” · View on HN
JeanPierreJun 2013Critical
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.
in “Replacing Clever Code with Unremarkable Code in Go” · View on HN