Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

21 years and counting of 'eight fallacies of distributed computing' (2025)

blog.apnic.net

Post reply on HN
Print view View original

21–30 of 59 posts

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#21

Post by rusk »

adornKey wrote: post #16
jffhn wrote: post #12

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.

Today even tiny CPUs are really fast. Locally you have to mess up badly to run into trouble. But of course people will do exactly that... 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 ind…

Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.

Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#22

Post by kator »

gf000 wrote: post #17
mojuba wrote: post #14

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...

Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#23

Post by anax32 »

mrkeen wrote: post #15

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…

* You will have logs

Always gets me

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#24

Post by master_crab »

There needs to be a distinction - because people are making an honest conflation - between distributed computing and cloud computing. The list in the article applies to both, but the limits and performance variability can apply quicker - and with more effect - in the cloud.

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#25

Post by inigyou »

kator wrote: post #22
gf000 wrote: post #17

Earlier quoted context omitted.

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...

Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.

You hate Java so much you think AI code is better? You're not even getting memory safety from the deal, because Java already has it.

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#26

Post by inigyou »

zephen wrote: post #3

On the one hand, the list isn't wrong. On the other hand, more fortunes have been made by assuming that physics will catch up (closely enough, anyway) to computational needs, than by assuming that every byte and every cycle and every nanosecond matters.

In 2026 Moore's law has mostly stopped. My computer from 10 years ago still has acceptable performance today. My computer from 15 years ago would struggle a bit but still get the job done. This is nothing like the 90s where you actually could wait two years for all of that year's conceivable performance problems to be solved.

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#27

Post by inigyou »

rusk wrote: post #8
shermantanktop wrote: post #4

Earlier quoted context omitted.

Making money and being highly available are different goals.

Stock markets and commercial Telecomms beg to differ

Is every business a stock market and commercial Telecomm?

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#28

Post by inigyou »

rusk wrote: post #11
aussieguy1234 wrote: post #10

This is highly relevant to the recent craze over microservices, which has settled down now (after un-neccasarily complicating systems at multiple companies).

Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …

Aren't Windows's named pipes very similar?

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#29

Post by bayindirh »

mrkeen wrote: post #15

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…

Another one from my experience:

* Hardware is cheap.

So many services and daemons are running on your system and most of them believe that they have all the hardware for themselves, while the opposite is true. Designing to capitalize whole hardware while they are other processes which are fighting to do the same never ends well.

OTOH, being a good citizen on a crowded system makes life for everyone better. Both maintenance and performance-wise.

Re: 21 years and counting of 'eight fallacies of distributed computing' (2025)

#30

Post by rusk »

inigyou wrote: post #28
rusk wrote: post #11

Earlier quoted context omitted.

Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …

Aren't Windows's named pipes very similar?

I believe so.

I don’t think either that or domain sockets are quite as ubiquitous as TCP sockets though.

The issue I see with domain sockets is that although they may be supported for example by spring, you can’t rely on a consistent cross platform experience which is perhaps (anachronistically?) a core ethic of the Java community.

I would favour domain sockets as to make a component go from being embedded to networked would require a small but significant implementation step.

But established best practice unfortunately disagrees with me.

Post reply on HN