I quote Fowler's ancient First Law of Distributed Object Design: "don't distribute your objects".

Any distribution results in masked complexity and many hard to reason about scenarios even if the language or platform supports it transparently.

Ergo, just because you can doesn't mean you should, unless you want to discover them all, usually at an inconvenient point in the future when everything is broken and there's cash bleeding out of your org somewhere.

> don't distribute your objects

I guess people writing microservices or services connected via the Internet didn't get the memo.

I spend all day every day working with those.

I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution.

(Note I only work on non-google scale stuff where it is probably appropriate)

Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.

Honestly the rule I put on it nowadays is, if it doesn't have a logical boundary within the organization then it doesn't need to be a separate service.

If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.

sounds as bit like Conway's Law

Conway's law

The author of that rule explains that (well-crafted) microservices don't disobey that rule: https://martinfowler.com/articles/distributed-objects-micros...

Microservices aren't about distributed objects, they're about small services which communicate via explicit IPC (such as HTTP or gRPC).

Frankly, I completely disagree. There was a lot of research into distributed objects back in the 80s/90s; languages which allow objects to seamlessly move between nodes. And there's a very good reason IMO why that never took off. Communication between processes is always fallible and subject to blocking indefinitely, and when such communication happens implicitly and all over the place, the result is a disaster. IPC must be explicit, not implicit.

IPC must also be language-agnostic, which means serialization and deserialization, which means there will always be some manual "impedance matching" between your program's domain model and the IPC protocol's messages.

Could things be better? Sure, yeah, I guess. Languages with a single implicit event loop and with native support for JSON-like trees of values (such as JavaScript) will have an easier time than languages with neither (such as C++). But I don't think there's really some magical 10x better solution out there if only we had all "seen the light" and used SmallTalk.

> Communication between processes is always fallible and subject to blocking indefinitely

You speak as if you have never heard of Carl Hewitt's research, Erlang or Elixir before.

You mentioned SmallTalk, not Erlang.

I wasn't aware that Erlang did IPC implicitly.

Erlang puts communication across actors/processes at its core mechanism. Sending a message is as simple as adding two numbers. It is closer to Smalltalk than a lot of other programming paradigms.

The real issue is that Erlang is its own world. But you could also say IPC is its own world (does not work natively on the Internet, does not work on non-UNIX machines, etc.)

Erlang is being sneaky because an Erlang "process" is not the same thing as what the rest of call us a "process". As soon as Erlang needs to talk across real processes is runs into all the same problems. Now, admittedly, Erlang has a nice supervisor toolkit to help with this, but its still a real problem, even for Erlang.

"Real processes".

The point is UNIX is too low-level for communication primitives. Maybe it's time to research new paradigms? It's been 60 years.

Okay but then you're talking about designing a completely new kind of kernel which has a completely different concept of what a "process" is, which is quite far away from "we should've just used SmallTalk".

Besides, no matter how you design the system, there will be a categorical difference between communication which is expected to be fallible and communication which is expected to be infallible. The "communication" between a caller and a callee is expected to be infallible, for example. Communication between threads in a process (in the UNIX and Windows model) is expected to be infallible.

Communication between an app and a system service is expected to be fallible; at the very least, the system service has to expect that the app might misbehave in any number of ways, even if you argue that the app should expect the system service to be perfect.

Depends pretty much how those threads were started.

In Windows there are fun things like COM apartments, owner module scopes, local RPC, wrapping in-proc COM into DCOM remoting.

Apple and Google have similar local RPC features coupled with multithtreading.

I don't understand what you think depends on how threads were started.

An HN comment is not big enough to explain OS specific threading models across component systems, and dynamic libraries.

Or Java RMI, Jini, .NET Remoting, Tcl agents, or many others with similar approaches.

You mean OS/2 with Visual Age for Smalltalk and SOM?

It was great, SOM even supported meta-classes, but sadly we all know how it went down.

> communication should be as easy, for the programmer, as adding two integers

I agree wholeheartedly. But the real issue is that Linux doesn't have rich communication primitives (compared to, say, the NT kernel), so we've had to implement those in userspace, and so here we are with systemd and dbus being intertwined with each other and the rest of the desktop. It could have been better if the kernel provided a message bus or at least some primitives.

Even with richer kernel primitives, Apple, Google and Microsoft have learned that user space with process separation for IPC and OS extensions, is a much saner way than expecting developers to write code that doesn't randomly crash their hosts, including the kernel.

> We need another variation of the rule: "Any sufficiently advanced desktop operating system contains an informal, buggy implementation of half of Smalltalk"

How about: any sufficiently advanced desktop OS eventually turns into a buggy microservices system.

> even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that?

I usually output json if the output is hierarchical, or some simple size+block format if it is just fixed size column data.

You might want to look at how Apple's platform does it. If you use the high level API it's pretty straightforward.

https://developer.apple.com/library/archive/documentation/Ma...

(Not to be confused with the OG Mach messages!)

https://dennisbabkin.com/blog/?t=interprocess-communication-...

I think there are many problems with D-Bus, and there are better ways to send data to other processes. It is a useful feature, but I have different ideas about how it would be done, which I will describe below.

There is no bus names, interface names, and object path. Capabilities are used, and the program refers to the capabilities it has access to, to do any kind of I/O (and, the capabilities can be used for security, too).

The kernel does not know about data types; each message is a sequence of bytes and/or capabilities.

However, there is common conventions (which are the same for all computer types, so that programs on different computers and programs being emulated, can still communicate with each other) for data types.

It does not use Unicode, so there are no Unicode types (the main character code is Extended TRON Code, although 8-bit characters are also possible, including strings of arbitrary bytes/capabilities which can be used for any purpose).

It does not need the marshaling, authentication, etc like D-Bus uses. Other features of D-Bus also are not needed, and can be made simpler and faster.

The Command, Automation, and Query Language would make communication almost as easy as adding numbers together. (It can never be quite as easy (unless adding numbers is difficult), because communication is just a thing that is not as easy, anyways; but, it can be made almost easy.)

Actually, it is like a actor model in some ways.

(The above ideas are a part of an operating system design, which does not yet have a name, at this time.)

> (I am working on this space, as I have been obsessed with this question for a long while.)

What is your work on this space?

> even a number-crunching monolith written in high-performance C++ needs to communicate its result to the user or some other remote service. How many lines of code to do that?

I would think it depends what you need to communicate. Sometimes, I would expect, printf would do.