Názor k článku Clojure aneb jazyk umožňující tvorbu bezpečných vícevláknových aplikací pro JVM (3.část - funkcionální programování) od SB - Jasně, že implementace (řešení) OOP vždy nějak vypadá,...

Jasně, že implementace (řešení) OOP vždy nějak vypadá, rozumně s několika vlákny, protože je asi zbytečné dělat každému objektu vlastní vlákno, protože pro abstrakci pseudoparalelizace dostačuje, ale nemůžu spoléhat na kauzalitu/exklu­zivní přístup jen proto, že v realizaci pomocí např. jednoho vlákna to ono vlákno prostě musí udělat sekvenčně. Takže musím uvažovat abstraktně (to platí u OOM/OOP obecně) a synchronizaci garantovat jinak.
Na nízké úrovni je samozřejmě i OOP volání funkcí/spouštění strojového kódu, protože počítač to jinak neumí, neboli převod abstrakce na konkrétní řešení dané platformy, ale na vysoké úrovni je to skutečně zpráva, což je jakýsi dopis objektu, že má něco dělat, přičemž interpretaci celé zprávy řeší objekt. To je drtivý rozdíl oproti imperativnímu programování, kdo toto nepochopí, nikdy nepochopí OOP. Zpráva tedy je jakýsi objekt, ale ne ve smyslu OOP (odkazovatelný jako ostatní objekty).
Erlang neznám, ale z vašeho příkladu není jasné, jak moc abstraktní je samotný erlangový proces. Ale to nechám jiným, tomu fakt nerozumím. Z vašeho popisu je jasné, že Erlang využívá zcela jiný model výpočtu, kdy se určuje, co bude systémový(?) prostředek počítat, ne co je třeba spočítat (bez ohledu na systénové prostředky).
Vzhledem k tomu, že chci abstraktní OOP, ale k dispozici je počítač, který pracuje ÚPLNĚ jinak, je opravdu třeba tu iluzi naemulovat, to říkáte správně. Právě proto to taky něco (systémové zdroje) stojí.