I found a great line in Charles Blooms blog.

More generally, this programming pattern of finding clever complicated ways to hide the fact that your systems are overly bloated and slow is just not the win. You will only make the failure cases less common but more ugly.

This is exactly one of the main problems with a lot of D code I see day to day.
(Which is mostly poor attempts to spend up the DMD compiler.)

On Monday, 15 November 2021 at 21:24:20 UTC, Stefan Koch wrote:

In applications, Phobos or the compiler? Maybe some examples, so we have something to discuss?

On Monday, 15 November 2021 at 21:24:20 UTC, Stefan Koch wrote:

More generally, this programming pattern of finding clever complicated ways to hide the fact that your systems are overly bloated and slow is just not the win. You will only make the failure cases less common but more ugly.

This is why I like the Erlang philosophy.

On Tuesday, 16 November 2021 at 09:32:41 UTC, Imperatorn wrote:

More generally, this programming pattern of finding clever complicated ways to hide the fact that your systems are overly bloated and slow is just not the win. You will only make the failure cases less common but more ugly.

I am not familiar, what are you referring to?

On Tuesday, 16 November 2021 at 12:14:12 UTC, Stefan Koch wrote:

More generally, this programming pattern of finding clever complicated ways to hide the fact that your systems are overly bloated and slow is just not the win. You will only make the failure cases less common but more ugly.

Probably referring to:

Erlang has “fail-fast” philosophy that means processes do what they are supposed to do or fail. i.e. Process must obey single responsibility principle. It should be possible for one process to detect failure in another process and we should also know the reason for failure.

On Monday, 15 November 2021 at 21:24:20 UTC, Stefan Koch wrote:

More generally, this programming pattern of finding clever complicated ways to hide the fact that your systems are overly bloated and slow is just not the win. You will only make the failure cases less common but more ugly.

I would say it resembles the core of commercial development quite good ;)

But I think it's the problem of legacyness, ugly workarounds are cheaper to implement than to solve the underlying problem.