Less is Exponentially More (2012)

I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation. On the other side, take a look at your…

Rob Pike's confusion about why C++ programmers didn't want to move to go is partially explained by his focus on a particular problem domain at the time Go was being developed. Google in those days was primarily concerned with writing highly concurrent request processing software, and at that time the vast majority of that software was written in C++. Writing highly concurrent C++ in the days before the language had things like lambdas, std::function, std::future, etc was definitely gross. In…

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is?…

> name: 'go'. you can invent reasons for this name but it has nice properties. it's short, easy to type. tools: goc, gol, goa. if there's an interactive debugger/interpreter it could just be called 'go'. the suffix is .go. I'm surprised that the ability to search easily didn't come into their consideration, given ... well, it's Google. I'm not a Go developer, so I have no idea of how big of a problem this is, but the fact that there…