Vlákno názorů k článku
Ubuntu dokončilo plný přechod na coreutils napsané v jazyce Rust od Dushino - Pěkný flame, ale ti, co brojí proti Rustu...

Hele a všimnul sis, že ne každá změna nebo alternativa = vylepšení?

Ano, to je princip evoluce. Pokud je nějaká věc neživotaschopná, nepřežije a pokud je životaschopná, rozšíří se.

Přesně napsáno. Důležité je si všimnout, že "životaschopná" neznamená automaticky "lepší".

> Důležité je si všimnout, že "životaschopná" neznamená automaticky "lepší".

Příroda nemá jiný test, než že se daný produkt vyzkouší. Lepší a horší jsou dost subjektivní kategorie a musí se říct v čem. Přežití je test realitou. Byl Pascal lepší než Algol? Bylo C lepší než Pascal? Jak v čem, ale zjevně byly praktičtější v dané době, v dané situaci.

Vždy si vzpomenu na to, jak si lidé stěžovali, že Betamax byl lepší než VHS a v lecčems byl, ale existovaly dobré důvody, proč prohrál. A dnes to je jedno, překonané jsou obě tyto technologie.

Lepší a horší jsou dost subjektivní kategorie a musí se říct v čem.
Ano. A pro daného člověka v danou chvíli jsou to ty důležité kategorie. Přežití je test úplně jiné metriky - životaschopnosti k konkrétním prostředí. Nevypovídá vůbec nic o kategoriích lepší/horší, protože může záviset na okolnostech pro hodnotitele irelevantních nebo zcela náhodných.

> Ano. A pro daného člověka v danou chvíli jsou to ty důležité kategorie. Přežití je test úplně jiné metriky - životaschopnosti k konkrétním prostředí. Nevypovídá vůbec nic o kategoriích lepší/horší, protože může záviset na okolnostech pro hodnotitele irelevantních nebo zcela náhodných.

Já jsem slovo "lepší" použil ale přesně v tom významu "lepší pro vás, kteří nemáte rádi Rust". C je špatný jazyk, sám ho nechceš používat. Přepis do "moderního" idiomatického C++ naopak možný je a když ho někdo udělá, bude srovnání. Ale nestalo se, pokud vím. Jsem na to zvědav. Nahoďte cabin (nebo jiný ekvivalent carga) a moderní C++ a Rustu to natřete!

Byla to první, nebo jedna z prvních free reimplementací původních proprietárních unixových utilit.

Pak jsi možná málo hledal.
Máš kandidáty (něco jiného než Rust)?
C prostě není dobrý jazyk, to před sebou žádnou reálnou možnost nápravy už nemá.
Bez konkrétních metrik pro hodnocení je to bezobsažné tvrzení. V závislosti na výběru metrik může a nemusí být pravdivé.
Ale divit se, že ho někdo používat nechce a hledá alternativy?
Tomu se nedivím, já C taky nechci používat, když nemusím a existuje v dané situaci lepší alternativa. Což podle mých měřítek v případě coreutils neexistuje, protože nejlepší volba ne nepřepisovat je.

> Máš kandidáty (něco jiného než Rust)?

Já je mám hledat? Jazyků existuje spousta. Chápu, že nemají často takový ekosystém, aby se daly využít v praxi (tam je rozdíl mezi Rustem či třeba Go a "zbytkem" - že bylo dost sil na to, aby to někdo dotáhnul do stavu masové použitelnosti). Ale zajímá mě, jestli by sis vybral něco, co by mělo třeba lepší syntaxi atd.

> Bez konkrétních metrik pro hodnocení je to bezobsažné tvrzení.
> Tomu se nedivím, já C taky nechci používat, když nemusím

Tohle je konkrétní metrika. Že ani lidé, kteří jsou z tábora "konzerv", často daný jazyk dobrovolně používat nechtějí. C nemá vyšší abstrakce, je plné podivností typu for (;;) a switch a neviděl jsem zatím žádný náznak, že by se to mělo změnit (už si naštěstí nikdo nemyslí, že je normální, aby pointerová aritmetika byla rychlejší než přístup přes index, ale to je konkrétní příklad mentálního stavu, který za C historicky byl).

Že vznikají jazyky typu C3 (který toho mění poměrně málo), jen ukazuje, že i konzervám došla trpělivost a C nemá důvěru, že se z něj stane něco výrazně lepšího.

Já je mám hledat? Jazyků existuje spousta.
Já jsem hledal a nenašel. Ty tvdíš, že jazyků existuje spousta a že jsem možná málo hledal. To ve mně vzbuzuje naději, že víš o nějakém jazyku, který mi při hledání unikl.
podivností typu for (;;)
To je drobnost, kterých se najde spousta asi v každém jazyce.
už si naštěstí nikdo nemyslí, že je normální, aby pointerová aritmetika byla rychlejší než přístup přes index
Proč by to nemělo být normální? Aby bylo indexování stejně rychlé, je potřeba dostatečně chytrý procesor nebo optimalizující kompilátor. Navíc algoritmy zapsané pomocí pointerové aritmetiky se často lépe zobecňují v generickém kódu než indexování. Proto taky existují iterátory.
konzervám došla trpělivost a C nemá důvěru
Z toho, že si jen někdo chce zkusit navrhnout vlastní jazyk, bych nedělal závěry o tom, že C je beznadějně ztracené.

> Aby bylo indexování stejně rychlé, je potřeba dostatečně chytrý procesor nebo optimalizující kompilátor.

Ano a o tomhle se bavíme. Že C je myšlenkový produkt zcela jiné doby. Rust a C++ dělají spoustu optimalizací, které se v C realizovat moc nedají (zero-overhead abstractions, kde indexování pole je asi nejprimitivnější příklad).

> Z toho, že si jen někdo chce zkusit navrhnout vlastní jazyk, bych nedělal závěry o tom, že C je beznadějně ztracené.

To je jen jeden střípek z mozaiky. Nejpozději v době objevení se C++ a Objective-C bylo jasné, že C je pro větší projekty nepříliš vhodné. A "zběsilé" tempo vylepšování s každým dalším standardem to jenom potvrzuje.

Zbytek nekomentuju, nemá to valného smyslu.

To byl z mé strany sarkasmus...

Jen pár bodů, co se mi na Rustu nelíbí: Borrow checker, který odmítá korektní kód, protože jeho správnost ve svém axiomatickém systému neumí dokázat. Sémantika safe/unsafe. S tím související množství knihovního kódu, který existuje jen proto, aby se to celé dalo aspoň trochu používat a daly se dělat věci, které jsou v jiných jazycích triviální. Explicitní rozlišování hodnot a referencí v argumentech funkcí. Podivnosti typu phantom data. Celý systém maker. Nedostatečné vyjadřovací schopnosti nástrojů pro generické programování. Implementace dynamic dispatch. Nic moc nástroje pro psaní dokumentace (rustdoc). Propojení jazyka, build systému a package manageru (cargo).

No tak Rust se vydal cestou předvídatelného kódu, což má nějaké náklady, ale spoustu věcí to řeší, třeba při paralelizaci atd. Nelze mu vyčítat, že konkrétní rozhodnutí má konkrétní náklady, protože nic neřešit je vždy pohodlné a "bezpečné".

> Propojení jazyka, build systému a package manageru (cargo).

To není propojení, to je konkrétní řešení. Pořád můžeš používat rustc s nějakým jiným systémem, ale prakticky nikdo to (pochopitelně) nechce.

> Nic moc nástroje pro psaní dokumentace (rustdoc)

Jako fakt? Ve srovnání s čím? Nikde jsem neviděl tak skvěle zdokumentovaný kód všech knihoven (i s prokliky do zdrojáku) jako u Rustu.

> Explicitní rozlišování hodnot a referencí v argumentech funkcí.

V C++ se nerozlišuje mezi hodnotou a referencí?

> Celý systém maker

Ve srovnání s čím?

18. 9. 2026, 11:49 editováno autorem komentáře

protože nic neřešit je vždy pohodlné a "bezpečné"
Neříkám neřešit nic, ale řešit jinak (např. statická analýza, testy + runtime sanitizers).
> Nic moc nástroje pro psaní dokumentace (rustdoc)
Jako fakt? Ve srovnání s čím?
Doxygen
> Explicitní rozlišování hodnot a referencí v argumentech funkcí.
V C++ se nerozlišuje mezi hodnotou a referencí?
Rozlišuje. Ale při volání funkce nemusím explicitně rozlišovat, jestli do funkce posílám hodnotu nebo referenci. A to jsem ještě zapomněl nutnost v definici funkce vypisovat typy všech parametrů a návratové hodnoty.
> Celý systém maker
Ve srovnání s čím?
C++ templates, constexpr, consteval

Statickou analýzu Rust dělá. Při kompilaci.

Ale vy spíš myslíte dobrovolnou statickou analýzu nad výsledkem. S tím došla průmyslu trpělivost, spousta projektů ji nedělala a paměťové chyby jsou dnes už nepřijatelné bezpečnostní, reputační a finanční riziko.

Potom Vám vadí už samotný záměr jazyka označit pointery za unsafe a nedovolit kód, který se nedá prokázat. Jo, to komplikuje věci.

Ale pokud to chcete, můžete právě použít unsafe. Které slouží k označení kódu, kde za správnost ručí programátor. (A jen pro jistotu: Ano vím, že je to složitější, protože aliasing pravidla)

Překvapivě (nebo spíš ani ne) unsafe bloky lidem vadí a snaží se je minimalizovat ve prospěch těch "formálně správných" safe algoritmů.

Jiným směrem se vydal třeba Zig. Zachoval pointery, ale omezil dopad chyb pomocí arena alokátorů. Což řeší ergonomii vývojáře, ale některé problémy to chytit neumí a nemůže.

Runtime kontroly jsou i v Rustu, ale z mého pohledu jsou akorát k zlosti. Program by prostě neměl u zákazníka padat, ideální je, když tam ta chyba přístupu nebo souběhu vůbec být nemůže (resp alespoň je omezena četnost na minimum).

A valgrind je něco, co sice pomůže, ale je to časově náročné, vyžaduje to fakt důkladné testy (které se v Rustu píšou taky výrazně snáz a jednotněji než v C++) atd.

Mimochodem, nevím jak jste přišel na to, že musíte v Rustu při volání rozlišovat jestli posíláte hodnotu nebo referenci. To totiž není pravda. Jediný takový běžný případ je explicitní označení reference jako mutable, což je záměr, aby si toho programátor všiml.

Mimochodem, nevím jak jste přišel na to, že musíte v Rustu při volání rozlišovat jestli posíláte hodnotu nebo referenci.

fn main() {
    let i: i32 = 123;
    f(i)
}

fn f(a: &i32) {
    println!("a={}", a);
}

Když tohle zkusím na play.rust-lang.org, tak chce, abych místo f(i) napsal f(&i).

A tohle snad v C nebo C++ projde? Ano, posílání skaláru do parametru, který očekává pointer/referenci samozřejmě vyžaduje pointer/referenci.

https://www.programiz.com/online-compiler/7dIOV8cx0h8W0

/tmp/IKQvEsbShs/main.cpp: In function 'int main()':
/tmp/IKQvEsbShs/main.cpp:13:10: error: invalid conversion from 'int' to 'int*' [-fpermissive]
   13 |     test(v);
      |          ^
      |          |
      |          int
/tmp/IKQvEsbShs/main.cpp:4:16: note:   initializing argument 1 of 'void test(int*)'
    4 | void test(int *val) {
      |           ~~~~~^~~

U reference to v C++ projde. Ale to už je pak design rozhodnutí jazyka, který chce, aby uživatel některé věci "odsouhlasil".

V C++ bych napsal void test(int& val) a volal to test(v).

Ano, to jsem zkoušel a projde to. I když tohle je zrovna ta mutable varianta. Ekvivalentní tomu Rustu by asi bylo

const int& val

.

A tady je pak hlavní rozdíl v tom, jestli to bude teoreticky dělat kopii nebo ne, ale oba jazyky to stejně pravděpodobně vyoptimalizují pryč. V -O0 to oproti skaláru malý rozdíl bude.

> Neříkám neřešit nic, ale řešit jinak (např. statická analýza, testy + runtime sanitizers).

Tohle všechno bylo před Rustem. Zjevně byl důvod zvolit něco jiného (runtime kontrola jako alternativa compile-time kontroly, jako fakt?)

> Doxygen

Tohle mi přijde jako typické "já jsem zvyklý na tohle". Rustdoc se většinou bere jako výhoda a ne naopak, ale jistě se dá mnoho zlepšovat.

> Ale při volání funkce nemusím explicitně rozlišovat, jestli do funkce posílám hodnotu nebo referenci.

Tohle má nějaké výhody. Byť třeba i minimální.

> A to jsem ještě zapomněl nutnost v definici funkce vypisovat typy všech parametrů a návratové hodnoty.

Tohle je IMO úplně správně.

> C++ templates, constexpr, consteval

Opět - výhody a nevýhody. Za mě jsou makra v lecčems lepší koncept, navíc se tady asi plete role traits + bounds, const fn a maker.

Tohle všechno bylo před Rustem.
Ale mezitím se to taky zlepšilo.
runtime kontrola jako alternativa compile-time kontroly, jako fakt?
Runtime kontrola tam, kde to v compile-time nejde. I Rust je runtime kontrol plný.
Tohle mi přijde jako typické "já jsem zvyklý na tohle".
Když ta nová alternativa nemá půlku featur...
Tohle má nějaké výhody. Byť třeba i minimální.
A taky nevýhody.
Tohle je IMO úplně správně.
Tak rozumný jazyk si typy často dokáže odvodit. C++ to zvládá docela dobře, Haskell je v tom fakt dobrý.
Za mě jsou makra v lecčems lepší koncept
Když jsem si s makry v Rustu hrál, tak jsem měl asi poprvé v životě pocit, že templaty v C++ jsou na používání fakt příjemné :-)

Jen pár bodů, co se mi na Rustu nelíbí
Když to shrnu, vadí vám, že jazyk kontroluje některé věci, ve kterých se často dělají chyby.

To ale není chyba Rustu. To je záměr všech jazyků nad assemblerem. Že vám takové jazyky nevyhovují, to je možné. Ale není to jejich chyba. A neznamená to, že když ty jazyky používá někdo jiný, že je to špatně.

Když to shrnu, vadí vám, že jazyk kontroluje některé věci, ve kterých se často dělají chyby.
To jste shrnul jen asi první dva body a ještě mi podsouváte, co jsem nenapsal. Mně nevadí, že jazyk něco kontroluje. Mně vadí, že pro řešení jednoho principiálně neřešitelného úkolu mi nutí jednu aproximaci a nenechá mě vybrat.

Buďte rád, že nepoužíváte Eiffel nebo ADA. Design by contract. Kontroly (některých) vstupních a výstupních podmínek kompilátorem, atd.

https://en.wikibooks.org/wiki/Ada_Programming/Contract_Based_Programming

Rust Vás nechá vybrat. Od toho je právě to kouzelné slovo unsafe. Které by ovšem mělo spíš vypadat "za_tohle_ručím_já", jen by se to blbě psalo. A pak máte clippy a miri, které umí dělat externí analýzu a kontrolu.

Buďte rád, že nepoužíváte Eiffel nebo ADA. Design by contract.
C++: assert, static_assert, C++26 contracts: pre, pos, contract_assert. GCC 16 už to umí.
kouzelné slovo unsafe
Které znamená něco jako: "Kvůli tomuto jednomu unsafe řádku zkontroluj minimálně celý modul, případně všechny nadřazené moduly, pokud do nich potenciální problém může probublat."
clippy a miri
Já bych čekal, že v Rustu takové nástroje nebudou potřeba, nebo se budou volat povinně automaticky z kompilátoru nebo cargo.

To jste shrnul jen asi první dva body a ještě mi podsouváte, co jsem nenapsal.
Spíš první čtyři.

Mně vadí, že pro řešení jednoho principiálně neřešitelného úkolu mi nutí jednu aproximaci a nenechá mě vybrat.
Jenže on ten principiálně neřešitelný úkol má mnoho pro praxi dostatečných řešení. Jiné jazyky problém paměťové bezpečnosti řeší automatickou správou paměti, třeba s GC. Je to omezení? Je. Je v pořádku, že ty jazyky existují, že se používají, a předešlo to spoustě problémů? Ano. Nutí vás někdo ty jazyky používat? Nenutí. Tak v čem je problém? Vy si budete řešit pár svých úloh, kde vám automatická správa paměti nebo borrow checker překáží. A všichni ostatní budou programovat v jazycích, které paměťovou bezpečnost nějak ošetřují, protože to předejde významnému množství chyb a urychluje to vývoj.

Navíc Rust vás nechá si vybrat. Na rozdíl od Pythonu, JavaScriptu nebo Javy.

Jiné jazyky problém paměťové bezpečnosti řeší automatickou správou paměti, třeba s GC.
Jenže tyhle jazyky se netváří, že jsou lepší náhrada za C a C++.

Ale tváří. Java vznikla, aby nahradila C a C++. Go určitě také mělo částečně nahradit C a C++, částečně možná Python a některé další jazyky. I Python měl v menší části nahradit C, možná i C++.

Přičemž „nahradit“ v tomto případě neznamená, že by bylo cílem, aby C a C++ úplně zaniklo. Ale příslušný jazyk měl za cíl převzít některé typy aplikací dříve psané v C a C++.

A úplně stejně je na tom Rust. Cílem Rustu není vymýtit C a C++ z povrchu zemského. Cílem je některé typy aplikací psát v Rustu místo C nebo C++.

Myslel jsem nahradit ve smyslu úplně nahradit. Tedy aby se cokoliv, co by se dřív psalo v C nebo v C++, nyní psalo lépe v novém jazyce.