This article appears to be focused on running many components on a single computer under the same process tree. Perhaps a better title would be "No more DSLs: Implement and deploy microservices as a monolith".
>Functionality for distributed execution and monitoring is shared through libraries rather than by delegating to external orchestration systems, making a single-program system completely self-contained.
and this section in the examples: http://catern.com/caternetes.html#thread
With the emphasis on distributed systems, I was waiting to see how the approach would help synchronization, replication, network dependencies, etc. But all the examples show calling other services as functions or spawning new processes. At the end orderd starts listening for requests, but I don't see any example in the article where the example program talks to another computer in the system. Perhaps I am missing something?
Nope. As the second paragraph talks about, there are other tools too (distributed languages) which also let you write a single program which is distributed. It's very common really - if you've ever written a shell script which performed some operations on another host with ssh, you've written a distributed program.
This is just another way to write a program which performs distributed operations, like using a distributed language or using ssh. (Well, rsyscall is the way to do that, this article is about an application of doing that, actually...)
Anyway there is overlap between the two terms so strictly speaking the author is not wrong. But is anything with threads a distributed system? If so I built many of them, even with Python .
https://en.wikipedia.org/wiki/Concurrency_(computer_science)
>An rsyscall.Thread may operate on a local or remote host, or inside a container or VM, or on other kinds of nodes, depending on how the rsyscall.Thread was produced...
>All distributed operations are performed by method calls on rsyscall.Thread objects.