Ad profesionálně. Profesionálně dělám BI SaaS v Perlu na cloudu v Amazonu a protože narážím na určitou třídu problémů, tak hledám jak je řešit. Dělám evaluaci možných řešení a postupem času jsem zavrhl všechno jako přechod na jiný jazyk (Python, Ruby, Java, CL) protože u žádného z nich benefity po případného přechodu nevyváží ty problémy s přechodem. Erlang je v tomhle výjimkou. Znamená to radikální změnu paradigmatu, ale přináší:
Nárůst výkonu - žádná z alternativ nepřináší větší větší výkon. Ruby a Python o tom se nemá cenu bavit. CL - problémy s GC které krásně ukazuje ten druhý odkaz, což mě osobně velmi zklamalo a akceptace Lisp syntaxe taky není nic moc, to by musel přinést něco podstatně víc. Java - stejné problémy s GC - prostě globální GC s nutností řešit cykly nikdy nemůže překonat GC per proces a bez cyklů. Ostatně viz zkušenosti z Motoroly, ani C++ a vlastní management v konkurenčním charakteru zátěže prostě nestíhá. Je to nefér, ale Erlang tady nebojuje čestně ;-)
Kvalita - tady se má cenu bavit jedině o J2EE a CL. Zkušenosti s J2EE nejsou přesvědčivé. Spolehlivost je tam dosahována za cenu obrovských nákladů, problémy s memory aliasingem (reference na objekty a vedlejší efekty funkcí). CL je na tom podobně. Tady opět Erlang nebojuje fér, funkcionální paradigma a sideefect free to je prostě někde jinde.
Velikost kódu - O Javě se v tomhle nemá cenu bavit, je na tom skoro stejně špatně jako C++. Tady má šanci CL a Python, Ruby. Jenže do toho nám vstupuje pattern matching a optimistické programování v Erlangu a opět to není úplně fér. Když by se přidal pattern matching do CL, tak je to asi jediný který může držet krok.
Spolehlivost - framework J2EE je asi jediné co se může srovnávat s OTP. U CL nevím, ten diskvalifikovali jiné věci na to abych zjišťoval jak je na tom například Allegro nebo jiný průmyslově ověřený framework. O akademických pokusech se nemá cenu bavit. Tohle diskvalifikuje OCaml i Haskell (HApps je v vtip, přečtěte si specifikace). Ukažte mi projekt se SLOC jako má ADX301 do kterého bylo investováno cca 1000 člověkoroků a stejnou spolehlivostí a můžeme se o tom bavit. Aby to bylo fér tak u Javy SLOC dělte aspoň třema ať nežeru.
Clusterování - J2EE, příliš komplikované proti erts (Erlang RunTime System). V erts je to součást jazyka, síťová transparentnost základních jazykových konstrukcí a podobně. Opět kvalitativně někde jinde.
Na OCaml, Haskell a podobně jsem se díval a absence OTP je asi největším zabijákem, pak následuje nenativní cluster a už se vezou.
Erlang testuji už nějakou dobu, tak můžu potvrdit, že ty výkonnostní čísla nelžou. Kódu je skutečně potřeba několika násobně méně. Programování v něm je skutečně jednoduché, minimum bižuterie okolo (succes case a pattern matching je nakažlivý, jak jednou zkusíte, tak vám defenzivní programování a absence pattern matchingu přijde strašný opruz - jestli to nemyslíte vážně tak to radši nezkoušejte, protože v jiných jazycích budete od té doby strašně trpět).
Co se týče komunity, tak ta roste exponenciálně a je na vás jestli se chcete svést na vlně, nebo sedět v koutku. Co se týče hlavních vlastností jazyka, tak je přebírají ostatní jazyky a platformy, ale vždycky je to s nějakými kompromisy. A tam kde to není s kompromisy (OCaml, Haskell, Oz), tak chybí OTP. Do toho by musel někdo investovat obrovské prachy a nemá cenu na to čekat. Za porovnatelný ekvivalent bych považoval snad F#, ale i tam jsou kompromisy a ta platforma je pro mě osobně nepřijatelná. F# v CLR .NET má peněz dostatek a výkon se tím dá nahnat. Když bych na .NET dělal, tak bych měl velké dilema.
Jedinou nevýhodou Erlangu je neobvyklá syntaxe (mě osobně se maximálně líbí a v ní jsou zakleté některé klíčové výhody) a relativně malá báze knihoven a dokumentace. To všechno se dá překonat, ale chyby v konceptu nikoliv. Z Erlangu výkon Javy teoreticky vymačkat jde (pokud ho už nemá). Dodělat do Erlangu knihovny a dopsat dokumentaci jde. Dostat z Javy spolehlivost, čitelnost a jednoduchost vývoje v Erlangu nejde ani teoreticky. A místo Javy si dosaďte jakýkoliv oblíbený jazyk z této ankety a dojdete ke stejnému závěru.
Živost projektů:
CouchDB - jeden s nejdynamičtěji se vyvíjejících projektů Apache Foundation. Během několika měsíců se dostal z inkubátoru mezi oficiální projekty.
SimpleDB v Amazonu - ;-)
ejabberd - LOL
Facebook - LOL
Během posledního roku je kolem Erlangu se podezřele motají firmy jako IBM, Sun Mircrosystems, Yahoo, Amazon, Google a další
Riziko vidím v tom, že někdo zainvestuje infrastrukturu kolem CL, OCaml, Oz nebo Haskell. A přetáhne na sebe pozornost. Nebo vylepší JVM a udělá z ní MVM (viz odkazy v disertaci J. Armstronga jako jedna z větví kterou se Java nevydala, pro Erlang naštěstí, pro celé IT bohužel) což je nekompatibilní krok a stejně pak bude muset předělat půlku infrastruktury kolem (to mi přijde jednoduší vylepšit BEAM nebo HiPE).
