Názory k článku
Rust Coreutils 0.10 vylepšují bezpečnost a kompatibilitu s GNU

Hlavně compile-time kontrola se děje v mé pracovní době u mně na stole. Runtime ne. Takže pro ty runtime kontroly je stejně nezbytné to důkladně pokrýt unittesty. Protože v runtime se to už dá jen eskalovat na crash, což je jen jiný druh průseru. Není to prevence bugu, jen změna jeho projevu.

> Rust ukázal cestu, jak 99% problémů lze vyřešit už v compile-time. Zig uvažuje o zlepšení debug buildů, ne o takto drahému řešení pro produkční buildy - to by zabilo ten jazyk OMG.

To není pravda, protože celá standardní knihovna je plná unsafe kódu, takže když použijete cokoliv ze standardní knihovny, tak používáte unsafe kód, který může být plný chyb.

Jinak řečeno 99,9 % programů závisí na unsafe kódu. Takže zdaleka nemáte paměťovou bezpečnost.

Pro úplnost: existují snahy verifikovat standardní knihovnu, ale zatím je FIl-C dál.

> Jinak řečeno 99,9 % programů závisí na unsafe kódu.

To je nepřesné. Reálně 100 % programů (vč. Hello world) v jakékoli implementaci jakéhokoli jazyka závisí na nějakém unsafe kódu. Jen je otázka, jak hluboko je to ukryto, jak dobře je to odděleno a kolik toho je

To, že nějaký kód může být plný chyb, neznamená, že plný chyb je. Zkontrolovat na paměťovou bezpečnost standardní knihovnu je mnohem jednodušší, než kontrolovat stále veškerý kód, který standardní knihovnu používá.

Chyby mohou být samozřejmě i v Rustu, takže i paměťově bezpečný kód v Rustu může mít ve skutečnosti chybu. Jenže ono to ve skutečnosti není „program je/není paměťově bezpečný“. Ve skutečnosti jde o to minimalizovat množství chyb při práci s pamětí. A tam prostě Rust oproti C/C++ dost pomáhá, a za poměrně nízkých nákladů.

> Zkontrolovat na paměťovou bezpečnost standardní knihovnu je mnohem jednodušší, než kontrolovat stále veškerý kód, který standardní knihovnu používá.

Je to jednodušší, ale pořád těžké. Tak těžké, že i zkušení vývojáři standardní knihovny dělají chyby v jednoduchých funkcích a na review se na to nepřijde. Při troše štěstí to najde Miri, který je ale ještě pomalejší než Fil-C.

Druhá věc je, že Rust nemá pořád specifikována pravidla pro aliasing. Takže ani nejde přesně říci, kde je to ještě dobře a kde špatně (jsou situace, kde i třeba lidé kolem Miri řeknou probably bug, ale jistí si nejsou).

> Při troše štěstí to najde Miri, který je ale ještě pomalejší než Fil-C.

Jako, obvykle jsou tvoje argumenty docela absurdní, ale tady ses překonal :) Fakt porovnáváš pomalou runtime kontrolu s pomalým miri checkem CI?

Jsou snad v Rustu jiné možnosti, jak ověřit memory safety v unsafe kódu?

Mluvím o tom že srovnáváš hrušky s jabkama. „Miri je ještě pomalejší než Fil-C“ je úplně uhozené tvrzení. Jedno je jednorázový test, to druhé pomalá runtime. Pomalost Miri řeším jen při čekání na výsledek CI pipeline při vývoji, pomalost Fil-C pocítí každý uživatel.

> Pomalost Miri řeším jen při čekání na výsledek CI pipeline při vývoji, pomalost Fil-C pocítí každý uživatel.

To ano. Ale znamená to pak také, že programy v Rustu, které dám uživatelům, nejsou chráněny proti nedefinovanému chování v unsafe kódu. Můžu jen doufat, že jsem ta chování odhalil testem, který běžel na CI pod Miri.

Ale znamená to pak také, že programy v Rustu, které dám uživatelům, nejsou chráněny proti nedefinovanému chování v unsafe kódu.
Úplně stejně, jako všechny ostatní programy, které reálně uživatelé používají. Takže tohle není žádná nevýhoda Rustu.

S Fil-C ano. A v Zigu, když přeložíte s ReleaseSafe, tak jste na tom lépe než obyčejný unsafe Rust nebo C.

S Fil-C ano. A v Zigu, když přeložíte s ReleaseSafe, tak jste na tom lépe než obyčejný unsafe Rust nebo C.
Kolik je těch programů s Fil-C nebo v Zigu přeložených s ReleaseSafe, které reálně uživatelé používají?

Současné rozšíření není moc argument, když se diskutuje možná budoucí změna, vylepšení. Stejně tak se dá říct, že uživatelé beztak používají většinu softwaru psaného v C, C++, Javě, tak proč řešit nějaký Rust, Go, D atd.

Vzhledem k tomu, že se často používají pomalé skriptovací / interpretované jazyky, tak bych ty běhové kontroly zakompilované do programu úplně nezavrhoval. Rychlost není vše a pro spoustu uživatelů to vůbec není hlavní kritérium resp. může to být zpomalení, které je pod jejich rozlišovací schopnost, takže pak převládnou ty přínosy.

Jinak já třeba považuji za zvěrstvo, že se v C pořád píší věci jako systemd. Tam by se ten vyšší programovací jazyk hodil mnohem víc, než cpát Rust do Jádra. Ale když už ten software v C je, tak dodatečné kontroly něčím, jako je Fil-C, můžou být dost užitečné. A zrovna ten systemd jen orchestruje služby, tam ta rychlost fakt není kritická a klidně by to mohlo být psané v Shellu, Lispu, Lue, PHP... ale když tam bude bezpečnostní chyba, tak to postihne prakticky všechny. Podobná situace je v tom Jádře - jen pro část toho kódu je kritická rychlost - ten zbytek by klidně mohl být v nějakém nízkoúrovňovém skriptovacím jazyce, protože se spustí jen jednou, nakonfiguruje dané zařízení a skončí.

> Přece každý kdo má rozum to musí pochopit. Žádná firma nebude platit 6x tolik serverů jen proto, aby mohli nasadit produkční kód s Fil-C. Vždyť pro některé i 5% zlepšení výkonu je něco, co se dá spočítat na konečné ceně serverů.

Vzhledem k tomu, kolik firem používá interpretované jazyky, které jsou i 30x pomalejší, tak bych řekl, že se to tolik neřeší.

Ale řeší. Třeba v kontextu googlu nebo facebooku zrychlení o 1% zaplatilo daného vývojáře jen skrz úspory energie. Byla to přednáška hodně let zpátky, takže už nevím co to bylo za megafirmu.

To použití pomalých jazyků stojí na tom, že pro kritické části můžou zavolat rychlé knihovny. Obvykle to vyžaduje volat nějaké C api, dost často nějaké 3rd party knihovny. Bez unsafe kódu to jde dost blbě.

Pokud je nezajímá výkon, nebudou řešit Fil-C, ale napíšou to v Javascriptu nebo Pythonu. Pokud budou řešit výkon, ale ne tolik, napíšou to v Go nebo C#.

Ve velkých firmách jako Google, Amazon nebo Microsoft se i 5 % výkonu na serveru promění v obří úspory. Smysl má řešit i 1 %

Kam do toho zapadá Fil-C?

IIUC Fil-C má určitou výhodu u již existujícího kódu, tam je to jednodušší než ho přepisovat do JS/Pythonu. Ale zase Fil-C je one man show. Navíc možná bude dost často důvod, proč ten kód byl původně psán v C.

A to může být i ten důvod, proč se do toho nikomu nechtělo výrazněji investovat – použití bude dost omezené.

Vlastně bychom to mohli rozčlenit do čtyř skupin:

Nový kód, záleží na výkonu => Rust, dostaneme I pohodlnější jazyk. Informace pro borrow checker je IMHO stejně věc, kterou netriviální Cčkový kód musel nějak udržovat v komentářích.

Nový kód, nezáleží na výkonu => JS, Python a další.

Starý kód, záleží na výkonu => Fil-C bude pomalé => jiné řešení (statické analýzy, přepis do Rustu, …). Možná sandboxing aplikace jako celku, byť to brání škodám jen částečně.

Starý kód, nezáleží na výkonu => většinou nebyl napsán v C. Ale ano, tady by se Fil-C mohlo hodit. Ještě víc by se hodilo, kdyby to nebyla one-man-show, ale s ohledem na omezené využití do toho nejspíš nebudou velké investice.

> Starý kód, nezáleží na výkonu => většinou nebyl napsán v C. Ale ano, tady by se Fil-C mohlo hodit.

To je taky otázka. Studie ukazují, že starý C kód (Pokud je udržovaný) už tolik na podobné chyby netrpí, po nějaké době se to nejhorší vychytá. A nová funkcionalita už může být klidně Rust - takhle to tuším dělá s úspěchem Google. My v práci zase takhle kvůli výkonu "Rustizujeme" .net kód.

Asi záleží, ale on ten starý kód může být stále vyvíjený legacy kód.

ad „Nový kód, nezáleží na výkonu => JS, Python a další.“

Tady nějak implicitně předpokládáš, že tyhle jazyky jsou pro vývojáře lepší. Pro někoho na psaní asi ano, ale pokud máš číst kód po někom jiném, tak dynamicky typované jazyky jsou obecně horší. Kolikrát zjistíš, co to dělá, až v debuggeru, když to spustíš, ne čtením zdrojáku. Osobně budu radši číst slušně napsané C++ nebo i C než průměrný Python nebo JavaScript. Ideál na čtení je asi Java, protože tam nejsou nízkoúrovňové záludnosti C/C++ a zároveň je to staticky typované.

(samozřejmě obfuskovat se dá kód v libovolném jazyce, i v té Javě, když to někdo přežene s AOP a automagickými frameworky, ale za jinak stejných okolností se líp čte staticky typovaný kód, protože tam ta informace je už ve zdrojáku)

7. 8. 2026, 11:12 editováno autorem komentáře

Když už bych si měl vybrat skript, tak typescript

Klidně Java / Scala / Kotlin / Typescript/ Python + Mypy / Elm / Haskell / Prolog . Pointa se nemění. Ty dva jazyky jsem vzal z příspěvku, na který jsem reagoval.

Ano, taky mám rád statické typy.

> Zig uvažuje o zlepšení debug buildů, ne o takto drahému řešení pro produkční buildy - to by zabilo ten jazyk OMG.

To není pravda, hned na začátku je věta "mainly it is expected to combine this ABI with Optimize.safe or Optimize.debug". Takže i v produkci, protože safe se používá i v produkci.

Děláte jakoby se Fil-C už nedal nikdy zrychlit.

Fil-C se nedá nikdy zrychlit - tak jako ASAN/MSAN/UBSAN se nedá nikdy zrychlit. Můžeš na tom strávit roky a posuneš to o 10% třeba, ale neuděláš to 6x rychlejší. Navíc 2x-3x extra paměťové nároky v době, kdy je cena pamětí na maximu... Prostě toto nikdo nezaplatí...

Unsafe není problém - unsafe je jediná možnost jak udělat třeba syscall nebo podporovat C ABI. Rozdíl je unsafe everywhere vs isolated unsafe.

7. 8. 2026, 09:26 editováno autorem komentáře

Zrychlit by to určitě šlo. Třeba přidat analýzu, která dovolí ty kontroly za běhu odstranit. Takové analýze by se mohla hodit i informace o životnosti datových struktur. Oh wait…

No a jsme u toho... co je perspektivnější? Udělat C++ bezpečnější pomocí lifetime anotací a nebo se pokoušet o trochu zrychlit sanitizér?

Za mě to první - compile-time je oblast, která potřebuje zlepšovat, a ne sanitizéry - tam jde o kvalitu, pokrytí, atd... špatný výkon není problém.

> No a jsme u toho... co je perspektivnější? Udělat C++ bezpečnější pomocí lifetime anotací a nebo se pokoušet o trochu zrychlit sanitizér?

Podle mě nemá cenu vydávat se stejnou cestou jako Rust - co by to mělo za přínos? Když někdo chce tohle, tak proč by nepoužít Rust rovnou? Smysl by to mělo, kdybyste ten C++ kód nemusel měnit, což asi obecně nepůjde, protože inference lifetimů nepůjde bez anotací s rozumnou časovou složitostí.

> Podle mě nemá cenu vydávat se stejnou cestou jako Rust - co by to mělo za přínos? Když někdo chce tohle, tak proč by nepoužít Rust rovnou?

Co třeba inkrementální nasazení? Ty anotace se dají přidávat soubor po souboru. Přepis do Rustu je hrubší - spíš po jednotlivých modulech.

BTW ono se to už zrychlilo za poslední rok.

Jinak pro upřesnění, ta rychlost závisí na tom, jak program pracuje s pamětí. U některých programů je zpomalení jen 1,1 krát a u jiných i 9 krát.

C ABI si můžete nadefinovat - různé platformy mají různé.

ABI je ABI - tam si nic vlastního definovat nemůžu.

Nedeterministické zpomalení ale není žádný argument pro. Program většinou potřebuje přistupovat k paměti - máme minimálně 2x read a 1x write za cyklus, a Fil-C toto naprosto degraduje k nepoužitelnosti.

> ABI je ABI - tam si nic vlastního definovat nemůžu.

ABI je sada pravidel, takže můžete. A tak to dělá Fil-C.

memory-safe Řeší to jednu třídu problémů. Chytne to "use after free", ale chytne to třeba v kontextu c++ "use after destroy/move"?

Chytne to, pokud byl objekt uvolněn. Pokud ne, tak to nechytne, protože to není memory safety problém.

C API voláte. Problém je s ABI. Má to vlastní nekompatibilní ABI. Ale díky tomu, že s tím ABI můžete přeložit všechny programy a knihovny, tak to není takový problém.

Navíc ta bezpečnost nezmizí jako u Rustu, když používáte dynamicky linkované knihovny. To bohužel Rust také neumí bezpečně.

> Ale díky tomu, že s tím ABI můžete přeložit všechny programy a knihovny, tak to není takový problém.

Tohle právě je problém. Máte nějakou třetí partu jen jako binárky? Smůla. Nebo zdrojáky máte, ale je to třeba Fortran. Někdy tu unsafe vrstvu můžete poslat jako PR do Fil-C, někdy ne.

Ta unsafe vrstva tam prostě bude. Fil-C ji akorát vyhodil do nehlídaného C. Tvářit se, že tam ten unsafe kód není, není rozhodně cesta k tomu aby v něm bylo minimum bugů. Mrknětě na Vulkan PR na Fil-C githubu. To je mrtě unsafe kódu.

Představte si to jako portování programů na jiný OS, kterým má ale shodou okolností stejná systémová volání jako Linux.

Jediné, co tam bude unsafe bude kernel a runtime Fil-C. Pro Fortran to samozřejmě znamená upravit kompilátor, nicméně pokud pro jazyk existuje LLVM backend, tak by to nemuselo být těžké. Stejně tak pro všechen uzavřený kód to znamená, že se musí přeložit pomocí Fil-C, uzavřený pak může zůstat a bude to bezpečné včetně používání dynamicky linkovaných knihoven.

Teoreticky i Rust by šel přeloži pomocí Fil-C, čímž by se stal bezpečný.

Ona je také otázka, čemu říkáte bezpečný. Rust garantuje, že v safe kódu nebude chyba v přístupu k paměti. Fil-C garantuje akorát to, že za běhu nedovolí chybu v přístupu k paměti provést – opravit ji ale nemůže, takže jediné, co zbývá, je zabít celý program. Za mne je to obrovský rozdíl. A snad ještě víc než ta náročnost za běhu to ukazuje, že Fil-C není v drtivé většině případů řešení. Fil-C je obezlička pro případ, kdy by chybné použití paměti znamenalo obrovský průšvih, a z nějakého důvodu nejde použít jiný jazyk. I pro aplikaci přeloženou s Fil-C ale platí, že v ní chyby v přístupu k paměti mohou být a pokud jsou, je daná část programu nepoužitelná.

Rozdíl to je, pokud se v Rustu dokážete omezit na safe kód. Pokud máte hodně unsafe kódu (např. protože používáte dynamicky linkované knihovny, píšete vlastní datové struktury), tak je naopak lepší použít Fil-C nebo alespoň Zig.

Pokud například potřebujete forknout datové struktury ze standardní knihovny (např. proto, že místo Ord chcete používat vlastní porovnávací closure, která má nějaký stav), tak máte safety dost možná horší než jiné systémové jazyky, protože alising v Rustu je těžký a nástroje na chytání chyb v unsafe kódu horší.

To ale neřešíte paměťovou bezpečnost vlastního kódu, ale kódu knihoven. Ta (když jde o C knihovnu) závisí na tom, zda tu knihovnu přeložíte s Fil-C – což je nezávislé na tom, odkud ji voláte.

> tak by to nemuselo být těžké

Těžké možná ne, ale rozhodně extrémně pracné. V porovnání s normálním asanem je to hodně peněz za málo dodatečné muziky.

> čímž by se stal bezpečný.

Jen pro velmi specifickou interpretaci slova "bezpečný". Fil-C se soustředí na paměťovou bezpečnost, ostatní třídy chyb nechává osudu. Paměťová bezpečnost stačí vyřešit jen částečně a normální význam bezpečnosti začne drhnout na úplně jiných problémech.

To pořád neodpovídá na otázku, jak by se to v praxi provedlo a komu by to něco přineslo.

Však to také nesvoboda je. Akorát se drtivá většina lidí shodne na tom, že svoboda nebýt zabit je nesrovnatelně důležitější, než svoboda zabíjet. Na tom, že GPL je svobodnější než třeba BSD, MIT nebo Apache, ale taková shoda rozhodně není.

Když děláš nesvobodný software, tak ti nehrozí, že by někdo tvoje zdrojáky vzal a uzavřel, protože už uzavřené jsou a máš je jen ty. Tzn. nehrozí, že by někdo „zabil“ tebe a naopak se ti hodí, když můžeš „zabíjet“ druhé.

Volba licence je věc každého autora a pokud vydává pod permisivní licencí, tak si nemůžu stěžovat. Stejně tak pokud to vydá pod proprietární nebo nějakou obskurní nebo to nevydá vůbec, tak si taky nemůžu nárokovat, aby to vydal pod licencí, která se líbí mně. Jen mi přijde, že hodně autorů podlehlo tlakům vydávat pod permisivní licencí, i když jsou za tím hlavně zájmy těch, kdo chtějí jen brát a využít zadarmo cizí práci ve svém proprietárním softwaru.

Jenomže názory na to, které opensource licence jsou svobodnější a které méně svobodné, se liší.