Gopherfest 2015 | Go Proverbs with Rob Pike on HackerTube: recommended by 1 Hacker News commenter across 1 month, 2016–2026.
talk · intermediate · evergreen
Rob Pike presents Go Proverbs at Gopherfest 2015, a set of pithy aphorisms about Go design such as 'Clear is better than clever' and 'A little copying is better than a little dependency'.
HN treats it as the canonical source for Go proverbs, quoted in debates about dependencies, concurrency and simplicity.
“The proverbs are based on this awesome talk by Rob Spike”
16 Hacker News comments link this video. Each one links back to its thread.
Just in case you haven't read the footer text: The proverbs are based on this awesome talk by Rob Spike: ▶ this video And for new proverb ideas, you can open an issue here: [link]
in “Go Proverbs: Simple, Poetic, Pithy” · View on HN
You can only pick the parts that you need and aren't now exposed to a supply chain attack. You can also easily adapt the code to your needs easily, especially as your needs change. ▶ this video
in “SRGB↔XYZ Conversion (2021)” · View on HN
I don’t use stars to select dependencies FWIW. I look for age, CVEs and what other reputable projects depend on a repo. Also try to look for other signals, like if claims in the readme don’t match the implementation, or if there’s poor hygiene in the CI workflows. (And yes, I have gotten burned by an otherwise well meaning project with a supply chain vuln). As the saying goes “a little copying is better than a little dependency” (see: ▶ this video ).
in “A MitM proxy to see what your LLM tools are sending” · View on HN
"Clear is better than clever" is often touted as a key part of the Go philosophy: ▶ this video You can see the impacts of this in the language design. I find Go code to be boring and fairly easy to understand.
in “Don MacKinnon: Why Simplicity Beats Cleverness in Software Design [audio]” · View on HN
The first Go proverb Rob Pike listed in his talk "Go Proverbs" was, "Don't communicate by sharing memory, share memory by communicating." Go was designed from the beginning to use Tony Hoare's idea of communicating sequential processes for designing concurrent programs. However, like any professional tool, Go allows you to do the dangerous thing when you absolutely need to, but it's disappointing when people insist on using the dangerous way and then blame it on the language. ▶ this video
in “A million ways to die from a data race in Go” · View on HN
> This whole fiasco led me tho think .... do I even need this crate at all? 35 lines later I had the parts of dotenv I needed. "A little copying is better than a little dependency." - grab the parts that you need and then include the library only in a test to ensure alignment down the line, an idea I liked a lot. ▶ this video
in “Rust’s dependencies are starting to worry me” · View on HN
I am missing a very important one: Don't communicate by sharing memory, share memory by communicating. ▶ this video And lot's of others here: [link]
in “Rob Pike's 5 Rules of Programming” · View on HN
It's not so much part of the language but it's an idiom that is said by one of its authors ( ▶ this video ). "Code reuse" always has some non-compressible context: another import with a line in go.mod, another repo and dependency, which doc is going to be on another page/site, etc... It makes sense for big dependencies but not for small ones; the threshold where "small" becomes "big" being of course subjective.
in “Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency” · View on HN
"The bigger the interface, the weaker the abstraction." - ▶ this video Abstractions are good if 1) they can't be any smaller and are 2) covering well understood processes warranting them.
in “Redundancy vs. dependencies: which is worse?” · View on HN
I think manual three-way comparisons are very clear. But so is strings.Compare. For better or worse, copying code is a pretty normal thing to do in Go. See "A little copying is better than a little dependency." [0] [0]: ▶ this video
in “No safe efficient ways to do three-way string comparisons in Go” · View on HN
Agreed. The problem with mutex is that it's often hard to get right, since it's a low-level primitive for serializing access to shared memory, and it does not compose (cannot atomically lock two mutexes). CSP/Actor model simply takes the problem that mutex solves on the low level - concurrency - and makes the whole world concurrent-by-default, so that mutexes are not needed. Note the 1st Go proverb [0]: "Don't communicate by sharing memory, share memory by communicating." [0] ▶ this video
in “Safety and Performance – Threadsafe Datastructures in C++” · View on HN
You've also opened yourself up to bugs by allowing the map values to be "false". Using a "set's" value in an if statement doesn't make sense either, compared to if _, exists := something[item]; exists { ... } which is explicit regarding what's actually going on. As Rob said, "Clear is better than clever." ▶ this video I also don't want to be hunting down whoever creates a map[T]bool and doesn't leave a comment explaining it's a set ;) Hopefully we won't have to worry about it for much longer regardless, since I imagine we'll be using proper sets (with methods) some point in the near future.
in “Go 1.18” · View on HN
Vendoring is when you just copy the dependencies into your own source tree, like in a third_party directory. Personally, I'm a big fan of just taking what you need. A little copying is better than a little dependency[1]. [1] ▶ this video
in ““Shared libraries are not a good thing in general”” · View on HN
A constructor is just a function though... If I add a new field to a Java class and fail to add its initialization to the constructor, I have the exact same problem because Java initializes the field to its default value when the constructor is called. You are correct that every situation where the struct in Go is initialized "bare" would need to be addressed if a field is added, but Go considers this a feature, not a bug (and, conversely, considers "bare initialization" of structs at dozens of places in your code to be bad practice if that struct could ever grow new fields). If you're bare-initializing structs, you're comfortable using them in a "loosey-goosey" context where zero-initialized fields are permitted (or, better, useful... ▶ this video ). In Go, the issue of required structure is addressed by wrapping the struct in an interface and then providing a function in the package that can create an instance of the interface. Used in that way, you get something very similar to a Java class (though Go doesn't force you into the "everything is a class" paradigm that Java demands).
in “Leveraging the Go Type System” · View on HN
"For comparison, this Amazon VPC example may be worth checking out" It might be better to compare how to use the module/stack: - Terraform: [link] - Pulumi: [link] So as a user, can I configure this Pulumi VPC stack before it's instantiated? Or do I have to use the defaults first and then use the CLI to change things? Do these CLI changes then get placed into code, or just into state? Does that mean I'm now in a situation where the code doesn't match the state? Personally I find the Terraform configuration much easier to reason about, I see exactly where resources are declared just by scanning the file. (But I've also used Terraform a lot). Edit: Ah, maybe I have to configure it via this config.py file [1]? I appreciate what Pulumi is trying to accomplish, but that is certainly not a config format I'd like to be using. Maybe you could use HCL or YAML for it? ;) Edit 2: Another last thought, I think a lot of the mindset in Terraform comes from Go, where the proverb "A little copying is better than a little dependency" is pretty well adopted. Before I started writing Go as my main language I didn't appreciate that mindset, but after 5 years with Go I've found it more and more appropriate [2]. [1] [link] [2] [link] -- ▶ this video
in “Pulumi – Modern Infrastructure as Code” · View on HN
Indeed, taken from "Go Proverbs" - [link] "Concurrency is not parallelism." > Video: ▶ this video
in “Hello Go” · View on HN