Názory k článku Reason: programovací jazyk od Facebooku nejen pro webové aplikace
-
EnE (neregistrovaný)Jakožto člověk, který se o tomto jazyce dověděl před pár minutami na této stránce, hodnotím článek kladně, ale vidím tu dva menší problémy;
- Nejsou mi úplně jasné případy užití jazyka - pochopil jsem, že „nahrazuje“ Java Script v prohlížeči, ale to, zda nahrazuje i PHP na serveru mi vyplývá velmi nepřímo a nejasně.
- Sekce s nevýhodami jazyka mi přijde příliš strohá - když vezmu v potaz své nejoblíbenější jazyky, dokázal bych uvést mnohem více nevýhod a problémů, které v nich vidím, a přijde mi krajně nepravděpodobné, že Reason by žádné takové neměl. Na druhou stranu, pokud je opravdu nemá - tím lépe. (Mimochodem, po chvilce Googlení jsem dospěl k závěru, že obrovskou nevýhodou je samotné jméno.)
-
m (neregistrovaný)
Výstupem je javascript. Teoreticky v tom lze psát serverové aplikace. Na https://redex.github.io/ lze nalézt i serverové knihovny.
-
Radek Miček (neregistrovaný)
Nejsou mi úplně jasné případy užití jazyka - pochopil jsem, že „nahrazuje“ Java Script v prohlížeči, ale to, zda nahrazuje i PHP na serveru mi vyplývá velmi nepřímo a nejasně.
Ano, může nahradit i PHP na serveru, ale osobně bych to zatím nedoporučil kvůli nedostatku kvalitních knihoven pro serverovou část aplikace.
Jednou z možností, jak napsat serverovou část aplikace v Reasonu, je přeložit Reason do JavaScriptu a spouštět na Node.js.
Druhou možností je využít nativní backend s nějakou knihovnou, která umožňuje napsat HTTP server - třeba cohttp. Ale to je dost nízkoúrovňový přístup a bohužel žádný rozumný vysokoúrovňový framework neexistuje.
-
jazykar (neregistrovaný)
Nu, tak nejak mi ty vsechny vyjmenovane vyhody (vcetne te moznosti nativni kompilace ala Go) pripomnely jazyk Dao (https://github.com/daokoder/dao , http://daoscript.org/ ) s tim rozdilem, ze Dao podporuje nativni paralelismus a nekolik skutecne peknych veci navic. A to vse i presto, ze je Dao dost minimalisticky (900 Kb binarka a jedna cca 1.2MByte knihovna) a velmi rychly jazyk (ne-JIT verze v syntetickych testech cca 2x rychlejsi nez CPython; ne-JIT verze v mnoha syntetickych testech temer stejne rychla jako zahrata JVM v syntetickych testech atd.).
Skoda, ze Dao nema reklamu jako ostatni jazyky a ze za nim stoji pouze malinkate firmicky a par vyzkumnych utvaru.
Jedina nevyhoda je tedy oddeleny ekosystem, ktery umoznuje sice automaticky generovat bindingy z C/C++/... knihoven a modulu, ale nepodporuje napr. nahravani JS ani Java ani Python ani Ruby ani jinych "vyssich jazyku" modulu (FFI nepocitam, to samozrejme chodi a pro nektere Dao moduly jako cblas se to pouziva).
-
jazykar (neregistrovaný)
Hm, takova ostra reakce asi nebyla treba - zase tak zle jsem ten postesk nemyslel.
Nu, plati to, co jsem napsal - cely seznam vyhod (pro pana/pani "mmm": vcetne kompilace do JS) je platny i pro Dao.
DaoReact ve smyslu "obdoba React pro Dao" neni treba - Dao nabizi o poznani lepsi jazykove nastroje nez JS a proto by DaoReact vypadal uplne jinak a tudiz jsem presvedceny, ze by problemy, ktere resi React slo v Dao vyresit lepe (jednoduseji, rychleji).
-
Boo (neregistrovaný)
1. Palec nahoru, ze zas clanku vevodi notebook Apple. Redakce uz prijala fakt, ze tu ma kazdy druhy ctenar Mac.
2. "oproti Elmu, Haskellu a jiným čistě funkcionálním jazykům, Reason podporuje mutaci, což v některých situacích značně zpřehlední kód" - tady podle mne po precteni par lidi dostalo lehci infarkt :D -
. . (neregistrovaný)
mě by zajímalo jak lidi hlídají javascript aplikace v produkci, dělat post portem analýzu javascript aplikace je dost peklo, stejně tak zjišťovat proč js aplikace stojí, proč má tolik paměti, proč se výrazně zpomalila atd. Facebook a jiní velcí na to mají vlastní closed source nástroje, v open source světě těch nástrojů moc není.
Máte někdo s tím zkušenosti nebo to nikdo neřešíte, restartujete aplikaci když zlobí a jedete dál?
-
spencer (neregistrovaný)
Delal jsem na aplikaci pro financni brookery kde cele MVC bylo ve frontendu a browser se vypinal tak jednou za mesic kdyz se updatoval windows. Takze hlidat memory leaky byla povinnost. Kazdopadne na to neni treba zadne extra nastroje, standardni devtoolsy v Chrome a Firefoxu jsou pomerne bohate + par specializovanych pluginu a jde to. Zadna velka magie to neni. Obvyklym vinnikem byly jquery eventy a nepozornost pri code review jestli pri zahozeni objecktu ci neceho na obrazovce byly vypnuty taky napojene eventy a pod. Mnoho z toho bylo odhaleno i pri testovani, meli jsme worklflow takovy, ze nez sly kody na produkci tak to jeste nejaky tyden jelo na stagingu v zatezovem testu a kdyz pamet nekde nekontrolovane rostla tak uz to Jenkins reportoval.
-
backup (neregistrovaný)
[...] Takze hlidat memory leaky byla povinnost. [...]
[...] nepozornost pri code review [...]
Tohle platilo pred 30 lety, kdy se pouzivaly prehistoricke jazyky jak C. Dnes v moderni dobe tohle prece neni vubec potreba. Moderni programator sahne k pythonu, javascriptu nebo nejakemu funcionalnimu jazyku a vsechny ty problemy minulosti jsou za nej vyreseny. Nakonec, jaky by melo smysl pouzivat moderni programovaci jazyky, kdyby museli programtori jako pred 30 let davat pozor pri code review ??
-
Popravde, reseni tehle veci je proti kompilovanym jazykum uplna pohoda :)
Tech nastroju v dusledku ani neni moc potreba - staci treba Chrome DevTools, to je tak silny nastroj, ze velmi pravdepodobne nebudes potrebovat zadny dalsi pro tyhle bezne problemy (pamet, debugging, rychlost).
A s tim zpomalenim / stanim - v tomhle je velkou vyhodou (ano, je pravda ze v node to 100 % neplati, ale skoro), ze JS je event driven jazyk - tech veci, co mohou aplikaci zastavit, v JS moc nenajdes (vyjimka - nektere node knihovny).Disclaimer: Nerikam, ze Node (ci obecne single threaded async processing model) je lepsi nez jine jazyky / technologie / pristupy, ale ze diky tomu nektere problemy proste nevznikaji a/nebo se lepe debugguji :)
P.S.: Pokud to nahodou nekdo nezna, tak pro ladeni node aplikace v DevTools staci spustit node s parametrem --inspect a pak otevrit chrome://inspect v Chrome a voila.
-
. . (neregistrovaný)
díky, tohle ale v praxi nefunguje, mluvím hlavně o node.js, aplikace v prohlížečích se ladí o trochu lépe, většinou nepracují s příliš daty a neřeší IO, blokující volání lze přes debugger odhalit snadno.
Mluvím o tom, když v node.js (či obecně v js) mi blokuje něco event looopu (parsování 10M jsonu), v téhle době ani --inspect ti nic pořádného neřekne (krom toho --inspect nefunguje řádně na všech verzích, způsobuje pád procesu, má šílené nároky na produkční provoz a nelze ho zapnout již u běžícího procesu).
Dalším velkým problémem, kdy vzniká memory leaky je zapomenutý callback, GC, které nestihlo promazat data, přeplněný IO buffer (input, output). K tomu díky features, react.js a dalším běžně použivaným frameworkům mi callstack moc neřekne, nedokážu se ani snadno dostat k datům z heapdumpu.
Nepomlouvám js (či node.js), nějaké problémy musejí řešit i u jiných prostředí v produkci. Zajímalo mě, jestli někdo nemá nějaké typy. Skončil jsem dopsanými dtrace probes i na nové LTS verze (už to moc nikdo neudržuje), dopsal jsem si vlastní thread pro monitoring GC, detekci zapomenutých callbacků, detekci dlouhých blockových volání atd. Je to ale náročné udržovat a už se tomu tolik nevěnuji. Zajímalo mě, jestli někdo řeší produkční provoz js backendu.
-
Tak na to většinou slouží profilery, ne? Tam zjistím, v jaké funkci mi to tráví čas, dohledat proč je pak už samozřejmě na programátorovi, ale to je u většiny jazyků stejné.
node.js není špatný, napsat prototyp v tom trvá chvilku, ale pohled pod pokličku a náklady na údržbu jsou důvody, proč už jej téměř nepoužíváme. Na jednorázové věci je ale vynikající. -
. . (neregistrovaný)
ano, na to je profiler a testování na nějakém "horké křesle", ale generická či testovací data často neodpovídají produkci, kde sice často podle call stacku, který si vytáhnu z paměti zjistím, na které funkci to vázne, ale už mi chybí ten důvod (mnou zmiňovaný 10M jsonu např.).
Poptával jsem, jestli někdo nezná nějaké out of box řešení pro node.js/js obecně. Souhlasím, že náklady na provoz node.js v produkci jsou dost vysoké kvůli neexistujícímu ekosystému.
-
. . (neregistrovaný)
source mapy jsou primárně pro prohlížeče a primárně pro případ, kdy kód generuješ/kompiluješ. To se zpravidla u servových aplikací nedělá, není totiž potřeba mít vše v jednom souboru a klidně na disku to mohu mít celé rozložené.
Sourcemapy ale moc ničemu nepomůžou, nezlepší mě čitelnost futures konstrukcí z call stacku atd.
-
. . (neregistrovaný)
většina? V jakkých projektech/společnostech pracuješ? Máš nějaký podklady nebo jen posuzuješ podle sebe protože děláš v reactu, coffeescriptu a používáš babel?
Source mapa každopádně není řešením toho co jsem psal, pořád je problém s callstackem u řady async/await frameworků, kde mi nic neřekne :)
-
mmm (neregistrovaný)
čemu říkáš async/await framework? Zrovna kód obsahující async/await musel být ještě nedávno vždy překládán babelem. Node.js a většna prohlížečů stále nepodporuje pokročlejší featury jako async iterátory. Většina npm modulů používá minimálně babel nebo je rovnou napsaná v typescriptu nebo jiném jazyku.
tohle nebude fungovat bez překladu babelem nikde
https://jakearchibald.com/2017/async-iterators-and-generators/
vygenerovaný kód je asi 20x delší a vyznat se v chybovém výpisu bez source map je těžké.
-
. . (neregistrovaný)
chybové výpisy ať si řeší vývojář a ten ať si používá co chce :), já se ptal původně na provoz ze strany administrátora. Async.js třeba žádný generátor nepotřebuje, async/await je v node.js od 7.
Opět tady házíš vycucané argumenty z prstu, píšeš, že většina npm modulů používá babel, podle libraries.io to jsou jednotky procent podle verze, https://libraries.io/npm/babel-core/usage?page=2&requirements=%5E6.1.21
-
mmm (neregistrovaný)
async.js je sračka, která se používala před příchodem promisů. async/await už je podporované všude, ale ještě nedávno tomu tak nebylo a já psal o async iterátorech. Ty jsou až v nodejs 8 a musí se explicitně zapnout. Když chcete fungovat i na starším node a v prohlížeči, musíte použít babel.
-
MarSik (neregistrovaný)
A všechno to co jste popsal se u produkční aplikace typicky nedělá. Snižuje to výkon, rozhodí to časování (co asi udělají timeouty, když zastavíte vlákno v debuggeru?) a je to nebezpečné z hlediska stability.
Povídat si jinak můžu s jakýmkoliv procesem, mám gdb (nebo dokonce gdbserver). A to nemluvím třeba o JVM, kde je vzdálené sledování stavu ještě o krok dál (JMX například).
-
koroptev (neregistrovaný)
ty timeouty nevim, ocekaval bych, ze se zastavi i task queue
gdb bez ladicich informaci (tozn typicky ostry release) ukaze co? disassemblovane instrukce? to se opravdu neda srovnat s povidanim kde k hovoru pouzivam slova popisujici abstrakce jazyka ve kterem jsem vec vyrobil..
-
MarSik (neregistrovaný)
Jak zastavíte expiraci TCP spojení na firewallu? Nebo nějakou úplně jinou aplikaci, která čeká na odpověď? Dnešní distribuované systémy jsou o dost složitější..
Ladicí informace nemusí být součástí běžícího procesu. GDB je umí nahrát i z jiných zdrojů (třeba debuginfo balíčků).
Jak se třeba v Pythonu nebo Ruby připojíte k běžícímu procesu? Jde o to, že zevšeobecnit to na "dynamické jazyky se dobře ladí" je přílišné zjednodušení. Protože třeba Erlang je kompilovaný a umí to, Java je kompilovaná a umí to. Python a Ruby jsou dynamické, skriptovací a přesto to neumí.
-
koroptev (neregistrovaný)
jasnej bottleneck tohoto je use case kdy chci svuj projekt tvorit v reasonml s pouzitim nejake velke existujici a proverene js knihovny, pro kterou nikdo neudelal nejaky wrapper; bylo by fajn, kdyby existoval nastroj, ktery by takoveto wrapper umel spolehlive automatizovane vyrabet z typovych definic typescript, kterych existuje mnoho pro vsechno mozne
-
Radek Miček (neregistrovaný)
Asi narážíte na spojení silný typový systém. Tímto spojením nemám na mysli nějakou přesně definovanou vlastnost, snažím se tím jen říci, že pomocí typového systému Reasonu lze popsat více než pomocí typových systémů populárních staticky typovaných jazyků. Mluvím tedy o vyjadřovací síle typového systému.
A samozřejmě, existují typové systémy, které jsou mnohem silnější než ten Reasonu. Např. dovolují popsat, zda funkce skončí nebo dokonce jakou má časovou složitost.
-
andy (neregistrovaný)
Protože pokud jste někdy viděl jazyk se skutečným typovým systémem, tak, jak už tu někdo psal, dojdete k tomu, že python (a spol.) jsou jazyky s jedním tagovaným typem. Prostě když v tom reasonu napíšu (neumim ocaml, takže plus minus):
type tenJedenTyp =
| Cislo(int)
| Retezec(string)
| Bool(bool)
| Desetinne(double)
| Trida(string, tenJedenTyp, tenJedenTyp String.Map.t }Tak mám +/- hotový celý typový systém pythonu. Dokonce i v té "strong" variantě...
Ale on typový systém s jedním typem... no je lepší než žádný typový systém, ale fakt toho moc neumí. Jako třeba staticky něco garantovat. A to vypadá, že reason umí, už třeba proto, že těch typů má trochu víc než jeden.
-
andy (neregistrovaný)
Tohle je hra se slovy a definicemi :) Zrovna jsem začal číst Pierce (types and programming languages, dá se to najít i online), a tam používá následující "neformální" definici:
A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.
No a v pythonu (pokud pominu nedávno přidané typové anotace, které skutečně jsou nějakým typovým systémem) nic takového není. Ještě jedna citace:
The word “static” is sometimes added explicitly—we speak of a “statically typed programming language,” for example—to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme, where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced
by “dynamically checked,” but the usage is standard. -
React Fiber ovšem není převratná technologie. Jak si tedy bůhvíproč polovina komunity kolem Reactu co se nenamáhala nastudovat co vlastně vývojáři Reactu dělají a dokonce ani jak některé vlastnosti v prohlížeších fungují myslí. Je to něco, co React potřebuje, co zvýší jeho výkon některých aplikacích ale na druhou stranu taky něco, co z veké části řeší problémy s ním samým.
-
Jakub Valenta (neregistrovaný)
Doplním jenom, že scala jde také kompilovat do nativního kódu http://www.scala-native.org/.
