11–20 of 59 posts
This is highly relevant to the recent craze over microservices, which has settled down now (after un-neccasarily complicating systems at multiple companies).
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
* Your system is not a distributed system
Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers
* Your DB's ACID transactions are sufficient for distributed thinking
An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage.
* Your DB's transactions are ACID
Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
Most real world problems still can be solved with 32-bit software, so the last ~20 years running out of RAM always counted as "using defective hardware". AI workloads now make things interesting again, but it's not that easy to hit the ceiling with real world workload.
Cache is indeed very important. Optimisations like that are gone when you go for distributed computing. Sometimes adding a single nop can do wonders. I wonder how many percent of developers have something in their toolbox to profile for that.
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
- The computer is plugged to an infinite source of unlimited power This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
https://www.sciencedirect.com/science/article/pii/S016764232...
A couple more that don't seem to be represented there. No mention of cause and effect, or the order in which different nodes perceive things happening? Anyway here's three which I think might be more relevant to designing and building software: * Your system is not a distributed system Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's i…
8. The network is homogeneous
Often misconstrued as a recapitulation of “there is one administrator”
A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
- The computer is plugged to an infinite source of unlimited power This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
Earlier quoted context omitted.
- The computer is plugged to an infinite source of unlimited power This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency. https://www.sciencedirect.com/science/article/pii/S016764232...