bitwiseand

If a system performance is profiled as being dominated by 80% A , 19% B and 1 % C. I'd focus on working on A first to get maximum gains. Amdahl's law gives you the backing as to why you should do this.

As a real world example, if an operation involves a network call and you see the RTT dominating the time. You may want to think of ways to avoid the call (caching etc..) if possible to get really good gains.

I fully agree with you. It's not just infrastructure but also devices and the surrounding ecosystem. I work in this space and let me assure you there are many jobs with GREAT pay.

I"ll go on and make another bold claim. Focusing on lower level stuff and systems concepts lay an excellent foundation for designing complex systems regardless of the language used. Once you understand how a program is executed from the ground up i.e. right from the program counter to page table lookups to cache hits to cache coherency, all abstractions are easier to deconstruct and understand. I work up and down the stack and this has been my, quite possibly just anecdotal, experience.

Writing and designing code that is mindful of latencies (Amdahl's law). Temporal / Spatial locality, avoiding needless copies etc.. This approach needs to start from design and also follow into implementing the code. Moreover, this is done without compromising on readability.

A self-driving car, as proposed by Waymo and many others, in no way relies just on GPS. These beasts have fusion of many sensors with built in redundancy.

Technology improves and evolves. If it didn't you wouldn't be so reliant on Google Maps. We convince people of progress by a safe track record. Google maps may fail occasionally but more often than not it gets you to your destination at the estimated time.

Yes self-driving cars can't be "more often than not" safe. But starting with smaller areas and showing the difference it makes on people's lives and the environment can be a good start.

"There are only two hard problems in CS : 1. Naming things. 2. Cache invalidation. "

- Allow an unambiguous, never "played with", chronological timeline. Have a separate view that's your ML playground.

I disagree. The alternate to a vision you may not agree with is not having two visions. Use data to support one not both.

Thanks :)

Edit: I also wrote my comment because the article is beginner friendly. A lot of beginners will get the right idea about CAP once they go through comments and then back again to your article.

No need to be sorry. I liked the rest of the article. Thanks for that.

I liked the article but I feel the CAP theorem is again misquoted; it often leads to misunderstanding. From the article - "but they would still confront the reality of the CAP theorem: your system can be consistent, available, or partition-tolerant, and you can only pick two"

The CAP theorem states that in the event of a network-partition you have to choose one of C or A. More intuitively, any delay between nodes can be modeled as a temporary network partition and in that event you have but two choices either wait to return the latest data at a peer node (C) or return the last available data at a peer node (A).

Edit: Switched C and A

This is essentially same as processes sharing (via Page Table mapping) one .so file AKA Dynamic Linking :).