Názory k článku
Podpora Rustu míří do překladače GCC

Již se těším.

Podle mě již C++ a Java jsou již poněkud vyčerpané, nejspíše proto, že to přehánějí se zpětnou kompatibilitou. Například jak dlouho C++ trvá osvojení klíčového slova synchronized a eventuálně dalších pro paralelní provádění.

Rust se taky vyčerpá. Najde si svou oblast (jádro, ovladače) a tam uvízne.

A co objekty? Objeví se frameworky, stane se mocným i jinde.

Rust si už našel tolik oblastí, že se může klidně stát skoro čímkoli.

Které oblasti? Jádro, možná crypto fintech? Všude je v menšině jako kuriozita.

Co vám brání strčit do objektu mutex a použít lock_guard?

Jak myslíte, že bude klíčové slovo synchronized implementované?

Cpát javovské synchronized do c++ je trochu problém, protože ty dva jazyky se v některých aspektech dost podstatně liší.
V Javě je jasné, co to synchronized zamyká. Každý objekt je samostatně existující entita, která má v sobě vždycky monitor. I když drtivou většinu objektů nikdo nikdy zamykat nebude.
V c++ není vždycky úplně jasné, co by se mělo přesně zamykat. A jaké vlastnosti by ten mutex měl vlastně přesně mít?

Těch objektů, které má smysl zamykat, zas tolik není. A jak už psal Ondřej Novák, napsat synchronized block, nebo do bloku strčit guard se složitostí zas tolik neliší.

A pak taky c++ razí celkem rozumný přístup, že není třeba cpát do jazyka věci, které se dají pořešit čistě na úrovni knihoven. Už tak je ten jazyk komplikovaný jako prase.

Rust neznám, ale k čemu je tak dobrá podpora v gcc? Do teď to bez ní taky evidentně šlo.

Např. pro Javu existovalo GCJ, které už dávno není podporované a myslím, že to nikoho netrápí.
https://gcc.gnu.org/wiki/GCJ

K ničemu.

Řekl bych, že podpora GCCRS je žádoucí pro ekosystém Linuxu, protože ten je v současné době postaven hlavně na jazyku C. Pro Linux musí GCCRS a GCC koexistovat.

Jazyk C, jakkoliv je nadčasový, je pro větší věci limitován kvůli absenci striktních typů a objektového programování. Rust také oproti C nabízí lepší bezpečnost a větší souběžnost.

C++ je sice objektový a umí cokoliv, ale někdy to je složité a těžkopádné. Spíše pro velké borce.

Díky za tip na Javu a GCJ, mrknu se na to.

Cože?

Absence objektů by snad ani nevadila, ale ta bezpečnost určitě.

C++ je spíš pro masochisty než borce :) Každopádně v jádru si neškrtne, Linus je ostře proti.

Akorát že C++ od verze 11 má trochu jiný vývoj a v současných verzích 20 a 23 je to dávno jiný jazyk, než si ho Linus pamatuje.

A Linus jen potvrzuje pravidlo, že neexistuje génius na všechno. On umí to svoje, o C++ nemá žádnou představu, nesleduje to, nemá dostatečné informace.

Když se podívám na kód jádra s optikou C++, tak ... no napsat mi někdo takový kód v týmu, tak nejen že neprojde code review, ale navíc dotyčný dostane výpověď. Prostě Céčko no... starodávný vyčpělý jazyk... A jestli to má zachránit Rust... nevím.

C je starý jazyk, ale pořád užitečný. Jako třeba Fortran, každý má svou oblast, kde se stále používá jako hlavní jazyk.

C++20 je jistě velký pokrok oproti “starému” C++, ale Go a Rust jsou silná konkurence.

Souhlasím. I když modularita s rozhraními se u větších projektů hodí. Na druhou stranu bych řekl, že Rust není v objektech netolerantní, jde přímočaře napsat rychlou rutinu, i bez použití objektového programování.

Ale musím říci, že i ta parciální praktičnost je fajn.

Rust má svoje traity, to je v pohodě, obšlehli to z Go a jen jinak pojmenovali. Dle mého skromného názoru absence “plnohodnotného” OOP à la Java nevadí. Typové systémy Rustu a Go jsou poměrně rozumný kompromis, víceméně staré dobré céčkové struktury, ale s přidaným dynamickým dispatchem ve formě rozhraní/traitů. Zdá se, že se to v praxi osvědčilo.

Minimálně jednoho člověka neexistence GCJ trápí natolik, že to snaží revitalizovat, viz https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607205.html a 56 dalších patchů :-)

Zpočátku jsem si kladl podobnou otázku, ale prý to přinese podporu více platforem. Což se na první pohled může zdát zanedbatelné, ale pokud to bude znamenat, že Rust bude pro všechny targety Linuxového kernelu, může to být významná zpráva i svět x64/arm64. Rezavění kernelu by se nemuselo omezovat jen na moduly relevantní jen na některých platformách, ale mohlo by se týkat v podstatě všech oblastí.

Nebylo by lepší tu práci investovat do rozšíření podpory stávajícího překladače Rustu?

Neni v tomto Rust omezenej spise LLVMkem?

Je, tak jsem to myslel, přidat do LLVM podporu pro další platformy.