mrkeen
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
systemMultiple 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 thinkingAn 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
ACIDYour 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.
|
> anax32
* You will have logsAlways gets me
|
> rusk
> No mention of cause and effect, or the order in
which different nodes perceive things happening?8. The
network is homogeneousOften 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.
|
jffhn
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.
|
> mojuba
- The computer is plugged to an infinite source of
unlimited powerThis 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.
|
> > gf000
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/a
rticle/pii/S016764232...
|
> > > kator
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.
|
> > > rusk
Indeed, the Java mobile platform had power
consciousness baked in 25 or so years ago.
|
> > rusk
Was big before the AMD athlon. First commodity GHz
processor was also the first to make obscene power
demands.
|
> adornKey
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 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.
|
> > rusk
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
|
> necovek
Disk never gets filled up.
|
jrpelkonen
In this instance latency must've been 10 years, per my
memory this paper came out in 1994
|
> rusk
According to Wikipedia it was first shown to Scott
McNeally, but according to Deutsch himself it was more
like 92...
|
zephen
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.
|
> shermantanktop
Making money and being highly available are different
goals.
|
> > rusk
Stock markets and commercial Telecomms beg to
differ
|
randfur
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?
|
> rusk
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 environment for the user to just try again has
been built on these principles.(*) there is one
administrator assumes it is within the user's power to
resolve the issue
|
rusk
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.
|
aussieguy1234
This is highly relevant to the recent craze over
microservices, which has settled down now (after
un-neccasarily complicating systems at multiple
companies).
|
> rusk
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 ...
|