Jaké jsou vaše zkušenosti s vývojem a provozem webových aplikací postavených v jazycích Erlang/Elixir.
nauc se cowboye a udelas v tom cokoliv. my jeli cca od 2011 chicagoboss s vlastnim db backendem (dsl na datamodely kompilovany do beamu a nativnich query procedur pro db) a pak jsme presli na vlastni odlehceny framework postaveny na cowboyi, websocketech, reactu a es6. cele to jede v docker containerech (zacinali jsme na lxc) nad zfs a management je velmi blizko nule.
ted leti phoenix ale elixir je spis takovy lakadlo pro rubysty, erlang je erlang :)
Citace od: Radek Miček kdy 18. 02. 2017, 14:29:44
Jaké jsou vaše zkušenosti s vývojem a provozem webových aplikací postavených v jazycích Erlang/Elixir.
S vývojem jsou moje zkušenosti skvělé (Phoenix framework). Co se týče nějakého většího nasazení, neumím posoudit, dělám věci víceméně jenom nástroje pro sebe a omezený okruh lidí. Ale s tím by taky neměl být žádný velký problém, možná to chce jenom aby si logiku Erlangu opsáci trochu nastudovali, aby věděli, jak se k tomu chovat...
Kdyžtak zkus nahodit nějaké konkrétnější dotazy, rád pomůžu, jestli budu vědět, Elixir je moje láska :)
Citace od: . kdy 18. 02. 2017, 15:39:53
ted leti phoenix ale elixir je spis takovy lakadlo pro rubysty, erlang je erlang :)
Elixir rozhodně není jenom o syntaxi. I když i ta ušetří hodně nervů (osobně jsem syntaxi Ruby nesnášel a díky Elixiru jsem si na ni zvykl, ne naopak). K psaní v plain Erlangu moc nevidím důvod, Elixir je super.
Phoenix je výborný framework, dal bych mu rozhodně před ChicagoBossem přednost (v Phoenixu jsem dělal hodně - od ranných fází vývoje, v CB něco málo). Ale je fakt, že jeho síla je hodně v tom klasickém modelu oddělených stránek generovaných na serveru šablonami. Websockety má taky pořešené parádně, takže SPA se s ním taky dá udělat příjemně, ale už to není mainstreamové použití, které je fakt odladěné.
Mám rozchozenou SPA aplikaci, kde Phoenix vyloženě jenom obsluhuje websockety, rendering se dělá na klientovi (v Elmu, ale stejně dobře se dá použít třeba i React). HTTP API v téhle aplikaci vůbec nemám, všechno valí přes ws a funguje to dobře.
Citace od: Mirek Prýmek kdy 18. 02. 2017, 16:57:45
Websockety má taky pořešené parádně, takže SPA se s ním taky dá udělat příjemně, ale už to není mainstreamové použití, které je fakt odladěné.
Jak souvisí SPA s websockety?
Citace od: gll kdy 18. 02. 2017, 17:31:24
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
Citace od: Mirek Prýmek kdy 18. 02. 2017, 16:57:45
S vývojem jsou moje zkušenosti skvělé (Phoenix framework). Co se týče nějakého většího nasazení, neumím posoudit, dělám věci víceméně jenom nástroje pro sebe a omezený okruh lidí. Ale s tím by taky neměl být žádný velký problém, možná to chce jenom aby si logiku Erlangu opsáci trochu nastudovali, aby věděli, jak se k tomu chovat...
Kdyžtak zkus nahodit nějaké konkrétnější dotazy, rád pomůžu, jestli budu vědět, Elixir je moje láska :)
Zeptám se tedy konkrétněji k Phoenix frameworku:
- Jak je to s upgrady na novou verzi? Bývá potřeba měnit aplikaci nebo jsou nové verze zpětně kompatibilní?
- Pro přístup k databázi používáte Ecto? A pokud ano, jak dobře se v tom píší složitější dotazy?
Citace od: Radek Miček kdy 19. 02. 2017, 09:53:18
Jak je to s upgrady na novou verzi? Bývá potřeba měnit aplikaci nebo jsou nové verze zpětně kompatibilní?
To je různé podle verze. Ze začátku byl vývoj docela bouřlivý, ale teď už je nějakou dobu řekl bych stabilizovaný. Žádné překotné změny bych teď už nečekal, podle mě už bude Phoenix hodně stabilní. Taky z toho důvodu, že z hlediska toho, co umí nejlíp (aplikace založená na oddělených stránkách, templatování) už imho není zas tak moc co vymýšlet :)
Způsoby upgradu na jednotlivé verze je zdokumentovaný, můžete se kouknout sám: http://www.phoenixframework.org/blog/upgrading-from-11x-to-120
Citace od: Radek Miček kdy 19. 02. 2017, 09:53:18
Pro přístup k databázi používáte Ecto? A pokud ano, jak dobře se v tom píší složitější dotazy?
Zatím jsem psal věci, kde se mi hodilo jako úložiště použít Mnesia (interní erlangovská databáze), kterou Ecto nepodporuje, takže s Ecto neporadím, zkoušel jsem to snad jenom jednou a velmi krátce.
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
Citace od: klaxo kdy 23. 02. 2017, 12:55:27
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
Vim. Našeptávač asi neexistuje - na Erlangu nemůže nikdy dobře fungovat, protože moduly je možné (un)loadovat za běhu. Proto funguje našeptávání jenom v shellu, připojenému ke konkrétnímu běžícímu VM.
Citace od: Mirek Prýmek kdy 23. 02. 2017, 12:58:09
Citace od: klaxo kdy 23. 02. 2017, 12:55:27
ake IDE viete doporucit na Erlang / Elixir? Idealne aj s nasepkavacom
Vim. Našeptávač asi neexistuje - na Erlangu nemůže nikdy dobře fungovat, protože moduly je možné (un)loadovat za běhu. Proto funguje našeptávání jenom v shellu, připojenému ke konkrétnímu běžícímu VM.
Našeptávač pro Elixir existuje https://github.com/tonini/alchemist-server . V Emacsu stačí nainstalovat balíček alchemist.
Do idei existuje erlang aj elixir pligin
Citace od: Mirek Prýmek kdy 18. 02. 2017, 19:15:21
Citace od: gll kdy 18. 02. 2017, 17:31:24
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
IMHO pro komunikaci typu požadavek-odpověď se websockety moc nehodí.
Citace od: gll kdy 23. 02. 2017, 20:03:35
Citace od: Mirek Prýmek kdy 18. 02. 2017, 19:15:21
Citace od: gll kdy 18. 02. 2017, 17:31:24
Jak souvisí SPA s websockety?
Když se stránky renderují na klientovi, musí klient nějak dostat data. Buď přes http api, nebo přes ws. Ws mají výhodu v tom, že je přes ně čistější oboustranná asynchornní komunikace. Takže když SPA, tak mi websockety přijdou jako lepší volba (pokud se s nimi v daném frameworku dobře pracuje).
IMHO pro komunikaci typu požadavek-odpověď se websockety moc nehodí.
proč? mi to docela funguje
Citace od: v kdy 23. 02. 2017, 20:06:48
proč? mi to docela funguje
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
Citace od: gll kdy 23. 02. 2017, 20:22:07
Citace od: v kdy 23. 02. 2017, 20:06:48
proč? mi to docela funguje
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
to "zadarmo" bych si dovolil zpochybnit, že není potřeba udržovat stav taky IMHO neplatí vždy, pro mě je přirozené, že aplikace naváže spojení spojení se serverem a po skončení aktivity uživaetle sezení uzavře
Citace od: gll kdy 23. 02. 2017, 20:22:07
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
To neni zadarmo. To je za cenu udrzovani dvou ruznych API (ws a http).
Citace od: Mirek Prýmek kdy 23. 02. 2017, 21:13:29
Citace od: gll kdy 23. 02. 2017, 20:22:07
Třeba protože v HTTP mám spárovanou odpověď s požadavkem zadarmo? Proč používat statefull řešení tam kde není potřeba udržovat stav?
To neni zadarmo. To je za cenu udrzovani dvou ruznych API (ws a http).
Websockety se dají používat jen pro vyvolání akce načtení dat přes HTTP API. K žádné duplikaci potom nedochází.
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
Citace od: gll kdy 24. 02. 2017, 16:31:34
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
Spis pure (eliminaci side-effektu), stavovosti se neda vyhnout. Uz tady je videt pekne proc. Co je stavove a nestavove ? Pokud to ma neco delat, tak to musi menit stav. Jde o to, aby zmeny stavu meli urcite vlastnosti a dalo se o nich lepe premyslet.
Prekladac si pak muze udelat vesmes co chce za danych garancych.
A pokud tak zapatram v pameti, tak i v Ruby a Jave neplati ze je to bezstavove. Volani je bud deterministicke, nebo nedeterministice. Nam jde o deterministicke, ktere samozrejme ulehci praci prekladaci, dovoli daleko lepsi cachovani atd.
V Ruby a Jave se programuje, tak ze se drzi stav v databazi.
Naopak v OTP se da takhle programovat taky, ale ... prave diky garancim mas tu databazi o jeden krok bliz.
Prakticky to mame nasazene celosvetove, odezvy v radech stovek micro sekund. Alchemist, VSCode ma taky extension. Naseptavace se moc nepouzivaji, moduly se pisou malinke...
Proste OO udelano spravne a microservice taky.
Citace od: gll kdy 24. 02. 2017, 16:31:34
stavovost na úrovni fungování aplikace
co to vlastně znamená?
By ma velmi zaujimalo, kolki z vas realne pouzivaju funkcionalne jazyky ako profesionalny jazyk, s ktorym pracuju
Citace od: jpu kdy 24. 02. 2017, 21:13:41
By ma velmi zaujimalo, kolki z vas realne pouzivaju funkcionalne jazyky ako profesionalny jazyk, s ktorym pracuju
haskell na některé nástroje, občas i velké, pro "produkci" ovšem ne
Citace od: gll kdy 24. 02. 2017, 16:16:08
Websockety se dají používat jen pro vyvolání akce načtení dat přes HTTP API. K žádné duplikaci potom nedochází.
Nepsal jsem "duplikace", ale dvě různá API. Typicky si na začátku říkáš, že tyhle data přece načteš jenom jednou, takže na to použiješ HTTP, ok, napíšeš to a za půl roku zjistíš, že bys vlastně chtěl, aby ty data byly živý - a přepisuješ to znovu do ws, s úplně jinou logikou, takže se ten kód nedá moc znovupoužít. Protože jsem si tímhle prošel, dospěl jsem k názoru, že nejjednodušší je prostě všechno posílat přes ws a fertig.
Citace od: gll kdy 24. 02. 2017, 16:31:34
Proč FP programátoři prosazují bezestavovost na úrovni jazyka a stavovost na úrovni fungování aplikace?
Mícháš dvě věci dohromady: vedlejší efekty a stavovost. "Sémanticky", význámově "stavová" může být i čistá funkce, třeba když jí jako první parametr dám stav. Taková funkce je čistá (nemá vedlejší efekty) a přitom pracuje se stavem (ještě líp možná "kontextem").
Stavovost "ná úrovni aplikace", resp. spíš komponenty, je prostě daná povahou toho, co ta komponenta dělá. Pokud servíruju statické stránky, pořád vracím stejnou stránku na stejný dotaz, tak mám nestavovou komponentu. Pokud chci, aby v hlavičce stránky bylo jméno uživatele, tak je to prostě komponenta stavová z principu - s jazykem to nemá nic společnýho.
Docela zajímavá je otázka vytížení serveru - pokud mi víc lidí přistupuje na živé informace, tak když to rozumně navrhnu před REST, tak tam můžu dát HTTP caching reverse proxy; u WS řešení bude výsledkem velké množství simultánních spojení. Nikdy jsem to nedělal (zrovna mám rozdělaný jeden projektík, kde jsem to původně přes WS chtěl řešit), ale nemůže to být trochu problém?
Citace od: andy kdy 25. 02. 2017, 08:22:18
Docela zajímavá je otázka vytížení serveru - pokud mi víc lidí přistupuje na živé informace, tak když to rozumně navrhnu před REST, tak tam můžu dát HTTP caching reverse proxy;
Živá data stejně typicky cachovat nemůžeš, protože neznáš expiraci.
Citace od: andy kdy 25. 02. 2017, 08:22:18
ale nemůže to být trochu problém?
Může. Ale erlang se dá dost snadno clusterovat a websockety v Phoenixu jsou na to od začátku navržené, takže se dá jít i touhle cestou. A přinejhorším kritické části můžeš do toho http vždycky přepsat - ale až to reálně bude výkonnostní problém, ne předem.
Viz https://dockyard.com/blog/2016/01/28/running-elixir-and-phoenix-projects-on-a-cluster-of-nodes
https://groups.google.com/d/msg/phoenix-talk/zjwitSVACUc/7gh8q9hBDgAJ
Citace od: Pilsner Urquell1842 kdy 24. 02. 2017, 17:03:10
Pokud to ma neco delat, tak to musi menit stav. Jde o to, aby zmeny stavu meli urcite vlastnosti a dalo se o nich lepe premyslet.
Prekladac si pak muze udelat vesmes co chce za danych garancych.
Je zajímavě, že si v tom samém příspěvku odporuješ: Překladač nepracuje se stavem, a přesto rozhodně něco dělá :-)