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

31–40 of 59 posts

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

#31

Post by nine_k »

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.

JIT gives you almost native performance. AI rewriting tools give you none of the knowledge of running the thing in production. A couple of noticeable mishaps could cost more than halving your fleet saves.

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

#32

Post by rusk »

inigyou wrote: post #27
rusk wrote: post #8

Earlier quoted context omitted.

Stock markets and commercial Telecomms beg to differ

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.

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

#33

Post by RetroTechie »

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.

That's like saying money is only spent on sw/hw systems which rely on ever-growing compute capacity.

Reality: embedded systems are a thing. And there's (lots of!) money in that business too. There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out.

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

#34

Post by neonstatic »

inigyou wrote: post #26
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.

[dead]

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

#35

Post by vrighter »

nine_k wrote: post #31
kator wrote: 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.

JIT gives you almost native performance. AI rewriting tools give you none of the knowledge of running the thing in production. A couple of noticeable mishaps could cost more than halving your fleet saves.

better than native, sometimes, due to the ability to profile and do profile guided recompilation at runtime

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

#36

Post by gf000 »

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.

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 Java can just have you write ordinary blocking code and they will automagically turn into non-blocking.

For most domains Java has a richer "industry-strength" library ecosystem, and absolutely not even close observability tools. So not really sure what would one win for e.g. a typical backend service doing web and db requests.

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

#37

Post by stonogo »

rusk wrote: 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...)

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

#38

Post by mcculley »

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.

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

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

#39

Post by chasil »

randfur wrote: post #5

Do people actually believe these dot points or are they just out of scope for most applications to tackle beyond letting the user try again?

I have had a developer with anger issues expect 100% success with FTP file transfers, and anything that failed was 100% my fault as a Linux/Oracle administrator.

These FTP sessions were running over WANs connecting Pennsylvania, Iowa, and Tennessee.

I ended up writing him an "until curl ftp://...; do echo it failed again; done" loop which calmed that particular issue down.

I don't miss that guy, not even 1%. Good riddance.

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

#40

Post by Nicook »

rusk wrote: post #6
randfur wrote: post #5

Do people actually believe these dot points or are they just out of scope for most applications to tackle beyond letting the user try again?

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.

Post reply on HN