Live data from Hacker News

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

blog.apnic.net

41–50 of 59 posts

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

#41
post #22

Earlier quoted context omitted.

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.

I encourage my competitors to refactor a working codebase into a different language.

Ideally by adopting a different architecture at the same time so they fix everything that is troublesome in their existing product!

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

#42
post #37
post #9

This article reiterates a lot of the Wikipedia stuff, while contradicting the main extant source which is Deutsch himself ( https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-... ). Nobody really knows who wrote the first four fallacies. They were just floating around it is Deutsch who pinned them down and it was Gosling’s endorsement that made them into the shibboleth that they are.

Deutsch speculated it was "either Bill or Dick Lyon" (sic) ( https://web.archive.org/web/20040203202935/http://www.aladdi... ) but there has been speculation he meant Tom Lyon, who worked there at the time. Gosling had them hosted on his website for a long time ( https://web.archive.org/web/20021206065457/http://java.sun.c... )

Yes, he didn’t really know. So the original attribution is fuzzy

Gosling still has them on his present day site https://nighthacks.com/jag/blog/401/index.html

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

#43
post #32
post #27

Earlier quoted context omitted.

Is every business a stock market and commercial Telecomm?

> Making money and being highly available are different goals. These are large, highly profitable vertical markets. The above remark is demonstrably foolish and ignorant.

Can you make money without being highly available?

Can you be highly available without making money?

And btw I've worked in both the industries you cite. It's hard to think of telecomms having amazing uptime when you have to write a restart script for a core security daemon because the sysadmin doesn't know how.

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

#44
post #40
post #6

Earlier quoted context omitted.

Perfect demonstration of the fallacies in action! If you were used to developing applications on a self contained platform you would think something like “sure, if it fails the user can try again” On a distributed system the user can only try again if the platform has remained stable, the failure is transient (*) and they have (crucially) have been given the information to retry. The platform that provides a stable e…

>we'll just add this feature on as some async verification since it takes a while, then make the original update wait in some weird state for it to finish. Later, when users are confused at failures and weird states. >ok now lets build a new system that tries to gather all this information on updates in "weird states" and let users fix them! simplified example, but nightmare.

If you’re exposing system concerns mixed in with application code you’re either doing it wrong or using some outdated architecture.

Either way, it’s no excuses for shipping slop, which is what you’ve done it your software only works under limited idealised circumstances

TFA is for you

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

#45
post #30
post #28

Earlier quoted context omitted.

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 network…

The more interesting thing on Windows would actually be COM, which is something like Java interfaces but for native code, that are optionally cross-process.

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

#46
post #32

Earlier quoted context omitted.

> Making money and being highly available are different goals. These are large, highly profitable vertical markets. The above remark is demonstrably foolish and ignorant.

Can you make money without being highly available? Can you be highly available without making money? And btw I've worked in both the industries you cite. It's hard to think of telecomms having amazing uptime when you have to write a restart script for a core security daemon because the sysadmin doesn't know how.

[flagged]

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

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

It's more niche but also underestimating the impact of using SIMD in places where it makes sense. Especially in higher level, interpreted programming languages where the overhead for each iteration is much larger than the few assembly instructions it would take to perform that iteration without vectorization in a low level language.

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

#48
post #45
post #30

Earlier quoted context omitted.

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 network…

The more interesting thing on Windows would actually be COM, which is something like Java interfaces but for native code, that are optionally cross-process.

In my recollection COM became ActiveX which fell down the distributed objects hole along with CORBA because it embodied many of these fallacies.

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

#49
post #36
post #22

Earlier quoted context omitted.

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.

Unless you are doing something very specific where rust is truly the best choice, I have to disagree. Rust has overly strict locking (otherwise it couldn't determine safety) that makes certain concurrent algorithms harder to implement, its concurrency model is significantly more complex (for an absolutely good reason, it's a low-level language where the developer should be in control), meanwhile for many applications…

> not really sure what would one win

Internet pointz

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

#50
post #27
post #8

Earlier quoted context omitted.

Stock markets and commercial Telecomms beg to differ

Is every business a stock market and commercial Telecomm?

Asymptotically, every billing system is a stock market and telecom. ;-)

My biggest career horror was realizing how much the medical informatics concepts have been structured around billing and insurance rather than scientific, biomedical requirements.

Post reply on HN