Vlákno názorů k článku
Google dává 1 milión dolarů na zlepšení interoperability mezi jazyky C++ a Rust od Ondřej Novák - Já tomu nerozumím. Rust vznikl jako pokračování C,...

Jak moc low level věci píšete?

Nerozumím smyslu otázky. Má posunout debatu, nebo jde o osobní dotaz jen tak?

"Nerozumím smyslu otázky." Tak to je mi líto.

V pohodě, jsem rád, že nesklouzáváme k jízlivosti a jsme konstruktivní. Také jsem se pobavil.

"pokud má moderní jazyk nekde slepé místo"
Rust je slepé místo.... Když si vemeš tak pořád vede java/ TS, ve velkém python, pak C#, či C/C++....
Řekni mi proč bych měl využívat Rust? Když mám možnost to psát v pythonu, nebo C#, či C++...
Rychlejší? Zatím jsem neviděl test, který by byl relevantní, či prokázalže zrovna Rust je lepší.. je rozdíl použít co je a pak v rustu napsat, následně srovnat a program, který je komplikovaný je náhle pomalejší...

Kdyz jsem v roce 2003 napsal svuj prvni program v Pythonu, taky mi spousta lidi rikala, ze je to obskurni jazyk, pomaly a ze nema sanci se nikdy uchytit. Myslim, ze s Rustem (ci necim podobne rychlym s automatickou spravou pameti) to bude podobne.

To je směšný, tohle je jen klasickej konzervatismus a strach z novýho.
Rust rozhodně není slepé místo. Umožňuje psát programy se stejnou low-level granularitou jako v C, ale mnohem efektivněji a s daleko méňe chybami. V podstatě odpadá nutnost se ručně vypořádávat se správou paměti a to narozdíl od GC jazyků jako C# bezeztráty výkonu. A například to FP style monadický error handlování je top. V C je to hrozně verbose a v C++ exceptiony to sou prostě enterprise-grade GOTOs, to je ještě horší než pure C.

Jinak ta interoperabilita s C++ je samozřejmě nasnadě, např. kdyby se dalo Qt a KDE psát v Rustu, byl by ten vývoj mnohem rapidnější.

Znáte std::expected a std::optional? Každý moderní jazyk se teď inspiruje v FP světě. Výjimky se dají zakázat a některé code base s nimi nepracují.

> V podstatě odpadá nutnost se ručně vypořádávat se správou paměti

Což se dosáhlo tím, že je správa paměti ještě složitější než třeba v tom C.

> narozdíl od GC jazyků jako C# bezeztráty výkonu

Takhle obecně je to tvrzení nepravdivé. V podstatě je to už spoustu let vyvrácený mýtus.

>> narozdíl od GC jazyků jako C# bezeztráty výkonu

> Takhle obecně je to tvrzení nepravdivé. V podstatě je to už spoustu let vyvrácený mýtus.

Zajímavý odkaz k tématu: https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/

> Řekni mi proč bych měl využívat Rust?

To Ti říct nedokážu, musel bych vědět, jaké máš priority, zkušenosti a mozek. V programování neexistuje "lepší" a "horší", to si každý vývojář, tým, firma musí rozmyslet. Přesto to zkusím:

Fast, Reliable, Productive. Pick Three.

Tohle je nejlepší reklama na Rust, jakou znám. Pokud chceš rychlost srovnatelnou s C a C++, máš možnost, zde je benchmark - doslova všichni mají neustále možnost ve svém jazyce udělat novou implementaci:

https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22

Co se týče produktivity, Rust je hodně vysokoúrovňový, co se týče abstrakcí, datových struktur apod. A hlavně člověk šetří čas při správě kódu, jelikož co se v Rustu zkompiluje, obyčejně funguje. A refaktorizace je třeba oproti tomu Pythonu úplně jinde (i když mu typové anotace hodně pomohly).

No a ta spolehlivost je dána samotným návrhem, ten jazyk je zkonstruován tak, aby maximálně eliminoval překvapení a nedefinované chování.

Ale pokud chceš dělat v TypeScriptu, Zigu, Javě, Ruby, Go, Fortranu, klidně to dělej. Máš o možnost navíc, ale nemusí Ti sednout.

> V programování neexistuje "lepší" a "horší", to si každý vývojář, tým, firma musí rozmyslet.

Tak proč mluvíš za všechny? Proto jsem se ptal jak moc low level věci píšeš. Např. v embedded nevidím žádný exodus k Rustu. Rust vůbec není špatný jazyk, ale rozhodně není náhradou za C nebo C++. V současné době ani blízké budoucnosti toto nehrozí.

> Tak proč mluvíš za všechny? Proto jsem se ptal jak moc low level věci píšeš. Např. v embedded nevidím žádný exodus k Rustu. Rust vůbec není špatný jazyk, ale rozhodně není náhradou za C nebo C++. V současné době ani blízké budoucnosti toto nehrozí.

My ale v tomto přece nejsme ve při. Jediné, co jsem tvrdil je, že Rust cílí do prostoru C++ a není koncipován jako náhrada C. Všechno ostatní je věc názoru a individuálních potřeb. Že je Zig lepší náhrada C tam, kde je vhodné používat něco jako C (což neznamená, že co bylo jednou v C, nemůže se nikdy s úspěchem reimplementovat v něčem docela jiném), jsem přece nikdy neskrýval.

Zrovna v embedded dává Rust docela smysl.

Není to sice echt embedded, ale např. nově napsaná user-space podpora DSP audia funkcí pro Apple Mx v Asahi Linuxu je komplet v Rustu https://github.com/AsahiLinux/asahi-audio . Ideální use case pro Rust.

Neexistuje a pravděpodobně ani nebude existovat univerzální jazyk na všechno.

Python je skvělý glue jazyk, který vyniká v interoperabilitě a navíc je čitelný a použitelný i pro neprogramátora - rozuměj vědce, data scientistu...
Python je skvělý i na psaní webových aplikací - flask, fastapi, django.
Python je memory safe - má GC.

Jenže, když je aplikace latency constraint a je pod loadem, objevují se výrazné spiky v latenci způsobené GC. Existují workaroundy jako vypnutí GC, vyprofilování memory cyklů a jejich odstranění z programu a případně řízené restarty s replikami/workery v HA režimu (a ani toto není občas řešení, protože ta paměť může vystřelit velmi rychle). Ale pak vás výše uvedené kolečko testování a workaroundů čeká s každou změnou v kódu. Nic vám totiž nepohlídá, že další změnou nevytvoříte cyklus v paměti. Jediný jazyk, který toto hlídá a je memory safe, je Rust. Nepomůže vám ani C# ani Go ani Java ani JavaScript/TS - všechny tyto jazyky mají GC.

Python je pomalej a má minimum záruk.
C# je hloupej.
C++ je složitej.

Prosím více takových nablblých příspěvků! Máš pubertu nebo opravdu pracuješ v oboru?

Tu algebru snad už dokonce protlačili. Ta 2D knihovna byla naprosto zbytečná. Trochu šikovnější člověk si něco takového musí umět napsat sám, vůbec nevím v čem by to komu pomohlo.

7. 2. 2024, 13:29 editováno autorem komentáře

Já třeba nechápu, komu pomůžou 3 implementace linalg v C++, když tu máme OpenBLAS, který má tolik architecture specific optimalizací... že se to někomu chce dělat... ale hlavně, změníme terminologii a všechno přejmenujeme, protože na to committee čas má!

Problém C++ standardní knihovny je, že jsou potřeba 3 implementace, a ty implementace jsou jiné a můžou mít jiný výkon, memory footprint, atd... Proto se std v podstatě vyhýbám, protože pak řešit, že něco někde je pomalé, atd... to nechci. Hezký příklad je std::regex a std::deque - MSVC tak zprasil deque, že se v cross platform projektech tento kontejner v podstatě nevyskytuje... Ale můžeme jít dál, třeba std::ranges a filtrování, tam taky hodně lidí narazí, nebo třeba velikost tuple v závislosti na compileru atd...

Takže souhlas, nikomu to ve výsledku nepomůže, protože ti co potřebujou BLAS, tak budou používat BLAS a vykašlou se na zprasenou implementaci v C++. Navíc co mám rád u těchto C knihoven je fakt, že nejsou jen pro C.

7. 2. 2024, 14:04 editováno autorem komentáře

std::regex - to se ví už dávno, cílem je připravit DFA v compile time, Hana Dusíková je v tom zavrtaná
std::deque - microsoft má obecně zvláštní implementace standardních knihoven
std::ranges - lépe použitelné od C++23, podle mě to má potenciál, ale pravděpodobně si budeme muset počkat než se posune core a optimalizace
To co považuji za opravdu obludné je používání boostu v knihovnách.
"vykašlou se na zprasenou implementaci v C++. Navíc co mám rád u těchto C knihoven je fakt, že nejsou jen pro C" C abi je kompletní a proto je použitelné.
Problém C++ wraprů C knihoven je ten, že to nikdo neudržuje a nevyužívá moderní přístup k memory a resource managementu, takže lepší je si napsat ten C++ wraper sám.

"cppfront je sračka" tak to asi težko, jedná se o výzkumný projekt, má svoje přesně definované cíle.
"Herb Sutter je známý tím, že by do C++ chtěl dát úplně všechno, protože používat knihovny je složité" Sleduju ho již dlouhé roky a nic takového u něj nepozoruji.
"Není to tak dávno co se snažil do C++ protlačit 2D grafiku a API pro zobrazení okna... ještě, že mu to neprošlo" Jednalo se o výzkum, zda do C++ lze dát knihovnu pro základní podporu "Human interfaces", nešlo primárně o to cpát uživatelská prostředí do standardních knihoven. Těch SGček tam bylo před pěti roky hodně, většina z nich skončila bez výsledku.
"Na druhou stranu zase někdo jiný tam tlačí linear algebra" To je v pořádku, jedná se o maticové a vektorové počty s případným využitím simd.
"Největší problém C++ momentálně je, že používat third party knihovny je někdy za trest, a toto má vliv na committee, které teď nemá problém s tím dávat víc a víc knihoven do std." To je záležitost tak posledních deseti let, kdy i Stroustrup mluví o potřebě standardního balíčkovače pro C++ ekosystém, který by obsahoval knihovny(podobně jako nuget) kdy v IDE po import modulX; to stáhne do projektu potřebný balíček.
"Tímto páchá vlastně takovou pomalou sebevraždu, protože všichni víme, jak to s těma knihovnama ve std knihovně je..." no já nejsem telepat, takže nevím a nejsem ani všichni

Já ti odpovím - do std se přidá nějaká knihovna, která existuje i jinde (třeba regex, linalg, atd...). Po čase je potřeba nové API, nebo něco změnit, tak jak to u knihovnen bývá... jenže ono to nejde protože ABI, protože není na to čas, atd... Standardizace je byrokratický proces, to není jak někde otevřít PR a mít něco v upstreamu hned...

Takže časem už o ty std knihovny nikdo ani nezavadí, protože jsou outdated a externí jsou dál, jenže v std musí stále hnít - a mají 3 různé implementace, protože dnes má každý compiler svoji std knihovnu...

Asi tak... Na compile-time reflekci čekám od C++11, ale místo toho dostávám pod nos věci, které už existují, a nevidím tam žádnou hodnotu. Já chci low-level věci, pro které C++ je dělané... třeba bit manipulation (popcnt, lzcnt, tzcnt, reverse), bit_cast, atd... na tyto triviální věci se musí čekat 15 let, a přitom to jsou zrovna věci, které implementuje většina CPU a většina pro ně má intrinsics...

7. 2. 2024, 22:53 editováno autorem komentáře