spis to chce mit nejakou korelaci mezi tim co umim a tim co trh poptava. a kdybych investoval 2 roky zivota do studia neceho cim bych se v zemich koruny ceske neuzivil mi neprijde dobra vyhlidka.
trochu trollim, na 10000% procent v anglii nebo v nemecku se takova prace da sehnat. ale co jsem poslouchal jaky jsou komplikace sehnat treba praci v UK tak nevim... jednou me napadlo jen tak hledat nejakou praci na slovensku. ftip je v tom, ze pri kliknuti na tlacitko vyhledat se zmeni domena.sk na domena.cz a pak se standartne hleda. ale pouze v CR :D :D
Jen tak pro priklad: WhatsApp, Facebook messenger, Battle.net bezi na Erlangu (backend)
Erlang pouzivaji i nekteri mobilni operatori, protoze to je prostredi kde vznik (Ericsson). Akorat se tim moc nechlubi. Dejte do Google Erlang jobs a uvidite. Vyuziti je, jenom je velice specificke.
Facebook přepsal chat z Erlangu do C++ - viz třeba http://www.quora.com/When-did-Facebook-switch-away-from-using-Erlang-for-Facebook-Chat/answer/Ben-Maurer
At the time Facebook switched away from Erlang, the chat system had numerous reliability issues. The Erlang servers (which were used to provide long-poll functionality for browsers) caused some, but certainly not all of the problems. One problem we found with Erlang was that some of the abstractions Erlang had that allowed one to transparently have a distributed system across multiple machines actually caused reliability problems -- one server in the group would fail and cause cascading issues. Secondly, we found a number of instances where Erlang wasn't scaling well to multiple cores.
I don't think these issues are necessarily fundamental flaws of the Erlang runtime. It's quite possible that there was tuning that would have made Erlang work better for us (in fact, in our investigations we found a few tuning options that helped us).
However, Facebook has a number of useful abstractions in C++, making that a logical replacement.
V Erlangu (IMHO stejně jak v Prologu) záleží na tom, kde se operátor '|' objeví. Při pattern matchingu, pokud je na levé straně přiřazovacího (ve skutečnosti pattern matching) příkazu, znamená získání prvního prvku seznamu a zbytku. Pokud je zapsán jako výraz, na pravé straně, slouží pro připojení prvku na začátek seznamu.
Jeste bych dodal, ze q(), init:stop() a erlang:halt() je lepsi moc nepouzivat - lepe receno nezvykat si moc na ne.
Problem je ze tyhle funkce ukonci ErlangVM na kterou je zrovna shell pripojeny - asi dokazete odhadnout co se stane, kdyz zapomenete, ze jste pripojeni na produkcni stroji napr kvuli nejakemu ladeni.
Bezpecne ukonceni aktualniho shellu lze udelat pomoci kombinace CTRL-G Q ENTER (CTRL-G aktivuje ovladaci prosterdi shellu), nebo CTRL-C A ENTER (CTRL-C aktivuje neco jako debugger).
Erlang je svým způsobem super a jsem rád, že se o něm mluví a že přitáhne pár těch zvědavců. :) Syntakticky je to trochu hardcore, ale dá se to. Odtud už to není daleko třeba k Haskellu nebo nějakýmu tomu Lispu. Vůbec ten systém "procesů", kradení práce nazvzájem napříč počítači, OTP framework, to je tak trochu unikát (nebo ne?). Těším se na další díly.
Mylim, ze podobny princip (m:n threadidng) pouziva "virtualni masina" Informixu. Informix ma vlakna kterym rika virutualni procesory. Tyhle vlakna nevolaji blokujici syscally OS a jenom procesuji kod. Navic Informix vola syscall sched_setscheduler (SCHED_RR) cimz rekne kernelu aby mu nekacal do planovani uloh. Prepinani uloh bezicich na virtualnim procesoru ridi vlastni procesor.
Erlang je super, ale rozhodne by bylo lepsi psat o Elixiru a Erlang vysvetlovat jen okrajove pro pochopeni urcitych veci z Elixiru. Cetl jsem, ze uz se doporucuje vyvijet v Elixiru misto Erlangu. Pro ujasneni Elixir je jazyk, ktery se preklada do bytecodu, kteremu rozumi Erlang VM. OTP je jina vec, protoze principy vyvijeni v Erlangu plati i pro Elixir (gen_server, supervisor, application, ...). Elixir vetsinou poskytuje vlastni rozhrani, ktere treba jen deleguje volani na erlangovsky modul.
Napr. volani erlangovskeho "now" je v elixiru proste :erlang.now a neni tam absolutne zadny overhead, ze by se to volalo pres nejake proxy moduly atd..Tzn. moduly pro erlang jde uplne normalne pouzit i v Elixiru, akorat je proste potreba vedet nejake ty rozdily, ze treba atom v Erlangu zacina malym pismenem a v Elixiru je prefixovany dvojteckou (atom vs. :atom).
Metaprogramming a vytvareni vlastnich DSL napr. pro definovani routeru, kdyz budu v elixiru delat webovku je naprosto super vec. Uplne me ten jazyk pohltil.
Pokud si myslis, ze Elixir je jenom o syntaxi, tak to sis ho poradne neprostudoval/nevyzkousel. Elixir krome syntaxe 1. opravuje nektere navrhove chyby Erlangu, 2. prinasi par zasadnich vylepseni, 3. ma spoustu ciste prijemnych vlastnosti.
Do 1 patri treba to, ze skutecne vsechno je vyraz (u Erlangu to neplati, proto nektere veci funguji v modulu, ale nefunguji v interpretu).
Do 2 hlavne namespaces a makrosystem (s hodne pokrocilymi vlastnostmi, treba volitelnou hygienicnosti).
Do 3 spousta ruznych prkotin, ktere vyrazne zprijemnuji zivot, jako treba to, ze v listu muze byt klidne carka pred zaviraci zavorkou a funkce neni nijak zvlast zakoncena - vyrazne snizuje pocet vlasu vyrvanych pri refaktoringu kodu :)
O Elixiru se pochvalne vyjadril i sam Joe Armstrong ;) http://joearms.github.io/2013/05/31/a-week-with-elixir.html
To je problém spíše jejich SW. Před pár lety (vlastně to bude už skoro 10) jich řada přešla na nové verze, které jsou založené na "checkboxech". Je tam kupříkladu seznam programovacích jazyků a tam zaškrtnete ty, které uchazeč umí. Pokud jazyk není na seznamu, tak máte smůlu, prostě to tam nezadáte.
Do té doby se to zadávalo jako "free text", ale fulltextové vyhledávání byl problém a automatizace vázla. Teď vám sice vyjede seznam pozic nebo uchazečů podle zadaných kriterií během zlomku vteřiny, ale jakmile hodnota není v číselníku, tak přes to vlak nejede. Daň za to, že práci najdou i uchazeči, jehož "personální poradkyně" do databáze zapsala, že uchazeč ovládá Jawu, PEHP a MÁJSEKVEL.
Má erlang něco jako striktní režim? Už totiž vidím jak se uklepnu třeba ve jménu atomu a budu se divit proč mi to porovnání furt vrací false..., líbilo by se mi zapnout nějaký striktní režim, ve kterém bude vše potřeba předem nějak nadeklarovat. To samé platí pro proměnné..., viz třeba perlovské use strict, nebo bashovské set -u. Pokud dělám na něčem co má víc jak dvacet řádek, tak se mi většinou vyplatí, že mi program vypíše smysluplnou chybu (funkci/proměnnou/atom vůbec neznám) za cenu, že musím napsat o malinko víc kódu.
Striktni rezim nema, ale napriklad preklepy v atomech se vetsinou daji odhalit pomoci http://www.erlang.org/doc/man/dialyzer.html.
(v clanku je asi preklep)
operátor přesná shoda ma tvar =:=
operator =/= bude zrejme: NOT "přesná shoda"
zdroj: http://erlang.org/doc/reference_manual/expressions.html#id78646
pretoze v erl:
1 =/= 1.0.
true
S Erlangem začínám, tak všechno co se mi nezdá si hned ověřuju - např. v tomto popisu a příkladech je chyba:
Porovnávací operátory (== < > =< >=) fungují opět dle očekávání. Operátor není rovno je vypadá méně obvykle (/=). Navíc existuje operátor přesná shoda (=/=).
1 == 3 % false
1 /= 3 % true
1 == 1.0 % true
1 =/= 1.0 % false
Za prvé, operátor 'přesná shoda' vypadá takto =:=
tohle =/= je jeho negace - ale připusťme jen nepřesné vyjádření
v posledním příkladu je ale tvrdá chyba - správně má být
1 =/= 1.0 %true