/dev/dump

The backstory here is that mostly I love the Go programming language. But I've been very dismayed by certain statements from some of the core Go team members about topics that have significant ramification for my concurrent application design.  Specifically, bold statements to the effect that " channels " are the way to write concurrent programs, and deemphasizing condition variables.  (In one case, there is even a proposal to remove condition variables entirely from Go2!) The Go Position Essentially, the Go team believes very strongly in a design principle that can be stated thusly: " Do not communicate by sharing memory; instead, share memory by communicating." This design principle underlies the design of channels, which behave very much like UNIX pipes, although there are some very surprising semantics associated with channels, which I have found limiting over the years.  More on that below. Certainly, if you can avoid having shared memory st...

Folks who follow me may know that Go is one of my favorite programming languages.  The ethos of Go has historically been closer to that of C, but seems mostly to try to improve on the things that make C less than ideal for lots of projects. One of the challenges that Go has always had is it's very weak support for versioning, dependency management, and vendoring.  The Go team's historic promise and premise (called the Go1 Promise ) was that the latest version in any repo should always be preferred. This has a few ramifications: No breaking changes permitted in a library, or package, ever. The package should be "bug-free" at master.  (I.e. regression free.) The package should live forever. For small projects, these are noble goals, but over time it's been well demonstrated that this doesn't work. APIs just too often need to evolve (perhaps to correct earlier mistakes) in incompatible ways. Sometimes its easier to discard an older API than to up...