Vlákno názorů k článku
Carbon: nový jazyk od Googlu má být nástupcem C++ od fortran1986 - Nástupcom C++ mal byť Rust, teraz keď Google...

Nástupcom C++ mal byť Rust, teraz keď Google uvádza vlastného nástupcu zatiaľ čo Microsoft, Amazon a Facebook podporujú Rust a Apple má svoj Swift sa ten nástupca rozbil na troch nástupcov, ktorí sú pre nováčikov na prví pohľad podobní, takže nakoniec sa ajtak ostane pri zavedenom C++. Google týmto vlastne nechtiac pomohol C++ k tomu aby tu s nami bol ďalšie 10tky rokov.

A okrem toho ja mám C++ rád. Baví ma na ňom práve to nekonečné piplanie sa a zdokonalovanie kódu. Taktiež C++ je jeden z mála jazykov, ktorý sa človek nikdy nenaučí na 100%, takže je stále čo objavovať.

Keď chcem rýchly vývoj aplikácií siahnem po funkcionálnom jazyku (napr. OCAML). Keď chcem niečo univerzálne (hry, IoT, desktop, konzola, ...), niečo čo je orientované na rýchly, malý a efektívny kód siahnem po C++.

24. 7. 2022, 21:33 editováno autorem komentáře

OCaml! FORTRAN bych ti i odpustil, ale OCAML ne .)

No vidiš. Na mě to tak nezafungovalo. Pro mě je C/C++ definitivně mrtvá záležitost.

Kontakt s realitou? Pokud neděláš stupidní informační systémy, nebo naopak řešení problémů vyžadujících DSL, c++ is the choice. Ale ukaž mi, že to tak není, třeba na pseudo embed systémech typu nVidialních SoM.

25. 7. 2022, 01:35 editováno autorem komentáře

Když dělat cokoliv malého embedded v Rustu je děsné utrpení. Podpora teoreticky existuje, ale knihovny moc ne a v praxi je to pořád nějaký wrapper..

C / C++ bez dynamické paměti je celkem v pohodě, odpadají všechny ty problémy s move, borrow a podobně. Vícevláknovost taky není moc potřeba (nějaká chytrá superloop nebo RTC scheduler stačí).

(Aby bylo jasno, nemluvím o embedded linuxu ani "velkých" RTOS, které v Rustu tedy také nejsou).

Mám stejnou zkušenost. Relativně malá věc (obsluha takového průmyslového průtokového ohřívače, takže pár čidel, PID regulátor, triaky, CAN rozhraní), měli jsme dost času tak jsme zkusili Rust, načetli svatou knihu a Embedonomicon, podle toho napsali bare metal firmware... funguje, ale rozdělení úsilí bylo tak 80% přesvědčování jazyka aby mi dovolil udělat co chci (zapsat bit někam do hw registru) a zbytek samotný vývoj aplikace. Chránit borrow checkerem HW periferie zní zajímavě na papíře ale reálně to je spíš boj, kor v takhle minimálním prostředí kde i relativně nezkušený programátor ví, co má procesor udělat na úrovni instrukcí (protože si to přečetl v datasheetu).

Experiment to byl zajímavý, ale vrátili jsme se k C. Jako compiler používáme zig cc (wrapper okolo clang/llvm) protože nesmírně zjednodušuje cross-compiling, a v posledních projektech jsem si všiml že kolegové mají i pár zig souborů. Usnadňuje to tvorbu některých abstrakcí: zig má luxusní způsob jak definovat složité Cčkové structy s přesně daným tvarem v paměti, takže se s tím snadno dělají drivery pro MCU hardware.

Nechci tvrdit, že jste to dělali špatně, a že Rust je na micročipy lepší volba než C... protože prostě já micročipy nedělám, a tak nemám zkušenosti.

Jen bych chtěl okomentovat, že "rozdělení úsilí bylo tak 80% přesvědčování jazyka aby mi dovolil udělat co chci (zapsat bit někam do hw registru) a zbytek samotný vývoj aplikace." - je principielně žádoucí chování. Časté nepochopení lidí je, že vyčítají Rustu jeho keci a že jim to brání v práci. Cílem je, aby Rust měl keci. To je to co chceme. (Zda je to výhodné i u těch micročipů, to už nevím.)

Ano pisat v Rustu embeded veci, je same unsafe a pointeri, proste ono sa to uz ani nepodoba na Rust a vsteky jeho principy treba obchadzat.

AKo ja by som bral nahradu C-ecka, nieco podobne ako bol experimentalny projekt "safe C", ale s tym, ze by tam boli skutocne genrika a defer operator, alebo using s C#. To by bohate stacilo a uhlacilo by to pracu s koleciami a opakujucim sa kodom.

Koukněte na Zig, ten tak nějak splňuje. Low level, dá se naučit za víkend, skutečná generika a defer operátor, a first class cross-compiling.