Vlákno názorů k článku
Pokračuje portace GNU Coreutils do Rustu, cp a mv ukazují postup od Calculon - Přepisovat kde co do Rustu je nějaká nová...

Přepisovat kde co do Rustu je nějaká nová móda?

Proč to pak nepsat přímo v Adě nebo Sparku?

Asi proto, že nikoho nezajímají.

Protože Ada i Spark jsou mnohem slabší, než Rust, pokud jde o statickou prokazatelnost.

Tohle je gigantický blábol, Spark ve "statické prokazatelnosti" (formální verifikaci) máloco překoná. Rust se mu v tomto vůbec nemůže rovnat.

Pretoze naklady, pociatocna investicia v pripade ada je vysoka, to ze celkova cena za vyvoj je nizsia, je v pripade takychto projektov irelevantne.

...a ked potom zistia, ze binarka namiesto 40kB ma 8MB a len jedny CVE presunuli na ine.

A pak ses probudil.

Takze sa zmozeme len na osobne utoky?

Co osobního tam vidíš? Tvoje poznámka byla mimo, tak jsem ji posunul do říše snů a fantazie.

Zkompiloval jsem si obě verze a takovéhle vidím velikosti binárek:

coreutils 0.0.17 (rust) 14,9 MB
coreutils 9.1 13,5 MB

V čem tedy vidíš problém nebo jak to porovnáváš? Původní coreutils používají hodně linkovaných knihoven, naopak rustové mají trochu jinou strukturu a nelinkují si mezi sebou, buď se pak distribuují po jednotlivých binárkách, které obsahují duplicitní kód nebo naopak v jedné binárce, které se symlinkuje.

Můžeš nějak podložit tvoji tezi ohledně přesunutí CVE?

Je naivni si myslet, ze zmenou programovaciho jazyka zaniknou vsechny zranitelnosti.

To ne. Ale legacy C je past, která znemožňuje zlepšovat kvalitu kódu. Napsat to v jazyce s podporou vyšších abstrakcí dává šanci posouvat to dál a ty chyby systémově řešit. Ne tím, že do toho někdo zašťourá a na jednom místě (snad) najde a opraví konkrétní problém.

To samozřejmě ne, ale jak to odpovídá na původní názor, že se jen jedny CVE přesunuli na jiné?

Současný coreutils má totiž velice málo CVE (a chyb obecně). Sám autor říká, že není jeho cílem snížit počet chyb (či je eliminovat změnou jazyka). Proto jsem se ptal, o jaký přesun CVE vlastně jde.

V tomto případě to je naivní, protože Rust. A u Coreutils není absolutní bezchybnost (zaručená absence zranitelností) zas tak důležitá, aby to někdo psal v něčem opravdu bezpečném.

Tady k tématu obecněji: https://mmapped.blog/posts/15-when-rust-hurts.html
“Accidental complexity” sedí jak p…l na hrnec. Tady tedy na Rust. Bylo by hezké mít nějaký jazyk s výhodami Rustu, ale bez jeho nevýhod, problémů a WTFs. Možná už se něco rýsuje.

a právě podobné experimenty s portací ukazují slabiny, proto tomu fandím

Zběžně jsem to prolítl:

a. Ano, jsou tu nějaké věci, které by snad šlo zlepšit bez větších negativních dopadů. Třeba ten pattern matching. Na to je ale mnohem jednodušší se snažit upravit stávající jazyk…
b. Jsou tu věci, které jsou někdy otravné, ale mají v Rustu dobrý důvod. Kdybychom je chtěli vyřešit, nejspíš nezískáme lepší nebo horší jazyk, ale získáme jiný kompromis. To je případ Common expression elimination.
c. A pak jsou tu povzdechy nad tím, že Rust nevyřeší vše. Ano, nevyřeší, například FS v principu je stav sdílený s ostatními procesy. Zejména u problémů, které sám o sobě zřejmě neřeší žádný jazyk, to zavání nirvana fallacy. Ano, je dobré o tom vědět a myslet na to, když je to relevantní, ale není to nevýhoda Rustu oproti konkurenci…

No právě, každý si musí vybrat svůj kompromis podle kontextu/projektu. Rust je fajn ve velice specifických kontextech, pro většinu projektů by ale ty kompromisy měly být jinde.

Tu je jeden pokus: https://www.youtube.com/watch?v=ELeZAKCN4tY