Thrilled by the announcement (blog.golang.org) of the portable #golang cloud APIs, but I feel the hard-fought lessons and wins from portability are being forgotten. It was an immeasurably great improvement when my code would run anywhere, unedited. Unix and C pioneered that (really dmr and scj).

The key thing to realize about this process is the need for convergence on a single standard. By analogy with how gofmt helped unify Go code, and hence the community, we need a single way forward for dependency management.

https://twitter.com/_rsc/status/1001567556887605248

I've been saddened by some of the fractious conversation on the topic lately, and while it's always difficult to make big changes, it's also always possible to do them better with the application of hindsight.

People keep quoting my '5 Rules of Programming'. Actually there were (and still are) 6 rules. Plus they need proper context. The original version was a handout (we used paper for things back then) for a graduate operating systems course at Princeton in 1987. The rules are the gist of the section on complexity.

/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code. When the Unix Support Group (development organization at Bell Labs) formalized everything, they gave it a long SCCS header, as they did every other file, and then needed to add "exit 0" at the end. The file was therefore infinitely larger than before.

I recently bought a @Cisco SPA112. Good product, but one unforgiveable flaw. To set it up, one connects over HTTP to an administration port. Standard stuff.

Whenever someone from Java or C++ or C# comes to Go, they look for "class", find "struct", and stop looking. #golang This misses two fundamental differences between Go and "traditional" OO languages. (But for "traditional" read "recent, mostly C-derived".)