Impresii de la Erlang, după un an de lucru cu el, note de programator
Voi începe cu cuvinte comune. Mulți oameni cred eronat că Erlang - funcțional limbaj de programare, un fel de sintaxă Lisp la om. La o primă aproximare, este adevărat. Dar uita-te ceva mai detaliată arată că Erlang - nu functional, ci mai degrabă un orientat pe obiect. și nu este un limbaj de programare și un cadru pentru construirea de aplicații distribuite tolerante la defect. Sau nu foarte rezistente și nu distribuite, ar putea fi la fel de scriere. De ce un cadru - clar, toată puterea este Erlang Deschideți Telecom Platform, inclusiv gen_server comportament. gen_event și altele, precum ETS. Mnesia și așa mai departe. Dar de ce Erlang dintr-o dată un obiect-orientat?
În general, ceea ce este PLO. Acest lucru este atunci când există obiecte, și obiecte pentru a interacționa cu fiecare alte trimite mesaje unul altuia. La fel ca în Erlang, doar aici obiectele sunt numite procese și clase - module. În Erlang are chiar moștenire interfață, dar aici se numește comportament (comportament). moștenire de punere în aplicare este implicat, este posibil, și în bine. Cu toate acestea, nimic nu împiedică utilizarea de delegare. De fapt, mult mai puternic decât Erlang corespunde ideilor OEP decât cele ca limbi OOP care sunt scrise astăzi toate.
Desigur, cu toate acestea, Erlang este un limbaj funcțional. Este pur și simplu nu destul de ceea ce PO, la care suntem obișnuiți.
Și acum, la subiect. Ce place atunci când se programează în Erlang?
- Datorită localizarea efectelor secundare și imutabilitatea variabilelor în codul Erlang uneori mai ușor de întreținut decât codul pe un limbaj imperativ, care, în plus, asigurați-vă că pentru a utiliza cu cinci etaje din clasa ierarhie și etc;
- Eleganta si consistenta limbajului. Procesele trebuie să ia tot felul de mesaje, așa că au nevoie de tastarea dinamic. mai degrabă decât statice. Cum de a distribui timpul CPU printre miile de procese? Desigur, compila la bytecode și de a folosi contoare de instrucțiuni executate. Etc si etc, toate au raspunsuri logice. Ma gandesc la asta, îți dai seama că Erlang nu poate fi alta;
- Modelul actor - e cool. Nici un stat partajat (aproape) și nici dedlokov (aproape);
- Convenabil de management. ETS, prize și etc. atașate la proces. Când procesul se datorează un motiv sau altul moare, resursa este eliberată. Nu este atât de ușor pentru a da o scurgere de resurse, deși este încă posibil. De asemenea, este imposibil sa nu nota de colectare a gunoiului corect în Erlang. În primul rând, nu este pe numărul de referință, ca și în alte limbi. În al doilea rând, memoria nu se scurge atunci când se utilizează destructor (deoarece acestea nu sunt), modul în care acest lucru se poate întâmpla în Python. În plus, colectarea gunoiului într-unul dintre procesele nu se oprește toate celelalte procese, cum ar fi într-un du-te;
- studiind viteza. Și într-adevăr, după câteva săptămâni de muncă sub îndrumarea mai multor colegi cu experiență de a începe să scrie cod de luptă destul de tolerabil. Un cuplu de luni au încetat deja să se simtă Junior;
- Maturitatea limbajului. O grămadă de biblioteci și cadre gata făcute, suport IDE diferit (dar eu încă mai scrie pe Erlang în Vim), dezvoltat Toolkit (DBG. Sommon de testare. Xref, dializor, Typer, Observer, ...). O mulțime de literatură bună, pagini de om se potrivesc;
- În experiența mea, nu am fost niciodată atât de ușor de a scrie cod paralel. Paralelizare de calcule - optimizare meu preferat în această limbă. Dacă te duci pe un server cu Erlang-nod al unei sarcini de mare și vedere Htop, este clar că toate miezurile sunt încărcate uniform. Mai mult decât atât, fără nici un efort din partea noastră. De asemenea, datorită proceselor ușoare pot, de exemplu, poate satisface cu ușurință pentru ambele 10k TCP-conexiuni;
- În Erlang nu trebuie să fie subminate, în scopul de a salva orice stat în memorie. Caching - aceasta este a doua mea de optimizare preferat în Erlang după paralelism. În tot felul de limbaje de scripting pentru astfel de lucruri de multe ori folosesc Redis și Memcached. și după care merg la Redis semnificativ mai scumpe decât mersul pe jos în memoria lui;
- În general, limbaje de scripting sunt în mod constant apare necesitatea unor aplicații de la terți - Redis, Tarantool și alte NoSQL și FastCGI, toate tipurile de SQL-proxy și alte cârje. În Erlang toate necesare sau este „scos din cutie“ (incluse, de asemenea, sunt SSL, Gzip și alte utilități), sau puse în aplicare în cinci linii de cod;
- Cross-platform. Puteți dezvolta o aplicație sub MacOS, în produs și rulați-l sub Ubuntu. Virtual Machine Erlang - este de fapt un sistem de operare independent;
- În Erlang, puteți lansa produsul în remedierea rapidă fără oprire a sistemului. Sau mediul de testare, fără a întrerupe executarea testelor. De asemenea, folosind remsh se poate agăța de un nod de lucru și a vedea ce se întâmplă chiar acum în intestine, sau, să zicem, pentru a modifica setările de sistem. oportunitate foarte convenabil;
- Limba evoluează, dar încă reușește să rămână stabil. Aici, în Scala din lume. de exemplu, toate modificările foarte repede. în codul Scala scris câțiva ani în urmă, astăzi poate fi aruncat la gunoi. În Erlang arunca, de asemenea, funcții învechite (așa cum a fost cu multe dintre funcțiile modulului criptografic) și caracteristicile lingvistice (module parametrizate). Dar toate afectele parte minusculă a codului. Și în R17 promisiunea de a adăuga map'y cu BIF'ami pentru a converti la / de la JSON;
- Viteza mare de dezvoltare, nu mai puțin de limbaje de scripting;
- comunitare competente și receptiv de programatori. Există opinia că poate susține de asemenea în cazul în care societatea scris pe Erlang, cel mai probabil, este o companie bună;
- Există un post vacant. Bine. Un număr relativ mare de PT lumii;
De asemenea, din punctele forte ale Erlang, aș dori să menționez o compilație rapidă, programare sigură „din cutie“ ușurința de a găsi blocajelor (eu sunt, de obicei, în căutarea la Repl prostește folosind timer: tc / 1) și apoi le elimina, precum și tot felul de distracție pe prilozhenki Erlang, tip RabbitMQ și Riak. care, de fapt, poate fi folosit oriunde, dar mai ales la fel ca pentru un motiv oarecare din Erlang.
Dar, în orice unguent zbura în unguent acolo. Și, uneori, nu unul. Ce înfurie:
Dar este un nonsens. Mult mai important dezavantaj Erlang în opinia mea, este după cum urmează. Știm cu toții că abstractia - asta e bine. Vom introduce un nou tip de funcție și de a lucra cu ea, bine, sau clasă și metode, dacă preferați. Aceste funcții sau metode definesc interfața prin care lucrăm cu datele, astfel că există o abstracție de tipul de dispozitiv intern. Pentru introducerea de „tip“, noi sau „clasă“ în Erlang utilizate intrări (înregistrări). S-ar părea, ce probleme - anunță înregistrare și funcții pentru a lucra cu ea, viața este frumoasă și uimitoare. Dar Erlang nu este de lucru! Luați în considerare, de exemplu, următorul cod până la acea Haskell:
myFynction x alte args
| field1 x == 123 field2 x == 456 field3 x == 789 = -.
Pot să scrie ceva similar cu Erlang? Se pare că este imposibil. Faptul că o puteți utiliza pentru Klose funcții doar pure. Deoarece Erlang nu are nici un control asupra purității funcțiilor la nivelul de tipuri sau chiar o dată, toate funcțiile care sunt declarate de către utilizator, sunt considerate murdare. Aici erlangistam și trebuie să folosim inkluda și acces la înregistrările câmpurile direct ceva de genul:
my_function # 40; # stat # 123; field1 = 123. field2 = 456. field3 = 789 # 125;.
Altele. args # 41; ->%.
Ca rezultat, sparge abstractizare, toate modulele sunt conștienți de înregistrare și să înceapă să se bazeze pe aceste cunoștințe. Dacă decidem, de exemplu, că field3 nu ar trebui să fie stocate și evaluate în mod continuu, trebuie să rescrie toate codul, care este accesat field3. Un V Haskell puteți suprascrie pur și simplu field3 și totul va funcționa ca înainte. Este clar că această problemă poate fi rezolvată, dar creșterea rezultată a numărului de cod șabloane.
În general, după cum probabil ați ghicit, cu atât mai mult am scrie pe Erlang, cu atât mai mult îmi place Haskell. În Erlang, puteți scrie pe eroare:
my_function # 40; # 123; flux = Stream # 125; # 41; ->%.
my_function # 40; # stat # 123; flux = Stream # 125; # 41; ->%.
... si va compila cu succes! Și ce de ea? tuple normal conținând un atom care am asociat cu flux variabil. Sau aici e un alt exemplu:
my_function # 40; UserRole # 41;
atunci când UserRole =: = admin;
UserRole =: = moderator ->%.
Ce se întâmplă dacă vrem să introducem un nou rol de utilizator, de exemplu, super_moderator? Nimic deosebit, codul va funcționa. Nu neapărat se potrivesc, dar aceasta este mica schimbare. Dar, Haskell, în acest caz, găsiți cu succes toate locurile în care aveți nevoie pentru a corecta codul.
Dar, în ciuda tuturor acestor rugozitate, Erlang - este un bun, limbaj adecvat. Este foarte potrivit pentru crearea de aplicații complexe, tolerante la erori distribuite, cât și pentru saytik obișnuite. Să limba este departe de a fi ideală, dar este mult mai bună alegere. decât orice acolo Perl, Python și Node.js. Desigur, gama de aplicabilitate Erlang nu se limitează la navigarea pe web, există tot felul de XMPP-servere sau, de exemplu, sistemul de management de baze de date distribuite (încercați să-l, de altfel, se aplică aici Python!). Cu o dorință puternică pe Erlang, puteți scrie GUI sau chiar și în Android.
Ce părere ai despre Erlang?