Rob Pike (co-author of Go) said:
OOP languages frequently shift the focus from data structures and algorithms to types.
I haven’t tried Go yet, but this resonated with me as a Clojurist. Managing all your state as classes and objects almost always, instead of just designing some nice mix of data structure for it. And then writing all your functions as methods restricted only to the data on that object, gets in the way of coming up with wholistic algorithms over data structures.
He also said:
If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. […] It is a language of composition and coupling. The obvious example is the way interfaces give us the composition of components. It doesn’t matter what that thing is, if it implements method M I can just drop it in here.
Which as a Clojurist also resonated with me. Apparently (correct me if I’m wrong), in Go, interfaces are implicits and match only by name, not by type. In effect, this sounds a lot like what a dynamic type system gives us with regards to polymorphism. Who cares, if the thing fits at run-time I’ll use it. And that idea of composition just by functions and only based on their name, it’s very much something I agree with and one of the things I like about Clojure.
He said as well:
Another important example is how concurrency gives us the composition of independently executing computations
Go has CSP, like Clojure core.async. So this obviously resonates with me as well. But especially the broader idea here, that concurrency is about composition of independently executing computations. Clojure brings other concurrency controls, like immutability being the main one, and I think a good aspect to consider is how would you compose code running concurrently or in parallel? Having things be immutable help, CSP helps, agents help, refs help, atoms help, etc. It’s all about composition, I like that.
And another thing he said:
Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I’m a philistine about types but I’ve never found that model particularly expressive. […] Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type’s parent, whether A inherits from B or B from A. Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision. […] I believe that’s a preposterous way to think about programming. What matters isn’t the ancestor relations between things but what they can do for you.
This also resonated with me. In fact, I think it’s one challenge for people coming to Clojure sometimes, they miss this “type driven development”. And kind of don’t know how else to design their code.
He finishes by saying:
If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. […] What you’re given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you’d write in some of those other languages, but it’ll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer.
Now I feel you could literally replace Go with Clojure here and it be just as applicable.
I found it quite interesting, and actually was surprised at how much similarity in the philosophy of Go it seems Clojure shares. Now there are some other things in the article I don’t resonate as strongly or would slightly disagree with, but to some extent those seem to be more about the best way to create a language that applies these philosophies and ideas I just quoted. For example, I’d rather everything be an expression, I’d favor functional programming over procedural, and I’d want a Lisp syntax and power to extend the language semantics of my own with macros.
Anyway, I recommend it for reading, and am interested in hearing other people’s thought on this.