Názory k článku Dyon: spojení předností Rustu a dynamicky typovaných programovacích ja­zyků

Osobně bych považoval za omezení nutnost řešit životnost proměnných.

scope proměnných jinde řeší garbage collector.

Cože? :D

Je to trochu opruz, ale vzhledem k tomu, že je to jazyk nad Rustem, není to mimo. Mně by spíš přišlo omezující, že to umí pracovat jenom s floatem a podporu celočíselných (přesných) čísel tam nevidím.

tak a teď mám podezření, že i část tvých výborných článků vlastně nepíšeš ty sám... To je skoro podvod na čtenáře rootu :)

pojmenované funkce nejdou definovat uvnitř funkcí (nebo možná jdou, ale nevím jak).

třeba tohle nevím jak bych bez uzávěru udělal:

fn fce(y) -> {
return \(x) = x * (grab y)
}

fn main() {
f_2 := fce(2)
println(\f_2(3))
}

neznal jsem a líbí se mi to. Rust mě oslovil a už jsme přešli s řadou projektou, snížila se o cca 30 % chybovost aplikací oproti java (což je ryze individuální metrika).

Existuje nějaký repl pro dyon?

Asi se zeptam trosku blbe (nemyslim to jako rypani ani nijak zle), ale mate ty projekty na GitHubu, treba jen pro inspiraci nebo i zvednuti povedomi o Rustu? Protoze u jazyku tvori popularita dost podstatnou kladnou zpetnou vazbu...

bohužel, vše to jsou korporátní zmetky a zveřejnění v tomhle světě a století moc reálné není.

Však to ale není nic světoborné, drobné procedury a transformace a parsování různých dat, občas drobné analytické výtvory. Povětšinou to nepíší programátoři, ale stážisté a junioři a já jim jen lehce radím, blbuvzdornost je dost důležitá, je rozdíl práci vracet jednou nebo pětkrát :)

Zajímá mě, v čem je ten rozdíl oproti javě, že je ta chybovost o tolik menší? Když mi někdo napíše: přešli jsme z céčka na javu a už nemáme takové problémy s uvolňováním paměti, tak tomu rozumím, ale vím že gc není samo-spásný, že je větší problém lenost a nedisciplina programátorů ... Co je teda ten rozdíl - třeba i subjektivně .-) Dík

Připojil bych se s dovolením k dotazu, konkrétně:

1. Je zajímavé, že se to projevilo na tak malých programech. Dovedu si představit nějaké důvody (imutable proměnné apod., možná i kvalitnější stážisti, kteří jsou vůbec Rust pobrat). Dá se to teda nějak popsat?

2. Předpokládám, že tam zaměstnáváte na tyhle blbinky ucha bez praxe, tudíž nemají nějaké hluboké znalosti knihoven Javy a tak to vyjde nastejno. Kdo ale s tím přišel, že to budete dělat v Rustu a proč?

Díky.

nelze to zobecňovat a nechci pomlouvat ostatní jazyky či rust glorifikovat. Základem je špatný programátor, pokud někdo umí skvěle programovat, je šumák, který jazyk použije a výsledek bude vždy nadstandardní.

Rust hromadu chyb odchytí při kompilaciu. Řada "programátorů" zkouší napsat program do té doby než jim přestane křičet IDE a než jim jde zkompilovat, pak ho často odevzdávají. V javě nebo pythonu těch chyb tímhle procesem prochází víc.

Problém je objektovost, lidé, kteří neznají dobře OOP paradigma, ztrácí se v tom, nerozumí struktuře a chtějí přemýšlet spíše víc funkcionálně, ale haskell či clojure je pro ně už moc. Jde i o závislosti, které musí používat.

Rust má přehlednější dokumentaci (ryze subjektivní) a oproti scale nebo pythonu se v ní lidé méně ztrácí, daleko dříve jsou schopni přijít s řešením.

Přímočařeji se tam řeší závislosti a sdílení datový struktur, lépe se copy-pastuje kód z jiných projektů či od kolegů. V javě skoro nikdo testy nepsal a v rustu si velice rychle zvykli psát testy přímo na konci souboru spolu s kódem, proč ne. Možnost kód napsat v jednom souboru se vším všudy je opět malá přidaná hodnota. Oni si ho pak sdílí emailem a funguje jim to. Napsaný program si většinou spouští přímo z IDE (terminál je vidět zřídkakdy) a u rustu se daleko přehledněji zobrazují chyby a rychleji najdou, co mají špatně, s Javou to končilo konzultacemi se zkušenějším.

Vývoj v korporátní sféře je hodně jiný, na efektivnost a standardy se často kašle, unit testy jsou výjimkou, k aplikacím je vždy support od vendora a on si pohlídá, že běží. Testování výsledné aplikace je jen na očekávané vstupy, důležitá je dokumentace, pokud něco na vstupu přijde jinak, hned se to porovnává s dokumentací a pokud to je špatně, za vše může zdroj a ne vendor. Vše píší neprogramátoři či teoretici.

Tvrdit jak je programování vznešený obor a jak je potřeba vše psát s láskou si můžeme říkat max. mezi sebou. Jakmile člověk uvidí realitu dělníků u vývoj SW, je trochu zhnusený. Já k téhle zoo poskytuji externě konzultace tak, aby se pohlídala technologická kvalita, občas mám nějaký workshop, na jednom jsem ukázal rust a u asi 10 jedinců se chytl a postupně ho začali používat, bylo zajímavé sledovat jak to dopadlo ve srovnání s javou, scalou a pythonem.

Já Rustui dost fandím, každopádně díky za info. Ať se daří!

Tak to jste ale vyměnili programátory a ne jen jazyk, viď? Proč lžeš?

kdyby to aspoň nějací programátoři byli :). Jedná se o stejné lidi, kteří do té doby psali v javě/scale, ale jak jsem psal v jiném příspěvku, nejsou zkušení a je to ryze individuální věc a nelze v žádném případě zobecňovat a ani to házet na jazyk.

ono je to tezke, nez se stacim zorientovat v nejakem novem jazyce, tak prinse pan Tisnovsky na rootu nejaky dalsi ....

Mě jen trápí, jak nové a nové jazyky přicházejí vždy s jinou syntaxí, když léty ověřená a geniální C-like syntaxe (počítám do toho i Javu apod.) není čím vylepšovat. Myslím tím syntaxi; aťsi přibývají uzávěry a nové konstrukce, počítání referencí, více kontrol při kompilaci (jen houšť!). Ale proč tu máme podmínku if-u bez závorek, příkazy neoddělené středníky... Abych se vyjádřil více k článku - ty backslashe v Dyonu jsou fakt eklhaft!

Trosku to zavani Wadlerovym zakonem :) https://wiki.haskell.org/Wadler's_Law ale ja celkem chapu, proc se nektere veci z cecka zahazuji. Napriklad vynuceni bloku {} v podminkach a smyckach, to resi docela dost chyb, ktere se mnohdy najdou az na produkci (GOTO fail...). Zavorky okolo podminek je mozno psat porad ne? Ty prece nemeni hodnotu vyrazu a stredniky, hmm, jsou fakt potreba jako druhy oddelovac? (po konci radku)? Popravde nevim, delam v jazycich s i bez stredniku a mentalni prepinani jde tak nejak automaticky.

S temi backslashi ale mas naprostou pravdu. Nevim proc proste nejsou funkce first-class objekty jako napriklad v JS nebo v Lue, tim by se automaticky vyresila i problematika uzaveru ;) Mozna to jeste zmeni a celou tu syntaxi s backslashem (to je asi napodobenina lambdy) pujde pryc, nebo povoli primo zapis lambdy, coz by bylo cool (a neprakticke soucasne :)