GitHub - carp-lang/Carp: A statically typed lisp, without a GC, for high performance applications
https://github.com/carp-lang/Carp

UETOYO: Nechceme, ale dalo se tam přihlásit přes google účet, tak jsem to zkusil. Doufám, že tu hrůzu nebudu muset používat nějak víc. :-)

SHAGA, LISKNI_SI: Mockrat dekuju!

Chapu, ze nasledujici otazka je tady dost chucpe ale odvazim se.

Muj rozhled je dost omezeny - zivi mne C++ a okolo sebe jsem videl vzdy temer vyhradne dalsi proceduralni jazyky (java, python). Posledni dobou mam pocit, ze komponenty pro distribuovane systemy se komoditizuji (xml-rpc, grpc, zeroMQ, rabbitMQ, kafka, docker, kubernetes, hdfs, cephfs, ...). Prijde mi, ze asi nejvic veci vzniklo v ramci java ekosystemu (videno u sousedu, treba se pletu) byt rozhrani mivaji budto pro vicero jazyku nebo bez vazby na konkretni jazyky (REST API, protobuffery, ...).

Takze pokud jste to nemysleli tak, ze byste i dneska kladli hlavne duraz na to aby engine vznikl ve funkcionalnim jazyce (cemuz mozna trochu odporuje ten perl? nevim), mam to tedy brat tak, ze Erlang ma skvele nastroje a Erlang VM se skvele hodi na ten middleware a v souctu vam to vychazi rozumnejsi volba nez treba (pardon) java (vcetne intellij apod.) a nejaky open-source middleware?

Pro jistotu opakuju - nejde mi o zadny flame ani netlacim nejaky nazor, jsem proste zvedavy a vy mate tu smulu, ze vypadate rozumne :-) Vychazim hlavne z toho, ze programatoru v C++, jave, pythonu jsou plne pracaky a kdejaky Google/Facebook/etc vyviji open source projekty pro "enterprise" distribuovane systemy zatimco Erlang ani Haskell tolik rozsireny asi nebude.

Predem diky za nazory.

LUDWIG_: Samozřejmě. Teď už dokonce ve voting režimu v pull request builderu - spadne ti dializer, nezamergeuješ.

LUDWIG_: Jop. Musel jsem si kvůli němu na 32b debian nainstalovat 64b erlang a zapnout v kernelu zswap. A naučit se zavírat zbytečný taby v browseru.

KOJA: Hodně napsal už tady kolega liskni_si, který na našem analytickém engine zanechal nesmazatelné stopy :) Nicméně - engine jako takový využívá z Erlangu jen subset, čili není až tak závislý na tom, co dělá Erlang Erlangem. Nicméně ten analytický engine poměrně mohutně využívá služeb našeho vlastního middleware, který je také napsaný v Erlangu a ten bych v ničem jiném (tedy kromě Elixíru) rozhodně nepsal - je to distribuovaný systém posouvající zprávy z jednoho konce clusteru na druhý a dělající s těmi zprávami během cesty různá kouzla a na to je Erlang (nebo cokoliv jiného běžícího nad Erlang VM) naprosto fantastický.

KOJA: Legrační je, že ta aktuální (druhá) verze analytickýho enginu byla postupně napsaná v Haskellu, Perlu a Erlangu — stejný algoritmy, stejně pojmenovaný funkce, stejný všecko, jen "trochu" jiný jazyky. V Haskellu se psal prototyp, přepis Perl aby zapadlo do tehdejší codebase, přepis do Erlangu protože Perl byl pomalej a blbě zapadal do tý cloudový infra.

Kdybych to psal dneska, vynechal bych ten Perlovej mezikrok, ale mezi Erlangem/Haskellem bych váhal. Haskell běží o dost rychlej a líp se refaktoruje, ale Erlang se úplně totálně megabožsky rychle kompiluje a testuje, a na produkci je to radost běhat, ladit, monitorovat. V Haskellu jsou knihovny na úplně všecko, v Erlangu chybí základní datový struktury, ale ten rozdíl v operations je tak velkej, že bych to přesto zvažoval.

(je ale možný, že kluci, kteří na tom narozdíl ode mě pracují dodnes, to vidí jinak anebo maj další postřehy)