The monument of human stupidity

The most embarrassing of it all is the idiotic insistence on piling up more and more imperative crap on designs based on fundamentally unsound principles, both in the language design and the implementation.

The 2000s boom of notoriously crappy Java literature ruined the book industry forever as a side effect. Now they just print 300+ pages amateur blogposts.

A mutable state cannot be guaranteed to remain consistent in an multi-execution (multi-processor) environment. Only in single-threaded contexts.

This is just an evolutionary rejection of an in principle flawed set of arrangements - this cannot be stable.

Imperative crap lacks true cell “membranes” or non-leaking abstraction barriers, as well as immutability.

Imperative OO crap makes things even worse by providing unsound /“encapsulation” of a mutable state - a flawed cell “membrane”. These “cells” are just fundamentally broken.

Every method of every object must be designed to be re-enterable (and have mandatory locks around the state), but, of course, most of the code are not.

Java, being an imperative OO clustefuck with inconsistent typing (even in C++ - the JVM’s implementation language!) and shared multi-threaded design, is doomed to always be buggy and to be exponentially slowing down in its improvement (already happened) due to not being able to fix concurrency flaws and subtle bugs - too much time and resources will be spent in vain.

Unrestricted (arbitrary) overwriting of memory locations (from another thread or a process), which we call “sharing”, cannot be fixed in principle.

There is a combination of features that cannot be combined in principle - objects, destructive over-writing, multi-threading, shared stack and exceptions. There is no way out from this and what we have is the sunken costs fallacy.

Exceptions break the shared stack, multi-threading and destructive updates break an internal state of objects in a random, non-reproducible way. Even if your code takes some care, your dependencies all the way down, do not.

There is another principle. One cannot make a truly non-blocking (asynchronous) system with blocking (synchronous) primitives. Hardware and Erlang guys knew that. A method calls is not an adequate primitive.

Java is indeed the monument to human stupidity, and “shared mutable state” is manifestation of ignorance and the cause of suffering.

First, one cannot model proper asynchronous /message-passing using calls to methods within a single thread, because a method call implies a transfer of control with a return address on the stack (a suspension). It requires sending to a “port” - a proper RPC.

It is not even possible to implement proper share-nothing abstractions (not even a single byte, leave alone a per-thread call-stack) with are required for multi-processing in an environment which combines imperative destructive updates, sharing and multi-threading. Other people’s crappy library code will fuck up everything.

Somehow not surprisingly, Java is the second most popular language (after fucking Javascript), LMAO, while it is just a corporate PHP turned into a holy catholic Church.

There is an account for actual experience I have right now.

I have some simple projects using Akka and Scala 3. Everything compiles and runs, except that it prints nothing.

I tried a Scala 2 setup and copied and pasted exaples from the site. Everything compiles, runs but ptints nothing.

Here is a short list what can go wrong (given that Akka is an advanced async and nio libray).

• the gcc 12.2.1 may not compile openjdk-17.0.5-p8 correctly
• this may happen only with certain optimizations enabled
• openjdk-17.0.5_p8 may have subtle async or nio bugs
• these bugs may only materialize with compiler optimizations
• maybe it networking has does not work due the new kernel
• or it is just Scala. Both 2 and 3? Why not.
• maybe scala breaks on the latest JDK 17, not being tested on it
• maybe it is Akka on the latest JDK, because the code uses advanced APIs
• it could be that only the latest versions of akka are affected
• any combination of the above.

So, when someone will say to you JVM is a stable, mature, battele-tested platform on which everyone runs - return to this page and reread it.