This was a really good read from the horses’ mouths. It definitely fits my experience: regardless of the language itself, the short build times, good standard library, great tooling, gofmt, approach to dependencies, ease of cross-compilation, “just copy the binary” deployments … this tooling is really a big part of Go’s appeal.
That said, I think they’re underselling the language itself a bit. I love Go’s unique approach to interfaces (“static duck typing”) and simple type system (I think of it as the anti-Scala). The simple language with few keywords and a short, readable spec. Reduced boilerplate with no explicit public keyword, the := declare-and-assign syntax, and syntax for things like string slicing and map lookup/assignment. I do think error handling boilerplate could be improved, but at least it’s simple and explicit.
I’m somewhat surprised the article says that “we left any form of generics out of the original language”, because Go has always had a “form of generics” with its builtin map and slice and channel types: map[K]V, []T, chan T. Go always had generic collections, you just couldn’t define your own.
It’s curious they don’t emphasize Limbo from Bell Labs though it’s cited in the bibliography and obliquely mentioned in passing. I perpahs misunderstood it to very much be a Bell Labs thus pre-Google-branding early Go.
Go borrowed ideas from Newsqueak, Alef, and Limbo, but it’s very much its own language, started from scratch at Google. The main thing all these language have is channels and some kind of lightweight thread. Limbo had low-latency garbage collection, which definitely helped us believe that was possible for Go too. And it was the first of the three to add preemption to the lightweight threads. But beyond that, there’s not a lot in common.
Limbo’s module (package) system was dynamically loaded and had separate API definitions and implementations. Strings were handled quite differently. There was nothing like Go’s interfaces. No built-in maps. (It did have built-in linked lists.) Slices were not the same. And the implementation of course was very different from Go: a JIT’ed portable bytecode language inside a virtual machine running its own virtual operating system.
This was a really good read from the horses’ mouths. It definitely fits my experience: regardless of the language itself, the short build times, good standard library, great tooling, gofmt, approach to dependencies, ease of cross-compilation, “just copy the binary” deployments … this tooling is really a big part of Go’s appeal.
That said, I think they’re underselling the language itself a bit. I love Go’s unique approach to interfaces (“static duck typing”) and simple type system (I think of it as the anti-Scala). The simple language with few keywords and a short, readable spec. Reduced boilerplate with no explicit
publickeyword, the:=declare-and-assign syntax, and syntax for things like string slicing and map lookup/assignment. I do think error handling boilerplate could be improved, but at least it’s simple and explicit.I’m somewhat surprised the article says that “we left any form of generics out of the original language”, because Go has always had a “form of generics” with its builtin map and slice and channel types:
map[K]V,[]T,chan T. Go always had generic collections, you just couldn’t define your own.I, too, like structural typing, but it isn’t unique to Go.
It’s curious they don’t emphasize Limbo from Bell Labs though it’s cited in the bibliography and obliquely mentioned in passing. I perpahs misunderstood it to very much be a Bell Labs thus pre-Google-branding early Go.
Go borrowed ideas from Newsqueak, Alef, and Limbo, but it’s very much its own language, started from scratch at Google. The main thing all these language have is channels and some kind of lightweight thread. Limbo had low-latency garbage collection, which definitely helped us believe that was possible for Go too. And it was the first of the three to add preemption to the lightweight threads. But beyond that, there’s not a lot in common.
Limbo’s module (package) system was dynamically loaded and had separate API definitions and implementations. Strings were handled quite differently. There was nothing like Go’s interfaces. No built-in maps. (It did have built-in linked lists.) Slices were not the same. And the implementation of course was very different from Go: a JIT’ed portable bytecode language inside a virtual machine running its own virtual operating system.
For a cross-reference: https://seh.dev/go-legacy/
As pragmatic as Go is, I always wonder why it insists on making unused variables an error instead of a
go vetdiagnostic.