Projekt Quantum (diskuse)

[little.owl]

Psat tak zasadni komponentu jako je renderovanci jadro prohlizece ve stale experimentalnim nestandardizovanem jazyce jako je Rust me tedy nanaplnuje nadsenim.

[sid]

Preco? Pride mi to podstatne bezpecnejsie a rozumnejsie ako pisat to v c++ ktory mi coraz viac pripomina rozpravku jak pejsek a macicka pekli dort. Aj ked mozilla co viem pouzivala iba cast c++ co je zase take trochu schizofrenicke.

[D.A.Tiger]

No nevim. Za me - zlaty Webkit... Skoda jen, ze je docela obtizne (a hlavne na dlouho) jej portovat do jineho frameworku ;)

[little.owl]

Pride mi to podstatne bezpecnejsie

Pokud omezite nizkourovnove C konstrukce, a pouzijete novejsi vlastnosti C++, lze psat pomerne bezpecny kod.

a rozumnejsie

Mozna za pet nebo deset let. Psat neco takoveho v jazyku, kde neni zarucena kompatibilita, a ve verzi 2.0 muze byt vse jinak, pokud to vubec bude Mozilla schopna financovat, neni IMHO moc rozumne.

Je to jen takove cereni vody, Mozilla bude muset drive ci pozdeji adoptovat Blink, maly podil na poli prohlizecu je k tomu donuti. Ostatne jejich byvaly CEO a zakladatel, velky tvurce Javascriptu, Brendan Eich, pracuje na novem prohlizeci Brave, postavenem prave na Blinku, coz mluvi samo za sebe.

ktory mi coraz viac pripomina rozpravku jak pejsek a macicka pekli dort.

Ten jazyk ma za sebou 35 let vyvoje, udrzuje si zpetnou kompatibilitu, ma plno vyvojaru a velke mnozstvi realnych projektu. On by nebyl problem ten jazyk procistit, pokud by se obetovala zpetna kompatibilita, a je dosti mozne ze se tak stane.

[nyan]

a je dosti mozne ze se tak stane.

To jses teda docela naivni. Nestalo se to za poslednich 20 let, nestane se to ani pristich 20. Maximalne se sem tam neco udela deprecated, jinak se tam porad budou cpat nove featury.

Kdyby chteli odstranit nejakou zasadnejsi cast jazyka, museli by to vydat jako uplne novy jazyk, a uprimne neverim ze ted s tim maji moc nadeje na uspech, konkurence je docela slusna a aktivni.

[little.owl]

Konkurence je irelavantni pokud nema podporu velkych hracu schopnych se domluvit na nejakem standardu a protlacit to - tady mluvim o firmach jako Microsoft, Google, Facebook a spousta dalsich.

[nyan]

Ano a kdo bude protlacovat ten tvuj shiny new C+++ ? Google ma Go, Facebook si dela v Haskelli... irelevantni bude prave ten C+++ protoze vetsina velkych hracu uz ma vystarano.

[little.owl]

Ani Haskell a ani Go nejsou alternativou k C++. Plno soucasnych standardu je dusledkem dohody velkych hracu, pro ktere je od urcite urovne standardizace a interoperabilita vyhodna, a bez adopce z jejich strany je standard jen car papiru. To je i situace C++, kdy v soucasne standardizacni komisi (WG21) a pracovnich skupinach tvori naprostou vetsinu lide primo spojeni s firmami jako Microsoft, Google, Facebook, Hewlett Packard, Oracle, Bloomberg, Intel, Morgan Stanley, USPS, Red Hat ci nektere staty tam posilaji reprezentatnty svych standardizacnich teles (Spanelsko, Holandsko, Nemecko, Britanie), ktere reprezentuji zajmy jejich prumyslu (opet velke firmy). Stejni hraci fakticky plati vyvoj kompilatoru, at jiz proprietarnich ci FOSS. To jak C++ bude v budoucnu vypadat, zalezi na jejich zajmech, je to logicke, maji v C++ miliony radku kodu v produkci a zamestnavaji statisice C++ programatoru. Podobna situace je i u Javascriptu. Navic, nikdo nemluvi o shiny new C+++, staci se treba domluvit na limitovanem subsetu stavajiciho standardu, ktere bude kompilator s vhodnym flagem vynucovat, a ktery pozdeji muze samostatne divergovat od C++, za predpokladu ze interoperabilita bude zachovana a naklady na refaktoring soucasneho kodu nebudou velke. To se ve WG21 jiz resilo a resi a v nejake forme to tam mozna casem asi bude, oni si uvedomuji, ze pridavat desitky a desitky dalsich stran k jiz tak rozsahlemu standardu uz neni mozne.

[Petr]

A není to všechno jedno, když se Rust i C++, ale třeba i Swift, nebo Haskell mohou kompilovat do LLVM?

[mica]

Mozilla bude muset drive ci pozdeji adoptovat Blink, maly podil na poli prohlizecu je k tomu donuti

Přechodem na Blink se podíl Firefoxu mezi prohlížeči zvětší? A jak? Uživatelům je přece jedno, jaké jádro v prohlížeči je, neboť většina jich o existenci něčeho takového ani neví. Uživatelé dají hlavně na rozhraní.

[little.owl]

Uzivatele hlavne potrebuji, aby jim to fungovalo. Podil Firefoxu (Gecka) klesa, jiz je pod deseti procenty a propad pokracuje. To muze vest k tomu, ze veci v nem pomalu prestanou optimalne fungovat. Mozna smerujeme k monokulture Blinku (a neceho od Microsoftu) a frameworky jako Electron to jen urychluji.

[Ivan2]

Protoze to uz jednou zkusili a nedopadlo to dobre. Puvodni Mozilla byla napsana kompinaci JS+XUL(XML). Na prvni pohled to vypadalo vyborne, ve skutecnosti to byla katastrofa. Nikdy to nebylo dokoncene, doladene, zdokumentovane. API se neustale menilo. Chybely nastroje pro vyvojare s celkove se v tom psalo velice spatne.

PS: s tim ze pouzivaji jen cast z C/C++ by se to dalo castecne chapat. Pokud maji ale problemy s tim, ze C a C++ nejsou prenositelne, tak to nevyresi vlastnim jazykem. Problemy jsou hlavne s kompatibilitou standartnich knihoven. Navic tenhle problem uz vlastne davno vyresili tim, ze prestali podporovat obskurdni architektury.

[Mike]

Dneska jsou v podstate jen 2 kompilovane memory-safe jazyky v kterych lze psat bezpecny kod - Rust nebo Go (je jich samozrejme vice, ale tohle jsou jedine ktere maji sirsi podporu). A Rust narozdil od Go nema GC a umoznuje psat vice nizkourovnoveji.

Napsat ze bezpecny kod lze psat i v C++ je sice hezke, to lze teoreticky i v asembleru, ale tak to v realite fakt nefunguje

[Mike]

A vubec, psat v dnesni dobe tak exponovanou vec jako jadro browseru v memory-unsafe jazyce je vyslovene hazardovani s bezpecnosti vsech uzivatelu.

[kralyk z abclinuxu]

Jakkoli jsem fanda Rustu, je potřeba mít na paměti, že použití Rustu sice pomáhá, ale zdaleka neřeší všechny bezpečnostní problémy...

[little.owl]

Dneska jsou v podstate jen 2 kompilovane memory-safe jazyky v kterych lze psat bezpecny kod

Ale velke kulove. Bezpecny kod lze jiz psat asi tak 30 let v ADA - standardizovany, kompilovany, deterministicky memory management, task based concurrency bez data race a jedna se o lety overeny jazyk pouzivany v kritickych systemech. Gcc ho podporuje jiz mnoho let (GNAT, AdaCore). Ve skutecnosti poptavka po takovych jazycich neni zas tak velka a bezpecny kod neni jenom o memory managementu, jak se snazi nabulikovat tvurci Rustu.

[Mike]

Nejak jste ucelove vynechal to co jsem psal v zavorce: "je jich samozrejme vice, ale tohle jsou jedine ktere maji sirsi podporu".

Kdyz pisu podporu, myslim tim sirokou podporu open source vyvojarske komunity. Staci se podivat treba na statistiky GitHubu, v jakych jazycich lide pisou. ADA se dneska siroce rozhodne nepouziva (jen v nekterych specifickych odvetvich).

[little.owl]

Staci se podivat treba na statistiky GitHubu, v jakych jazycich lide pisou.

Nekdo dava vahu realnym projektum v producknim nasazeni (radary, roboty, ridici systemy vlaku, letadel, tanku, druzic ci elektraren), a nekdo statistikam programatorskych cancu na GitHubu. V podstate jsem jeste nevidel jediny realny projekt, ktery by prokazoval, co Rust slibuje a zatim to vypada jako hype, ktery tu byl treba u jazyka D.

[sid]

Napr. Dropbox ma cast systemu v rust, kdesi sa da najst zaujimave pokec o tom

[sid]

Btw toto je trocha uletena argumentacia. Sam dobre vies, ze to su extremne specificke veci kde sa hladi na jednoduchost, odladenost, dokazatelnost a tudiz to tazko brat za bernu mincu. Podobne tiez nehanis moderne procesory a vravis ze sa treba pozriet napr na raketoplan a jeho cpu. Rovnako tam ako OS nenapchas linux ale to neznamena ze by sa medal linux pouzit inde

[little.owl]

Prave proto pisi, ze Rust jeste neni production ready, bude potrebovat cas se prosadit a prokazat.

Napr. Dropbox ma cast systemu v rust, kdesi sa da najst zaujimave pokec o tom

Jiste. A Facebook ted premysli o prepsani Mercurialu zkusebne v Rustu, a predtim zkouseli psat veci v Haskell, ale nadseni jiz vyprchalo. Kdyz dojde na lamani chleba, pisi vetsinu veci v Php a C++.

[kralyk z abclinuxu]

V podstate jsem jeste nevidel jediny realny projekt, ktery by prokazoval, co Rust slibuje

No a nebyl by tento projekt právě něčím takovým? Připadá mi, že ses v diskusi trochu zacyklil. Požaduješ reálné nasazení, ale ve chvíli, kdy se o to někdo pokouší, to kritizuješ, protože nepoužívají prověřený jazyk.

[little.owl]

Jde o to, ze kriticke soucasti systemu by meli byt napsany v odladenem jazyce, ktery byl predtim nasazen na mene kritickych castech a renderovaci jadro prohlizece je pro me takovou soucasti. Servo je zatim jen vtip, domecek z karet, jako vetsina veci co v soucasnosti Mozilla dela.

[kralyk z abclinuxu]

Instalovat si to rozhodně nemusíš.

[Václav "Darm" Novák]

Nevznikl Rust právě pro účel přepsání jádra Firefoxu? (navíc, pokud jejich koncepci chápu dobře, moc těch méně kritických částí které by v Rustu psané být mohly nebude. Spíš to zatím směřuje k jádru v Rustu a UI v JS, asi jako je QML pro C++/Qt)

Jako člověk co píše nějakou větší aplikaci bych se možná nasazení Rustu bát kvůli případné budoucí nekompatibilitě mohl.

Ale tady vyvíjí aplikaci i jazyk stejná společnost. Pokud jim nějak funguje komunikace mezi teamy, bát se toho že by to při další verzi jazyka museli celé přepsat zas až tak nemusí.

[Bedňa]

C++ proste patrí do minulého storočia, na normálnu prácu sa proste použiť nedá, preto tu vznikli projekty ako U++, D a QT aby sa dalo Hello World napísať bez segfaultu.

Človek potrebuje preniesť myšlienku na reálny program a nie rozmýšľať čo po sebe neupratal, alebo zpísal tam kde nemal.

[Václav "Darm" Novák]

Souhlas, ovšem s tím že zrovna to co řeší Qt ohledně paměti už je teď z části duplicita. C++ 14 to zvládne taky. Jen je to v praxi horší. Kamarád nedávno utekl z jedné firmy, kde nechtěli vůbec slyšet ani o C++ 11. Starý kód často novým kouskům nenaučíš. Ostatně, my taky pracujeme v prehistorické syntaxi jazyka, protože rewrite by byl moc drahý a velká část programátorů by to nedala.

[sid]

Vcelku suhlasim aj ked moja skusenost hovori, ze clovek co dokaze realne robit v c ma svojim sposobom urcitu vyhodu aj ked robi napr v jave lebo je navyknuty na urcitu disciplinu v kode a je celkom obozretny. Alebo inac povedane nepotrebuje aby ho jazyk viedol vsade za rucicku. Zopar spring/hibernate/jsf architektov co nedokazali zosynchronizovat lahke veci som uz videl.

[Václav "Darm" Novák]

Na stranu druhou nesmí u toho C zůstat. C psaného v C++ je plno a občas je to vidět i v jiných jazycích.

[little.owl]

C se zbytecne demonizuje. Bezpecnost "bezpecnych" jazyku je dosahovana predevsim restrikcemi co programator muze udelat a to lze u do znacne miry C/C++ vynutit externimi nastroji, a pritom je mozne pouzit "nebezpecne" konstrukce pokud je potreba. Sila C je v jednoduchosti a tu molosi jako C++, ale ostatne i Rust nemaji.

[Bedňa]

Nechcel by som tu vyzerať ako nejaký nepriateľ C, ale mám pocit, že dnešné technológie už dokážu to zbytočné (a denno denné) alokovanie pamäte nahradiť niečim čo vyzerá ľudsky. Asembler a Céčko boli moje prvé dva jazyky ktoré som spoznal, takže fakt sa snažím len vysvetliť, prečo stále ležať priamo na HW, nemal by to riešiť, prekladač?

Napríklad, prepísať aj takúto banalitu do C, bude kopec práce naviac a prehľadnosť bude ta tam:

use std::mem;

// This function borrows a slice
fn analyze_slice(slice: &[i32]) {
    println!("first element of the slice: {}", slice[0]);
    println!("the slice has {} elements", slice.len());
}

fn main() {
    // Fixed-size array (type signature is superfluous)
    let xs: [i32; 5] = [1, 2, 3, 4, 5];

    // All elements can be initialized to the same value
    let ys: [i32; 500] = [0; 500];

    // Indexing starts at 0
    println!("first element of the array: {}", xs[0]);
    println!("second element of the array: {}", xs[1]);

    // `len` returns the size of the array
    println!("array size: {}", xs.len());

    // Arrays are stack allocated
    println!("array occupies {} bytes", mem::size_of_val(&xs));

    // Arrays can be automatically borrowed as slices
    println!("borrow the whole array as a slice");
    analyze_slice(&xs);

    // Slices can point to a section of an array
    println!("borrow a section of the array as a slice");
    analyze_slice(&ys[1 .. 4]);

    // Out of bound indexing yields a panic
    println!("{}", xs[5]);

}

[little.owl]

C je jednoduchy portable assembler, a tu funkci plni stejne dobre dnes jako v minulosti.

Rust je o ctyricet let novejsi jazyk nez C/C++ a je to videt. Roubovani dalsich vlastnosti do C++ nebude od urcite urovne mozne, uz ted je to na bednu a bude nutne prijit s necim jinym. Jestli to bude treba Rust, D, Nim ci treba se omezi zpetna kompatibilita a prijde se strojovym prepisem starsiho kodu, nevim. Jinak to srovnani neni az tak tragicke, treba pokus zde.

[Bedňa]

Tie príklady mi neprídu úplne relevantné, pretože Rust nedovolí len tak niekde omylom zpísať a hlavne vlákna sú v C++ dosť problém.

[little.owl]

Borrow checking je hodne silna stranka Rust a C++ na ni nema zatim odpoved. Herb Sutter a jeho team v Microsoftu sazi na statickou analyzu pri kompilaci, ale mam pochybnosti jestli se jim to podari.

[sid]

Lenze prave zasadny rozdiel medzi rust a go, nim atd je prave v tej alokaci. GC nie je vzdy zrovna vyhoda (a aj ked existuju neblokujuce GC je to vzdy nieco za nieco, v tomto pripade pamat navyse.) Cim systemovejsia vec to je tym menej je vhodne aby tam kdesi na pozadi strasil GC. Samozrejme ked sa bavime o beznom pouziti. Pri tom co robi google je v principe skor dolezita skalovatelnost.

[kralyk z abclinuxu]

C se zbytecne demonizuje. Bezpecnost "bezpecnych" jazyku je dosahovana predevsim restrikcemi co programator muze udelat a to lze u do znacne miry C/C++ vynutit externimi nastroji, a pritom je mozne pouzit "nebezpecne" konstrukce pokud je potreba. Sila C je v jednoduchosti a tu molosi jako C++, ale ostatne i Rust nemaji.

Problém s C není pouze v bezpečnosti, ale (IMHO) hlavně ve výřečnosti. Napsat cokoli v C vyžaduje strašně moc boilerplate kódu. A to, že standardní knihovna v roce 2016 stále ještě neobsahuje běžné algoritmy a datové struktury, situaci taky úplně nezlepšuje...

[kralyk z abclinuxu]

C++ proste patrí do minulého storočia, na normálnu prácu sa proste použiť nedá, preto tu vznikli projekty ako U++, D a QT aby sa dalo Hello World napísať bez segfaultu.

To řekni vývojářům herních enginů a podobných věcí. Qt, U++ apod. pouze využívají některé věci, které C++ umožňuje, můžeš je klidně používat i bez těchto toolkitů, s novými verzemi C++ tuplem.

Co se týče D, to pouze přidalo GC, o kterém si nikdo v D není jistý, nakolik by měl nebo neměl být předpokládanou součástí D.

[Bedňa]

Tie frameworky vznikly, pretože C++ bolo fajn keď vzniklo, ale proste dnes v ňom napísať aplikáciu vyžaduje veľa úsilia. Možno je to fajn, že naspodu je niečo, čo vie siahať nizkoúrovňovo a nad tým sú frameworky, kde dokážeme pracovať s roziahlimi poliami a nejak nemusíme riešiť ako si framework alokuje pamäť.

Skôr ma láka niečo ako Rust, keď už tu máme roky niekoľkojadrové procesory a písať programy, ktoré ich dokážu rozumne využívať, na toto v C++ môžeme zabudnúť.

Celkovo, dnes je doba, keď ľudskú prácu opisovania stále tých istých pravidieľ, nechajme kompilátoru, nešahajme do pamäti, zabudnime na ukazatele a na jazyku nechajme aj peklo s vláknami.

[kralyk z abclinuxu]

Možno je to fajn, že naspodu je niečo, čo vie siahať nizkoúrovňovo a nad tým sú frameworky, kde dokážeme pracovať s roziahlimi poliami a nejak nemusíme riešiť ako si framework alokuje pamäť.

Co se týče de/alokace paměti, tyhle frameworky neposkytují v zásadě nic navíc oproti standardnímu C++. Qt poskytuje navíc COW, zatímco standard je spíš pro move semantics. Žádný z těchto dvou přístupů není 100% objektivně lepší, je to spíš otázka stylu.

Já jsem též fanoušek Rustu, ale nic nemění na tom, že C++ je poměrně mocný jazyk. Že v něm můžeš zapomenout na vlákna se rozhodně říct nedá. Přijde mi, že C++ kritizuješ jen proto, že ho neznáš, ale můžu se samozřejmě mýlit...

[Bedňa]

Ako hovorí Pavlix neviem sa vymakčnuť o čo mi ide Tak napr. U++ používa kontajnery, takže všetko niekam patrí a radím to medzi dobrý nápad ako spravovať pamäť. No a v Ruste Concurrency, to sú hotové nástroje kde odpadá veľa vývojárskej práce pre paralelizmus.

C++ samozrejme postúpilo, ale nemám pocit, že by to bolo tak easy ako v iných projektoch, alebo žeby reagovalo na dnešné požiadavky.

[little.owl]

No a v Ruste Concurrency, to sú hotové nástroje kde odpadá veľa vývojárskej práce pre paralelizmus.

Podpory concurrency ma i C++11 a C11. Take mi prijde, ze o C++ uz moc nevite.

[deda.jabko]

A vymysleli uz neco lepsiho nez vlakna a zamykani?

[little.owl]

Zatim futures. Coroutines/resumable functions s await/yield se zatim do C++17 nedostaly, komise stale neni spokojena s navrhy, i kdyz MS je implementuje.

[deda.jabko]

Zatim futures.

Aha.

Podpory concurrency ma i C++11 a C11.

V roce 2016 bych si podporu paralelniho programovani predstavoval trochu jinak.

[little.owl]

Tak az prijdete s tim spravnym resenim, dejte vedet.

[deda.jabko]

No a v Ruste Concurrency, to sú hotové nástroje kde odpadá veľa vývojárskej práce pre paralelizmus.

Podpory concurrency ma i C++11 a C11. Take mi prijde, ze o C++ uz moc nevite.

A vymysleli uz neco lepsiho nez vlakna a zamykani?

Zatim futures.

Tak jeste jednou pomalu.

Rust se snazi k problemu paralelismu pristupovat alespon trochu koncepcne a nabizi vcelku zajimave reseni, ktere soucasne resi dalsi problemy. To, ze ma C/C++ podporu future, neni zadna velka vyhra. Tento koncept (pro zajimavost puvodem z MultiLispu nekdy z osmdesatych let) v podstate jen obaluje praci s vlakny a realne zadny problem neresi. Myslim, ze kazdy, kdo trochu kdy programoval paralelni aplikace, k podobne pomocne tride dospel sam i bez standardu.

Zakladnim problemem paralelniho programovani v C/C++ jsou zamky, ktere se proste na bezne paralelni programovani(tm) nehodi, protoze i pri beznem skladani procedur se zamky je jednoduche udelat nejaky race-condition nebo dead-lock. Soubezny pristup do pameti je pak kapitola sama pro sebe, i kdyz uznavam, ze posledni specifikace C/C++ doplnuji memory model tak, aby se dalo neceho chytnout.

Kdybych to mel shrnout, programovat paralelni aplikace v C/C++ je zhruba tak efektivni a pohodlne, jako je psat v assembleru. C/C++ narozdil od Rustu neprinasi zadnou podporu navic a je to porad ten samy a neprehledny assembler.

[little.owl]

Ted pomalu pro zmenu pro vas. Ja nikde nezpochybnoval vyhody Rustu v teto oblasti, zejmena ownership/lifetimes. Poukazal jsem pouze na to, ze C++11/C11 ma jiz take podporu concurrency ve standardni knihovne a obecne se jedna o podporu na urovni soucasneho standardu. Pro vetsinu aplikaci to staci a pracuje se na jejim rozsireni. Podstatna vestina veci, co delame ma koreny v minulem stoleti, vcetne celeho Linuxu a presto to funguje.

Programovat paralelni aplikace v C/C++ je zhruba tak efektivni a pohodlne, jako je psat v assembleru.

Kdybych nestravil roky prevazne programovanim embedded RTOS systemu v C/C++, zahrnujice heterogenni SoC s vice nezavislymi jadry, kde je nutne se i manualne starat o cache coherency u sdilenych dat, a kde vam vedle vlaken litaji i asynchronni HW interrupty, tak bych vam mozna i veril.

[deda.jabko]

Programovat paralelni aplikace v C/C++ je zhruba tak efektivni a pohodlne, jako je psat v assembleru.

Kdybych nestravil roky prevazne programovanim embedded RTOS systemu v C/C++, zahrnujice heterogenni SoC s vice nezavislymi jadry, kde je nutne se i manualne starat o cache coherency u sdilenych dat, a kde vam vedle vlaken litaji i asynchronni HW interrupty, tak bych vam mozna i veril.

Gratuluji, doporucuji k tomu jeste dostudovat pojem metafora.

V kontextu teto diskuze (tvorba prohlizece, uzivatelske aplikace) je nicmene prinos C/C++ k snadne tvorbe paralelnich aplikaci mizivy.

Podstatna vestina veci, co delame ma koreny v minulem stoleti, vcetne celeho Linuxu a presto to funguje.

Proto dnesni software vypada tak, jak vypada.

[little.owl]

Proto dnesni software vypada tak, jak vypada.

No tak to urcite . Kez by to bylo tak jednoduche.

[kralyk z abclinuxu]

Tak napr. U++ používa kontajnery, takže všetko niekam patrí a radím to medzi dobrý nápad ako spravovať pamäť.

Na to nepotřebuješ U++, to je všeobecný koncept v C++, který je i podporovaný standardem, vygoogluj si "RAII".

No a v Ruste Concurrency, to sú hotové nástroje kde odpadá veľa vývojárskej práce pre paralelizmus.

Souhlasim, že podpora pro vlákna je v Rustu velmi pěkná, odpadá tam spousta boilerplate kódu. Nicméně borrow-checker není všemocný spasitel, například před deadlocky tě neochrání o nic víc než C/C++.

[kralyk z abclinuxu]

Psat tak zasadni komponentu jako je renderovanci jadro prohlizece ve stale experimentalnim nestandardizovanem jazyce jako je Rust me tedy nanaplnuje nadsenim.

Podívej se do historie C/C++, jak dlouho trvalo tyhle jazyky standardizovat a dostat na dnešní stabilní úroveň. Na něco takového Mozilla nemůže čekat.

Btw. standardizovaný Rust není, ale experimentální taky už imho úplně ne.

[little.owl]

Btw. standardizovaný Rust není, ale experimentální taky už imho úplně ne.

To je vec nazoru. Srovnejte situaci Rust a Go. Oba jazyky pochazi ze stejne doby, ale v Go lze jiz nalezt netrivialni dospele produkcni projekty, garantuji kompatibilitu do budoucna a lze ostatne jiz nalezt i realne pracovni nabidky. Rust se tomu ani zdaleka neblizi.

[kralyk z abclinuxu]

Vzhledem k tomu, o kolik víc Rust nabízí oproti Go (které je tak trochu suchým záchodem), mi přijde, že si vede celkem dobře...

[little.owl]

Vzhledem k tomu, o kolik víc Rust nabízí oproti Go (které je tak trochu suchým záchodem)

Nekdy je mene vice a Go nove vlastnosti opatrne pridava.

mi přijde, že si vede celkem dobře...

To ukaze cas. Ja nerim, ze Rust je spatny jazyk bez zajimavych myslenek, ale IMHO neni zatim pripraven na produkcni nasazeni a urcite bych ho ted nepouzil na neco, co je nutne podporovat roky.

[kralyk z abclinuxu]

Nekdy je mene vice a Go nove vlastnosti opatrne pridava.

Vzbuď mě, až opatrně přidají generika

To ukaze cas. Ja nerim, ze Rust je spatny jazyk bez zajimavych myslenek, ale IMHO neni zatim pripraven na produkcni nasazeni a urcite bych ho ted nepouzil na neco, co je nutne podporovat roky.

Není mi moc jasné, proč u Go to schvaluješ, ale u Rustu ne.

[little.owl]

Vzbuď mě, až opatrně přidají generika

Na to jsem sam zvedav, pracuji na tom, ale zadny navrh jim neprisel zatim dost genericky .

Není mi moc jasné, proč u Go to schvaluješ, ale u Rustu ne.

Neni to stejna situace. Na stupnici prototyp - dospely produkt ucinil Go za stejnou dobu mnohem mnohem vetsi pokrok. To souvisi jednak s tim, ze tvurci Go limitovali rozsah jazyka zpocatku na skalovatelne serverove sluzby, ale predevsim s inzenyrskymi schopnostmi Googlu, ktery pokud chce, ma k dispozici zdroje, ktere Rust nema, hlavne velky team zkusenych lidi. To je videt ze spodu od kompilatoru, kde pracuji lide jako Ian Lance Taylor (tvurce gold linker, ktery pouziva jak gcc tak llvm), po sitovy stack. Google pouzival Go interne nekolik let na nekritickych projektech, nez to nasadil na kriticke sluzby a podobne veci delali i treti strany, zahrnujice projekty jako Docker, CockroachDB, InfluxDB, Kubernetes, Etcd/Fleet a dalsi. Rust je v situaci, kdy se zkousi nakolik je to skutecne pouzitelne, a tam byl Go tak pred ~ ctyrmi lety.

[kralyk z abclinuxu]

Rust je v situaci, kdy se zkousi nakolik je to skutecne pouzitelne, a tam byl Go tak pred ~ ctyrmi lety.

... což je +/- doba, kdy se začal psát Docker. Stále cyklíš.

[little.owl]

... což je +/- doba, kdy se začal psát Docker. Stále cyklíš.

Kde ze presne cyklim?

[kralyk z abclinuxu]

Kde ze presne cyklim?

10: V Rustu by se neměly psát produkční věci, protože není připraven.
20: Rust není připraven, protože v něm nejsou produkční věci.
GOTO 10.

Jestli bylo Go před několika lety ve stejné situaci, proč bylo tehdy v pořádku napsat v něm Docker?

[Petronel]

Ehm. Trolíš nebo ti to uniklo?

Rust i Go vznikly skoro současně.

Tam kde bylo Go před několika lety byl i Rust.

Takže kdyby začli psát nové renderovací jádro v té době, kdy se začal psát Docker, tak by se nedal říct ani popel.

Prostě startovali stejně, ale Go je už o čtyři kola vepředu. A z toho jde vidět kdo na to má a kdo ne.

[kralyk z abclinuxu]

Ok...

[little.owl]

To je vase selektivni dezinterpretace. Psat si muzete co chcete v cem chcete, nicmene casti napsane ve stale experimentalnim neodzkousenem jazyce neni vhodne davat do systemove dulezitych/produkcnich komponent a o to tady jde. To plati dnes, i pred lety, vcetne Dockeru ci cehokoliv jineho.
Zkousim nightly build Serva od cervence, a stale to neni ani alfa verze, jak z hlediska funkcnosti, tak stability. Dodnes nemaji vyresen Windows build, protoze toolchain neni jeste pripraven v pouzitelnem stavu (Go ma funkcni podporu pro Windows od 2011).

[sid]

To experimentalnom a neodskusanom jazyku mi pride ako citat bugtracker boost-u pre c++ chyby v prekladacoch vdaka pridavaniu novych veci. Ta "stabilita" jazyka priam sposobuje tuzbu poslat cely standart aj jeho implementacie do pekla. Obrazne samozrejme ale ked clovek robi kod co ma bezat od predhistorickeho gcc, cez posledne gcc a zaroven windows tak pomaly viacej skuma prekladac ako vlastny kod. Go ma presne tu vyhodu co rust jedna implementacia ktora sedi voci specifikacii. Samozrejme bugy su a budu ale je to poriadna vyhoda. Skromny odhad, ze za rok bude rust v stabilite a prenositelnosti dalej ako kedy c++ bolo.

[little.owl]

Go ma presne tu vyhodu co rust jedna implementacia ktora sedi voci specifikacii.

Neexistence standardu je nevyhoda, stejne jako nemoznost mit vice kompatibilnich implementaci.

Skromny odhad, ze za rok bude rust v stabilite a prenositelnosti dalej ako kedy c++ bolo.

Hodne optimisticke. Ja se ovavam, ze s C++ tady budem muset zit jeste desetileti.

[sid]

To ani nespochybnujem. Myslim to kolko tu c++ bude.

[kralyk z abclinuxu]

To je vase selektivni dezinterpretace.

Není, viz tvé komentáře:

Psat tak zasadni komponentu jako je renderovanci jadro prohlizece ve stale experimentalnim nestandardizovanem jazyce jako je Rust me tedy nanaplnuje nadsenim.

+

Nekdo dava vahu realnym projektum v producknim nasazeni (radary, roboty, ridici systemy vlaku, letadel, tanku, druzic ci elektraren), a nekdo statistikam programatorskych cancu na GitHubu. V podstate jsem jeste nevidel jediny realny projekt, ktery by prokazoval, co Rust slibuje

Sorry, ale z toho mi vychází, že není způsob, jak by ti mohl Rust v této chvíli mohl vyhovět. Úplně nevím, jak vymyslet projekt, který by byl velice seriózní, určen pro produkční nasazení typu letadlo/robot/družice/atd., ale aby zároveň vůbec nevadilo, když nečekaně zhavaruje.

Psat si muzete co chcete v cem chcete, nicmene casti napsane ve stale experimentalnim neodzkousenem jazyce neni vhodne davat do systemove dulezitych/produkcnich komponent a o to tady jde.

Jak říkám, je dobře, že se tvými radami neřídili tvůrci Dockeru...

[little.owl]

Davate dohromady prispevky vytrzene z kontextu, timto smerem opravdu jit nechci.

[kralyk z abclinuxu]

Oba jazyky pochazi ze stejne doby, ale v Go lze jiz nalezt netrivialni dospele produkcni projekty

Ve chvíli, kdy se tyhle projekty psaly, bylo Go v zásadě ve stejné situaci jako Rust... Ještěže v té době neměli ti lidi little.owla...

[vas]

Já myslím, že Rust má docela budoucnost. I lidi v GNOME jsou z něj docela nadšení. Je to jazyk, který byl vytvoření pro postupné přepsání velkých projektů v C. Tím, že to dodržuje stejné konvence volání jako C, se to dá jednoduše integrovat se zbytkem, který je stále v C a člověk nemusí přepsat všechno naráz. To je pro projekty jako GNOME nebo Firefox jako dělané.

[_]

patlalové v gnome jsou tedy měřítko :)

[Franta]

Říká anonymní nýmand...

[Pepa]

Říká anonymní nýmand...

[tacoberu]

Z uživatelského hlediska bezpochyby úspěch. Jenže to laguje. Takže něco co by jim pomohlo s pamětí se určitě hodit bude.

[Cabrón]

Mozilla neustále vyhlašuje, představuje a na druhé straně zase ruší a stornuje, ale že by taky někdy něco dotáhli do konce, to ne.

[JiK]

Tomu se rika vyvoj, R&D...to je jejich primarni funkce...

[Cabrón]

Dělají hodně toho R, ale poměrně málo D.

[sid]

Ono to nejako tak aj vyplyva z ich zamerania nie?

[JoHnY3]

Bla, bla, bla ... je moderni nadavat ma Mozillu ... bla, bla.

Je to paradox. Mozilla funguje jako inkubator napadu relevantnich pro web a internet. Chapal bych, kdyby jim lide zazlivali Firefox OS, ktery byl zjevne mimo jejich predchozi ramec pusobnosti a take podle toho dopadl, ale nadavat jim za inovovani FF mi prijde vazne dost divne. Projekty jako Rust, Servo a Daala bych naopak povazoval za krok spravnym smerem.