Vlákno názorů k článku
Rust Coreutils 0.2.0 jsou znatelně rychlejší od Michal Smrž - Těch závislostí je požehnaně. Právě kvůli tomu si...

Spíš naopak. Z hlediska bezpečnosti je anti-pattern používat kód, kterému nikdo nerozumí a má pramalou garantci kompatibility, což je často kód v různých knihovnách, které jsou postaveny nad API systému.

Sice jsou přenositelné, ale na každém systému fungují trochu jinak a málokdo ví, jak přesně (občas se to dokonce mění v různých verzích).

Knihovny mají otevřený kód a na garanci kompatibility existují testy. Právě naopak, případné odchýlky api jsou v modulech a nejsou rostříštené všude po aplikačním kódu, který je navíc unsafe a způsobuje nepředvídatelné chování.

Zrovna třeba mio mění chování a API častěji než epoll v Linuxu. Takže ty testy kompatibility nebudou tak horké.

Neřekl bych. Knihovny (nezávisle na jazyku) které obalují různá nízkoúrovňová API naopak používá většina projektů. Takže buďto (skoro) všichni píšou jeden velký anti-pattern, nebo to anti-pattern není.
A je to dané tím že ne každý má tendence psát furt dokola to samé kolo. Což bych řekl že to je naopak dobře... Proč 100x psát implementaci např. aho–corasicka, implementaci jwt nebo třeba oauth? Pak místo toho abyste se soustředil na to na čem záleží (produkt, aplikace etc.) tak píšete dokola kola která už napsalo X lidí před vámi. Ano je to dobré mentální cvičení, ale zdá se mi že to je tak všechno... A pokud jde o bezpečnost, nechcete tvrdit že umíte psát kód bezpečněji než halda lidí co se podílí na implementaci té/oné knihovny? ;-)

Psát kód lépe než kdokoli ze skupiny lidí, co píšou knihovny? To patrně ne.

Psát kód lépe, než skupina lidí píšící knihovny? To zcela jistě ano. Třeba jeden člověk nedojde ke kravskému nápadu udělat seniornímu kolegovi radost zařazením jeho oblíbené, naprosto zbytečné, extension https://owasp.org/www-community/vulnerabilities/Heartbleed_Bug

> Takže buďto (skoro) všichni píšou jeden velký anti-pattern, nebo to anti-pattern není.

Tak se podívejte, jak se HW zrychluje a SW je stále pomalý, kolikrát aniž by dělal něco navíc než dříve.

> A pokud jde o bezpečnost, nechcete tvrdit že umíte psát kód bezpečněji než halda lidí co se podílí na implementaci té/oné knihovny? ;-)

Určitě ano. Už třeba tím, že moje implementace je jednodušší a nemám tam 10 vrstev zbytečných abstrakcí navíc. Třeba napsat kód pomocí epoll na Linuxu je stejně těžké jako ho napsat pomocí mio v Rustu. Rozdíl je v tom, že u epoll alespoň trochu tušíte, jak se to chová. U mio se musíte podívat do implementace - bohužel totiž není přesně zdokumentované, kdy jakou událost můžete dostat - jen z příkladů vidíte, že některé události jako WouldBlock pro jistotu ošetřují všude.

Pak je třeba řada prapodivně specifikovaných formátů jako ZIP nebo JSON, kde i implementace od velkých korporací obsahují totální prapodivnosti nebo dokonce přímo chování, co specifikace nedovoluje (třeba ZIP na Macu místo použití Zip64 použil starý Zip formát a délku souboru prostě oříznul na 32 bitů). Určitě to dovedu lépe.

Nebo mám vlastní zapisovač do XLSX formátu, protože existující jsou pomalé a spotřebují hodně paměti. Zatímco tomu mému stačí pár kilobajtů paměti bez ohledu na velikost výsledného souboru. Samozřejmě je to na úkor flexibility, ale pro nějaký export dat mi to stačí.

Já pro změnu nepochybuji, že to napsat lépe dokážete.

Dokonce uznávám i ten argument s přehledností.

Ale když bych měl potřebu použít nějakou AIO, tak bych asi použil Mio, protože epoll neznám, a navíc je jen pro linux, a hlavně nemám náladu se učit epoll.

Předpokládám, že Mio napsal nějaký alespoň trochu zkušený vývojář, zkoukla to parta dalších alespoň trochu zkušených vývojářů a tebe nemám. A než na toho pustit nějakého kolegu, který je na stejné neúrovni jako já...