The Go Programming Language

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: [VIDEO]

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: [VIDEO]

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. [VIDEO]

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 [VIDEO] Rob Pike, Google Tech Talk

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. [VIDEO]

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 [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.

> 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" [VIDEO] I don't think that Google ever wanted to develop a new OS kernel.

Go has been announced as a systems programming language: [VIDEO] . After some backlash the slogan has been changed quietly.

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: [VIDEO]

When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language [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.

> 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. [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. [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." [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] [VIDEO]

> But looking at how adamant Go used to be on the whole "No Generics" stance What "no generics" stance? Ian Lance Taylor started working on generics before anyone outside of Google had even heard of Go and when the rest of the world found out about Go it was understood that they would come someday. "In short: not yet" — [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] [VIDEO]

Huh? First they said they would: [VIDEO] After a decade of nobody coming up with a solution that did turn to believing that Go would never be able to add generics. That is true. The air of defeat did become quite strong. But the Haskell guy did eventually came along to share his expertise and the rest is history.

> 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: [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.