Názory k článku
Rust-coreutils cp má problém s vytvářením live obrazu v Ubuntu

Náhoda většinou (možná vždy) označuje jen situaci, kdy neznáme příčinu. Což ale neznamená, že ta příčina neexistuje.

Jdu si vsadit Sportku, u náhody jen neznáme příčinu, takže mě nemůže pravděpodobnost rozházet. :)

Zrovna u Sportky tu příčinu známe docela dobře, je to pár fyzikálních zákonů. Akorát vás asi nenechají dostatečně přesně změřit počáteční stav a nespočítáte to. Ale v kasinech to občas někdo spočítá, nebo se o to snaží.

Já ti nevím. Najdi mi druhej podobnej jazyk, který má safety first by default, a je tak nízkoúrovňovej jako Rust.

Vždyť jsem tu už psal ATS (Applied Type System). Má silnější typový systém a rychlost jako C. A navíc je starší, takže existoval před Rustem.

Pisali ste o typovom systeme a tu sa bavime o safety first. To su dve uplne odlisne veci.

Jsou to dvě věci, co jsou odlišné, ale dost spolu souvisejí. Tu bezpečnost budeš bez promyšleného typového systému dělat obtížně.

V životě jsem o něm neslyšel, tudíž bratři jsou ještě horší markeťáci jak já.

Vypadá to zajímavě, tudíž díky za něj.

Takhle od stolu odhaduji, že problém nerozšíření ATS je v tom, že se o rozšíření moc nesnažili, vývoj je spíše pomalejší, a ta syntaxe je přesně o ten drobet za hranou než běžný vývojář dokáže snést.

BTW: Máš představu, jakej problém je vysvětlit běžnému vývojáři, k čemu je užitečné statické typování? Mě se to líbí. Ale já jsem programátorskej fanatik.

to nekdo potrebuje vysvetlovat, ze je dobre prekladaci pomoct dodanim maximalniho mozneho mnozstvi informaci, aby mohl na oplatku pomoct mne tim, ze me nakope uz behem prekladu, zejmena pokud je preklad destruktivni / reduktivni v informacich o typech?

Ty vole! A navíc neúspěšně.

at zijou paralelni pole v C++ svazane proti poradi enumu (neclassoveho)

On pan Jirsák sice pracuje v jedné korporaci, ale zdá se, že přesto neví, jak to tam funguje. U nás v jiné korporaci se před započetím vývoje neřeší nejvhodnější jazyk, ale na který jazyk máme volné kapacity.

To s tím exhaustivity checkem jsem nepochopil. Znamená to třeba, že když u Option pořeším jenom Some<T>, je to v pohodě?

Móda podle mě pro preferenci syntaxe není dostatečné vysvětlení. Móda se mění, nicméně ML, LISP atd. nikdy masově neprorazily. A že se u toho LISPu a jeho dialektů opakovaně vývojáři snažili.

Zato prorazil JavaScript, jen proto, ze mel lepsi startovni caru. Co to rika o tom, jak dobri jsou develove pri vyberu technologii, to je na zvazenou :)

> Zato prorazil JavaScript, jen proto, ze mel lepsi startovni caru. Co to rika o tom, jak dobri jsou develove pri vyberu technologii, to je na zvazenou

No a dnes už to je jazyk postupně nahrazován TypeScriptem. Pokud se bavíme o frontendu, tam je to rozhodnutí výrobců browserů.

> Pokud se bavíme o frontendu, tam je to rozhodnutí výrobců browserů.

Představme si situaci, že třeba Ladybird přibalí cojávím, tcl. Vývojáři budou mít na výběr a) stejně poslat klientovi javascript, anebo b) vyžadovat jeden konkrétní prohlížeč, protože nikdo z ostatních se do toho nehrne.

To rozhodnutí je dané vlastně jenom setrvačností toho, že spousta věcí už v javascriptu je - tedy se ho nedá dost dobře zbavit - a když už v prohlížeči jeden jazyk je, experimentování s čímkoliv jiným bude mít jenom omezený dopad, ledaže by se prohlížeče shodly. Všichni se shodli na javascriptu; a pak až na wasm. Nevidím naději, že by tady prorazil nějaký lepší jazyk.

Hezká teorie, kterou v praxi vyvrátilo WebAssembly.

Jojo, škoda, že jsem se o něm ani nezmínil. Kde mám ten klobouk...

Zmínit nestačí. Je potřeba také vzít na vědomí, změnit názor tak, aby odpovídal faktům – a pak napsat úplně jiný komentář.

Tož against my better judgement:

• Fakt: Javascript se objevil v roce 1995, wasm až 2017. Dvacet let je dlouhá doba - obzvlášť v IT.
• Fakt: Wasm je specifikací virtualizovaného procesoru, ne programovacím jazykem.
• Fakt: Wasm neumí sám o sobě manipulovat s DOMem, nelze ho tedy pokládat za náhradu javacriptu.
• Fakt: Ani samotná inicializace wasm knihovny se neobejde bez javascriptu
• Závěr: Wasm nenahrazuje javascript, je to bajtkód a trvalo bratru dvacet let, než se vůbec objevil.

Existence wasm tudíž není v rozporu.

Přínosné pro další diskusi by bylo zpochybnit některý fakt (se zdrojem!), nebo demonstrovat chybu v logice. Cokoliv dalšího budu mít na salámu...

Jazyk C se objevil v roce 1972, Rust v roce 2006. Obě ty informace o rozestupu vzniku jazyků nevypovídají samy o sobě o ničem. Nebo jinak – ten časový rozestup nevyvrací tvrzení, že když se objevila potřeba používat na webu jiný jazyk, tak se ta potřeba naplnila. A ne jednou – kromě wasm tu máme TypeScript a další jazyky, které ten problém řeší transpilací do JavaScriptu. Mimochodem, Internet Explorer kdysi podporoval i VBScript.

Wasm v současné podobě není ani zdaleka hotový. V různém stádiu rozpracovanosti je spousta návrhů, např. na Component Model, který by mohl umožnit integraci na Web API.

Wasm vskutku není jeden jazyk, naopak je to způsob, jak do prohlížeče dostat libovolné množství jazyků.

Aplikace v Rustu používají spoustu knihoven z C, a je to silná stránka Rustu. Stejně tak něco, co umožní v prohlížeči používat i jiné jazyky, než JavaScript, vůbec nemusí JavaScript 100% nahradit.

Takže existence JavaScriptu nebrání experimentování s jinými jazyky. Autoři prohlížečů se shodli na WebAssembly, což je způsob, jak umožnit v prohlížečích používat prakticky jakýkoli jazyk – pokud ho dokážete přeložit do wasm. Jiné jazyky se díky tomu v prohlížečích používají. Např. Figma, která má dnes téměř monopol jako nástroj pro UX designery, je napsaná v C++ a v prohlížeči běží ve WebAssembly. Nebo SurrealDB – dokumentová a grafová databáze napsaná v Rustu – může běžet díky WebAssembly přímo v prohlížeči (nepodporuje všechny storage, ale podporuje IndexedDB) nebo JavaScriptových/wasm enginech (třeba Deno).

> kromě wasm tu máme TypeScript a další jazyky, které ten problém řeší transpilací do JavaScriptu. Mimochodem, Internet Explorer kdysi podporoval i VBScript.

Jinými slovy všichni autoři náhrad javascriptů berou javascript jako fakt se kterým nepohnou, a ani Internet Explorer (v té době dominantní prohlížeč) nedokázal místo JS prosadit něco jiného.

Nějaké teoretické možná budoucí funkce wasm nejsou na újmu faktu, že v současnosti to wasm neumí, a u klienta není na výběr než použít javascript.

> Takže existence JavaScriptu nebrání experimentování s jinými jazyky.

Které prohlížeče experimentovaly se kterými jazyky? Zatím teda víme o VBScriptu, který se vlastně vůbec neuchytil. Podstatné slovo je asi to experimenty, protože přes veškerý bordel v javascriptu se v nice javascriptu nikdy neuchytilo nic lépe navrženého.

Stále ignorujete WebAssembly, které je implementované ve všech moderních prohlížečích a umožňuje spouštět kód napsaný v různých jazycích. Smysl použití jiných jazyků v prohlížečích není v tom zadupat JavaScript do země, aby se na webu úplně přestal používat. Smysl je v tom, aby bylo možné si vybrat.

Typescript je spíš nadstavba nad JS, než svébytný a jiný jazyk.

IMO při psaní matche je lehké si pohlídat, zda jsem pokryl vše, co potřebuji. Co je těžké, a kde exhaustivity check pomůže, je když enum rozšířím - díky exhaustivity checku nemusím procházet všechny matche, abych je zkonbtroloval, ale kompilátor mě na to může upozornit.

Proč bych si ale něco hlídal, když to jazyk dělá za mě? Vždyť to nemá v zásadě žádné výhody.

Chtěl jsem říct, že je dost situací, kde exhaustivity hlídat nepotřebuji a třeba i v Rustu použiji _ => {}.

> třeba i v Rustu použiji _ => {}

Jenže to není totéž, nebo je?

Pardon, máte pravdu. Moje chyba. V Rustu použiji něco jako

match foo {
  Jedna => ...
  Dve => ...
  Tri => ...
  _ => panic!("Absurd")
}

typicky, když už jsem na &foo nějak matchoval, např. pomocí Jedna | Dve | Tri => ..., takže vím jistě, že další match musí uspět v jedné z prvních 3 větví, ale kompilátor Rustu tvrdí Non-exhaustive patterns.

A používám to k tomu, když všechny 3 případy mají nějakou společnou logiku - napřed použiji or pattern, provedu společnou logiku, a pak matchnu znovu na jednotlivé případy, abych provedl logiku specifickou pro jednotlivé případy.

> typicky, když už jsem na &foo nějak matchoval, např. pomocí Jedna | Dve | Tri => ..., takže vím jistě, že další match musí uspět v jedné z prvních 3 větví, ale kompilátor Rustu tvrdí Non-exhaustive patterns.

Mně tohle přijde jako špatný návrh. Potřeboval bych vidět reálný kód, kde tohle je dobrý nápad. Smysl enumů je právě v tom, že cíleně omezují možnosti vstupu na smysluplné hodnoty, to není switch z C nad charem nebo intem.

Jinak v Rustu bych určitě použil třeba unreachable!, ale nemělo by to být nutné. Mimochodem, příklad z https://doc.rust-lang.org/std/macro.unreachable.html je dost blbý (dá se řešit lepší definicí druhého matche), což je pro mě indikace, že by se tohle fakt stávat moc nemělo.