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".)
The first is that it's not only structs: Any concrete type can have methods: ints, bools, slices, even funcs: golang.org/pkg/net/http/#…
But the more important idea is the separation of concept: data and behavior are two distinct concepts in Go, not conflated into a single notion of "class".
That is the insight (which goes all the way back to Smalltalk) on which the OO type system, including the interface model, is built.
Stopping at "struct == class" misses much of what makes Go work.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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).
But now there are a million incompatible Unix variants and clones.
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.
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.
So as things go forward, keep in mind that the community-oriented aspects of dependency management are arguably as important as the technical ones. It will take work on both fronts to succeed.
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.
Since then, there have appeared many corrupted version of those notes, with bad formatting or punctuation or what have you.
/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.
At some point, somewhere (not sure where) it was decided this was poor engineering, probably because the shell spends time reading that big SCCS header as a comment one byte at a time.