3 ms·
I don't understand which "DSLs" the author is arguing about. Also, as other have said, the author's definition of "distributed system" (here, basically a "mult
by phtrivier 5y ago
I don't understand which "DSLs" the author is arguing about.
Also, as other have said, the author's definition of "distributed system" (here, basically a "multithreaded" , concurrent system) seems to clash with the conventional definition (a system that has to involve multiple _computers_)
It is true that there is some overlap (having concurrency forces you to handle "some" of the problems with functional part of your program not being collocated on the same stack, you kinda have to introduce callbacks / promise / futures / actors / etc...)
But the moment you really have different programs o two machines (or , worse, two replicas of the same peogram on two machines), then I don't see how the single program would work / help.
Unless, of course, the "single program" is meant to be run as "one of the replica of the full system" ? Then I would love to hear the author's strategy for handling sharing info and workload between the replicas.
- catern 5y ago>Also, as other have said, the author's definition of "distributed system" (here, basically a "multithreaded" , concurrent system) What gives you that impression? The article talks multiple times about using libraries to manage distributed execution, and shows those libraries in use.