(root)/Notes/Notes/notes/go.md RSS
Go it's not bad; it's just not good --- https://yager.io/programming/go.html resource go at Google: Language Design in the Service of software engineering by Rob Pike --- https://go.dev/talks/2012/splash.article resource why go is not good, comparing design decisions in go to Haskell and rust --- https://yager.io/programming/go.html go contains a myriad of contradictory design decisions; examples include: go calls itself a systems language but has a garbage collector go has the imperativity and verbosity of c but the built-in dynamic arrays of python go is a modern language designed from the ground up but still uses nulls for failure conditions and c-style valueless statements for control flow go is a statically typed language but has a top ‹type---the empty interface---which defeats the purpose of type systems most of this can be explained by the fact that go is the result of language design in the service of software engineering: Go's purpose is therefore not to do research into programming language design; it is to improve the working environment for its designers and their coworkers. Go is more about software engineering than programming language research. Or to rephrase, it is about language design in the service of software engineering. --- Rob Pike --- https://go.dev/talks/2012/splash.article The key point here is our programmers are Googlers, they're not researchers. They're typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. --- Rob Pike --- https://news.ycombinator.com/item?id=16143918 It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. --- Rob Pike --- https://go.dev/talks/2012/splash.article a large portion of the go language was invented rather than discovered; examples include: `append`, `clear`, `delete`, `min`, `max` and `new` are all go built-ins --- https://go.dev/ref/spec#Built-in_functions `range` and `map` are hard-coded into the go syntax --- https://go.dev/ref/spec#For_range and https://go.dev/ref/spec#Map_types functions returning multiple values is a hard-coded feature; tuples don't exist in go --- https://go.dev/ref/spec#Return_statements `range` and `make` are hard-coded go built-ins. they only work on primitives and cannot be extended --- https://yager.io/programming/go.html and the rest of go is half-baked at best; examples include: go uses "zero values" to avoid uninitialized variables, which is a band-aid solution to a problem that should be solved at the type system level go has interfaces, which are a poor man's traits. and go interfaces are duck-typed, which is another shady decision go dares to list type inference as a feature, but all its type inference engine does is fill in the type of a variable in a declaration based on the value it's assigned go proudly uses pairs instead of special syntax for error handling, except that the way you do errors-as-values is to use the `Either` monad, not a product ‹type for the sake of confirmation bias, let's end with a few cherry-picked quotes: the go way is to half-ass things. the go way is to patch things up until they sorta kinda work, in the name of simplicity --- https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride [...] it becomes extremely hard to follow what any program is doing at a high level, because everywhere you look, you get bogged down in imperative code doing trivial data manipulation or error propagation --- https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang the closest thing to a flexible iterator keyword is building a wrapper around your data structure that returns a `chan` and then iterate over the `chan`, but that is slow, complicated, and bug-prone --- https://yager.io/programming/go.html
© 2026 Emilien Breton ← 🍁 →

Go

it's not bad; it's just not good --- https://yager.io/programming/go.html

resource go at Google: Language Design in the Service of software engineering by Rob Pike --- https://go.dev/talks/2012/splash.article

resource why go is not good, comparing design decisions in go to Haskell and rust --- https://yager.io/programming/go.html

go contains a myriad of contradictory design decisions; examples include:

go calls itself a systems language but has a garbage collector
go has the imperativity and verbosity of c but the built-in dynamic arrays of python
go is a modern language designed from the ground up but still uses nulls for failure conditions and c-style valueless statements for control flow
go is a statically typed language but has a top ‹type---the empty interface---which defeats the purpose of type systems

most of this can be explained by the fact that go is the result of language design in the service of software engineering:

Go's purpose is therefore not to do research into programming language design; it is to improve the working environment for its designers and their coworkers. Go is more about software engineering than programming language research. Or to rephrase, it is about language design in the service of software engineering. --- Rob Pike --- https://go.dev/talks/2012/splash.article
The key point here is our programmers are Googlers, they're not researchers. They're typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. --- Rob Pike --- https://news.ycombinator.com/item?id=16143918
It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. --- Rob Pike --- https://go.dev/talks/2012/splash.article

a large portion of the go language was invented rather than discovered; examples include:

append, clear, delete, min, max and new are all go built-ins --- https://go.dev/ref/spec#Built-in_functions
range and map are hard-coded into the go syntax --- https://go.dev/ref/spec#For_range and https://go.dev/ref/spec#Map_types
functions returning multiple values is a hard-coded feature; tuples don't exist in go --- https://go.dev/ref/spec#Return_statements
range and make are hard-coded go built-ins. they only work on primitives and cannot be extended --- https://yager.io/programming/go.html

and the rest of go is half-baked at best; examples include:

go uses "zero values" to avoid uninitialized variables, which is a band-aid solution to a problem that should be solved at the type system level
go has interfaces, which are a poor man's traits. and go interfaces are duck-typed, which is another shady decision
go dares to list type inference as a feature, but all its type inference engine does is fill in the type of a variable in a declaration based on the value it's assigned
go proudly uses pairs instead of special syntax for error handling, except that the way you do errors-as-values is to use the Either monad, not a product ‹type

for the sake of confirmation bias, let's end with a few cherry-picked quotes:

the go way is to half-ass things. the go way is to patch things up until they sorta kinda work, in the name of simplicity --- https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
[...] it becomes extremely hard to follow what any program is doing at a high level, because everywhere you look, you get bogged down in imperative code doing trivial data manipulation or error propagation --- https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
the closest thing to a flexible iterator keyword is building a wrapper around your data structure that returns a chan and then iterate over the chan, but that is slow, complicated, and bug-prone --- https://yager.io/programming/go.html