Впечатления от Erlang след една година, които работят с него, програмист бележки
Ще започна с общи думи. Много хора погрешно вярват, че Erlang - функционален общо предназначение език за програмиране, един вид Lisp синтаксис за човешкото. За първо приближение, това е вярно. Но малко по-подробен поглед показва, че Erlang - не функционира, а по-скоро обектно-ориентиран. и не е език за програмиране и рамка за изграждане на устойчиви на грешки разпределени приложения. Или не е много гъвкав и да не разпространява, може да има като запис. Защо рамка - ясно, цялата власт е Erlang Open Platform Telecom, включително поведение gen_server. gen_event и други, както и СТЕ. Mnesia и така нататък. Но защо Erlang изведнъж обектно-ориентиран?
В общи линии, това, което е за освобождение на Палестина. Това е, когато има обекти, както и обекти, за да си взаимодействат един с друг, да изпращате съобщения един на друг. Точно както в Erlang, само обектите, тук се наричат процеси и класове - модули. В Erlang дори има интерфейс наследство, но тук той се нарича поведение (поведение). наследяване изпълнение е ангажиран, много е вероятно, както и за по-добро. Въпреки това, нищо не пречи да използва делегация. В действителност, много по-силна от Erlang съответства на идеите на ООП от тези, като обектно-ориентирани езици, които са написани днес всички.
Разбира се, с всичко това, Erlang е функционален език. Това просто не е точно това, което на ОП, на което сме свикнали.
А сега по същество. Какво удоволствие при програмирането в Erlang?
- Благодарение на локализацията на страничните ефекти и неизменността на променливите в Erlang код в пъти по-лесно да се поддържа от кода на някои наложително език, който, освен това, не забравяйте да използвате пететажна клас йерархия и др;
- Елегантност и съгласуваност на езика. Процесите трябва да вземат всички видове съобщения, така че трябва динамичен пишете. а не статична. Как да се разпредели времето на процесора сред хилядите процеси? Разбира се, съставяне на байткод и използват броячи на изпълнените инструкции. И т.н., и т.н., всички те имат логични отговори. Мислейки за това, ти осъзнаваш, че Erlang може да бъде никой друг;
- актьор модел - това е готино. Не сподели състояние (почти) и не dedlokov (почти);
- Удобен управление. ETS, контакти и т.н., свързани с процеса. Когато този процес се дължи на една или друга причина, умира, ресурсът е освободена. Не е толкова лесно да се получи изтичане на ресурси, въпреки че все още е възможно. Също така е възможно да не е да се отбележи правилното събиране на боклука в Erlang. Първо, тя не е на референтния брой, както и в някои други езици. На второ място, паметта не изтича, когато се използва деструктор (защото те не са), как това може да се случи в Python. В допълнение, събиране на боклука в един от процесите не спира всички други процеси, като в някои Go;
- изучаване на скоростта. И наистина, след няколко седмици на работа под ръководството на по-опитните колеги започнете да пишете доста поносими борба код. Няколко месеца вече са престанали да се чувстват Junior;
- Падежът на език. Купчина готови библиотеки и рамки, различни подкрепа IDE (но все още пишат на Erlang в Vim), разработен инструментариум (DBG. Sommon Test. Xref, диализатор, Typer, Наблюдател, ...). Много добра литература, годни човека страници;
- В моя опит, никога не съм бил толкова лесно да се напише паралелен код. Паралелно извършване на изчисления - любимата ми оптимизация на този език. Ако отидете на сървър с Erlang-възел на високо натоварване и изглед htop, ясно е, че всички ядра са натоварени равномерно. Освен това, без никакви усилия от наша страна. Също така, благодарение на леки процеси може, например, може лесно да се погрижат и за двете 10k TCP-връзки;
- В Erlang не е нужно да устоите, за да спаси всяка държава, в паметта. Кеширане - това е вторият ми любим оптимизация в Erlang след паралелното. В най-различни скриптови езици за такива неща често използват Redis и Memcached. и след като става до преразпределяне значително по-скъпи от ходене в негова памет;
- Като цяло, скриптови езици са постоянно възниква необходимостта от всякакви приложения на трети страни - Redis, Tarantool и други NoSQL и FastCGI, всички видове SQL-прокси и други патерици. В Erlang цялата необходима или е "извън кутията" (също се включват SSL, с GZIP и други комунални услуги), или изпълнява в пет реда код;
- Cross-платформа. Можете да направите приложение под MacOS, в продукта и да го ползвате под Ubuntu. Virtual Machine Erlang - това е действително независима операционна система;
- В Erlang, можете да ставам на продукта в актуалната корекция без спиране на системата. Или тестова среда, без да прекъсва изпълнението на тестовете. Също така, с помощта на remsh да се придържат към работна възел и да видим какво се случва в момента в смелостта, или, да речем, за да промените настройките на системата. Много удобна възможност;
- Език се развива, но все още успява да остане стабилна. Тук, в Скала света. например, всички промени много бързо. в Scala код, написан преди няколко години, днес тя може да се изхвърля в кошчето. В Erlang също хвърлят остарели функции (както е било с много от функциите на модула за шифроване) и езиковите характеристики (параметризираните модули). Но всичко влияе миниатюрен част от кода. И в R17 обещание да добавите map'y с BIF'ami да конвертирате от / до JSON;
- Високата скорост на развитие, не по-малко от скриптови езици;
- Компетентен и отзивчив общност от програмисти. Налице е спорно мнение, че прекалено, ако компанията написано на Erlang, най-вероятно, това е добра компания;
- Налице е вакантно. Добре. Относително голям брой РТ на света;
Също така от силните страни на Erlang бих искал да спомена един бърз компилация, сигурно програмиране "извън кутията" лесното намиране на тесни места (аз обикновено гледам с празен поглед на REPL използване на таймера: TC / 1) и след това да ги отстранят, както и всички видове забавно за prilozhenki Erlang, тип RabbitMQ и Riak. което на практика може да се използва навсякъде, но най-вече много прилича по някаква причина от Erlang.
Но в никакъв мехлем тъмен облак в ясно небе там. И от време на време, а не един. Какво вбесява:
Но това са глупости. Много по-значителен недостатък Erlang по мое мнение е, както следва. Всички знаем, че черпене - това е добре. Ние се въведе нов тип функция и да се работи с него, добре, или клас и методи, ако предпочитате. Тези функции или методи определят интерфейс, чрез който ние работим с данните, така че да има абстракция от типа на вътрешния устройство. За въвеждането на нов "тип" или "класа" в Erlang използва записи (записи). Тя ще изглежда, какви проблеми - обяви запис и функции за работа с него, животът е красив и невероятно. Но Erlang не работи! Помислете, например, следния код до този Haskell:
myFynction х други аргументи
| Field1 х == 123 Field2 х == 456 поле 3 х == 789 = -.
Мога ли да напиша нещо подобно на Erlang? Оказва се, че това е невъзможно. Фактът, че можете да използвате, за да Клозе само чисти функции. От Erlang няма контрол върху чистотата на функциите на ниво видове или дори веднъж, всички функции, които са декларирани от страна на потребителя, се считат за мръсни. Тук erlangistam и ние трябва да използваме inkluda и достъп записи директно полета нещо като:
my_function # 40; # състояние # 123; Field1 = 123. Field2 = 456. Field3 = 789 # 125.
Други. ARGS # 41; ->%.
В резултат на това се разпада абстракция, всички модули са наясно на записа и да започнат да разчитат на това знание. Ако решим, например, че Field3 не трябва да се съхранява и постоянна оценка, трябва да се пренапише целия код, който е достъпен Field3. А V Haskell можете просто да замени Field3 и всичко ще работи както преди. Ясно е, че този проблем може да се заобиколи, но в резултат на нарастването на броя на шаблон код.
Като цяло, както вероятно сте се досетили, толкова повече аз пиша на Erlang, толкова повече ми харесва Haskell. В Erlang, можете да пишете на грешката:
my_function # 40; # 123; поток = живо # 125; # 41; ->%.
my_function # 40; # състояние # 123; поток = живо # 125; # 41; ->%.
... и тя ще състави успешно! И какво от това? Нормално кортеж съдържащ един атом, че свързани с променлив поток. Или тук е друг пример:
my_function # 40; UserRole # 41;
когато UserRole =: = администратор;
UserRole =: = модератор ->%.
Какво се случва, ако искаме да се въведе нова роля на потребител, например, super_moderator? Нищо особено, кодът ще работи. Не е задължително съвпадат, но това е малка промяна. Но в този случай Haskell успешно намерите всички места, в които трябва да се коригира кода.
Но въпреки всички тези грапавина, Erlang - това е добра, подходящ език. Тя е много подходяща за създаване на сложни разпределени отказоустойчивост и приложения, както и за обикновения saytik. Нека езикът е далеч от идеалното, но тя е много по-добър избор. отколкото всеки има Perl, Python и Node.js. Разбира се, границите на приложимост Erlang не се ограничава до сърфиране в мрежата, има всякакви XMPP сървъри или, например, разпределена система за управление на база данни (опитайте го, между другото, се прилагат тук Python!). Със силно желание за Erlang, можете да напишете GUI или дори под Android.
Какво мислите за Erlang?