I suppose this article is about programming rather than software engineering but at the same time, I find there are a lot of these articles with heavy emphasis on code. I'd much rather people who want to improve their abilities keep an eye on architecture, and I thought the article yesterday about Uber's reasoning for moving to MySql had some gems in the comments, like this one: https://news.ycombinator.com/item?id=12166585. The code is often secondary to the architectural choices. Get the architecture right, and the language or the quality of the code is frankly, a secondary concern.
The whole discussion (this and [1] and [2]) is very interesting. I find it that Uber is holding on the ACID guarantees of a relational DB so much, in a way that is clearly hurting them. IMHO it will do them a big service to break down the responsibility of such a DB into multiple distributed systems that can work on a global scale. For example, a distributed lock system can help them when they need transactions. If they keep moving from one relational DB to another, they are bound to hit problems of Availability because they are choosing very strong Consistency, and the CAP theorem says we can't have it all (Partition tolerance is required).
I suppose this article is about programming rather than software engineering but at the same time, I find there are a lot of these articles with heavy emphasis on code. I'd much rather people who want to improve their abilities keep an eye on architecture, and I thought the article yesterday about Uber's reasoning for moving to MySql had some gems in the comments, like this one: https://news.ycombinator.com/item?id=12166585. The code is often secondary to the architectural choices. Get the architecture right, and the language or the quality of the code is frankly, a secondary concern.