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: ▶ this 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" — ▶ 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

Huh? First they said they would: ▶ this 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: ▶ 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.

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

> 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

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.

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

Go has been announced as a systems programming language: ▶ this video . After some backlash the slogan has been changed quietly.

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