Tady je zajímavý kontext, proč to Google udělal a nepokračoval místo toho raději v rozvoji C++. Je to důsledek neschválení rozbití ABI, což řešil C++ výbor v roce 2020 na standardizačním meetingu v Praze. Udržování ABI kompatibility je pro rozvoj C++ dost omezující, protože kvůli ABI kompatibilitě se nedá udělat např.:
Google má v C++ hodně produkčního kódu a udržování ABI kompatibility ho stojí spoustu peněz (C++ je kvůli ABI kompatibilitě pomalejší, než by mohlo být, takže potřebují víc hardware a v jejich škále to jsou opravdu velké náklady). Takže když nemohli udělat potřebné změny do C++, vytvořili si vlastní jazyk.
Osobně jsem tady spíš na straně Google. Myslím si, že udržování ABI kompatibility je pro C++ škodlivé. Jazyk se kvůli tomu nemůže dál rozvíjet a významní hráči to chtějí řešit a musí to řešit tak, že si vyvinou jazyk nový. Rozhodnutí C++ výboru udržovat ABI kompatibilitu v dlouhodobém horizontu C++ spíš uškodí a je možné, že Carbon C++ časem nahradí.
Ono nejde jen o ABI. On ten unique_ptr je jenom chudá náhražka za rigorózní správu paměti, která v C++ nemůže fungovat bez změny sémantiky, nejen ABI. C++ nemá prokazatelně bezpečné reference, nemá algebraické typy (tudíž nemůže mít ani něco jako Option), funkce musí brát parametry unique_ptr nebo shared_ptr a tudíž není možné napsat funkci, která by byla nezávislá na typu ukazatele na parametr, nemluvě o tom, že tyhle věci doopravdy nefungují. A samozřejmě "this" je klasický pointer à la C, se vším, co to obnáší.
Pomocí std::enable_if nebo nově pomocí conceptů (?). Kdyby tě to zajímalo, tak na tohle téma C++ vs Haskell pěkně píše https://bartoszmilewski.com/.
O to ale vůbec nejde.
Celý problém je ten, že C++ committee něco blbě navrhne, a pak se s tím kvůli ABI nedá nic dělat, a ten jazyk se pak nevyvíjí. Toto není jen unique_ptr, to je třeba i regex a spousta dalších věcí. A jsou i lidi, kteří by chtěli ve standardu z nepochopitelných důvodů 2D grafiku nebo audio!!!
Já jsem zastáncem rozbití ABI. C++ stejně žádné "stable" ABI nemá a kdo chce silné ABI tak udělá C interface.
BTW: Stačí předat parametr referencí, používat unique_ptr a shared_ptr v rozhraní je podle mě anti-pattern a zbytečný implementation detail, který není potřeba leakovat někam ven.
24. 7. 2022, 15:58 editováno autorem komentáře
Google už dávno svoji vlastní implementaci asociativních kontejnerů používá, má abseil. Stejně tak Facebook má folly. Takže jsme v situaci, kdy existují o dost lepších implementace, než které nabízí standardní knihovna, ale do standardní knihovny je nejde dostat kvůli ABI kompatibilitě. Tohle nevyhovuje nikomu, ani Googlu/Facebooku, kteří musí udržovat svoje implementace bokem, ani uživatelům standardní knihovny, kteří by mohli mít rychlejší implementaci, ale nemají, protože ABI kompatibilita.
A nejde jen o standardní knihovnu, do C++ třeba nejde přidat int128_t integer, protože existuje intmax_t, což nejde změnit, bylo by to rozbití ABI. Dobře je to popsáno zde: https://cor3ntin.github.io/posts/abi/
Google se to pokusil vyřešit, navrhoval rozbití ABI kompatibility, což ale neprošlo, takže zvolili jinou možnost, udělali si nový jazyk. Ze strany Google je to docela logický postup.
A ono nejake stabilni ABI fakt existuje? Tenhle argument me prekvapil.
MSVC ho rozbiji ukazde major verze. Debug build ma jine ABI nez Prod build,...
Zkuste si vyhodit vyjimku z g++ X a zachytit ji v g++ ver Y. Proc existuji header-only knihovny?
PS: Kdysi jsem napsal gramatiku pro parsovani PL/SQL a nechal ANTLR vygenerovat zdrojaky pro C/C++ a Javu. Dost me prakvapilo, ze parser v Jave byl 2x rychlejsi nez C++. Stravil jsem s tim nekolik tydnu nez jsem prisel na to kde to drhne, a nakonec to bylo prave v kontejnerech, skrytem kopirovani stringu nekde na pozadi a efktivite vyhodnocovani podminek.
Jako ze Java implementace mela mnohem vetsi uzivatelskou zakladnu a kod runtime byl urzovany. Zatimco C/C++ vyuzivalo jen pak "zoufalcu", kteri si mysleli ze kod pro C/C++ musi by "automaticky" rychlejisi.
aneb počkáme až se něco vývojáři pořádně naučí tak, aby v tom mohli profesionálně dělat, a pak jim předhodíme "moderní" novinku, aby se místo skutečné práce zase mohli začít od nuly učit "moderní a pokrokové" věci s pocitem že používají špičkové technologie; teď jen aby z nich taky vypadlo něco víc než "hello world"....
Už né další zapřísáhlý nepřítel typové inference. Zkus si někdy nějaký jazyk s pořádným typovým systémem který se i řádně používá a nepoužívat inferenci. Mě by asi trefilo...
Teď dělám na jednom projektu kde ta typová signatura může mít až několik řádků.
24. 7. 2022, 10:57 editováno autorem komentáře
V Rustu. Přesněji s touto skvělou knihovnou: https://docs.rs/chumsky/latest/chumsky/
Měl jsem tu čest pracovat na projektu kde byl jeden člověk jehož motto bylo "auto everywhere". Nevěřil bys, ale udělat review a údržbu takového kódu stojí hodně času a úsilí.
Nikdy jsem neřekl, že auto je špatně, ale používat ho všude a vlastně vůbec nevědět, co kde je, good luck u velkého projektu co má miliony řádků kódu...
Tak v takové situaci to chápu, v tu chvíli má celý projekt úplně jiný coding style. Možná bych se to v tu chvíli snažila částečně obejít nějakou mock knihovnou která bude poskytovat api pro snadnější vývoj, ale v takové situaci jsem nebyla. Mně teď stačí že musíme pravidelně skoro naslepo integrovat projekt s kdejakým proprietárním nemocničním softwarem, který si standardy mnohdy vykládá po svém, a jestli to bude fungovat se zjistí až při deploymentu.
Ten povzdech s auto ovšem zněl jako by to bylo špatně za každé okolnosti.
Ne, protože ho většinou ani nevypínám, ale umí to i každý rozumný programátorský editor. A i bez toho, pokud jsou proměnné pojmenované rozumně, na zběžné "prohlídnutí" kódu přesný typ často znát nepotřebuju. Na složitější už se fakt hodí mít možnost přesunu na definici funkce, tooltipy se signaturou funkcí, docstringy a podobně, což bez rozumného editoru stejně nejde.
V Rustu se typy specifikují fakt jen v případě kdy není inference možná, a že by to někomu chybělo...
Neznámá *code base* s neznámými signaturami funkcí, na to se přeci nějaký nástroj pro inspekci zdrojového kódu hodí, nebo ne? A nemusíme to mu říkat IDE. Každý lepší editor dnes má plugin s LSP pro daný jazyk. Doby kdy se programy psali pomocí standardní knihovny, nebo sis vše psal sám a tudíž jsi věděl, co která funkce bere a vrací, jsou dávno pryč. Nostalgii dejme stranou.
U nových jazyků ani u spousty věcí nemusí být jasné, jak je správně psát, protože se to u toho jazyka prostě ještě nestihlo ustavit. Je to součást adopce nových jazyků, že se hledá, jak v nich vlastně psát (a zda v nich psát). Navíc i u starých jazyků se vyvíjí úzus, jak v nich psát (a nejde jen o nové vlastnosti jazyka).
Nové jazyky vznikají stále. Jsem v IT od 90 let, a nevzpomínám si na dobu, kdy by se neobjevil nějaký nový jazyk. Přežije jich minimum a mimo dílnu svého autora se jich začne používat promile. O náhradě C++ se mluví 20 let. Osobně si nedovedu představit masivnější rozšíření s tak vůči C++ odlišnou syntaxí.
Ještě se doplním - to, že nové jazyky vznikají a zanikají je dobře - mění se IT, mění se možnosti, mění se úlohy, mění se komplexita úloh, se kterými se pracuje. Nové koncepty, nové jazyky prošlapávají cesty, a vývoj jazyka, jeho testování není dobré dělat na rozšířeném masově používaném jazyku. Něco z toho se pak dostane do stávajících jazyků, s novým konceptem, paradigmatem, prostředím mohou vzniknout a rozšířit se i nové jazyky (mohou vzniknout nové revize programovacích jazyků a prostředí).
Jinak, čím je IT jako obor starší, tím je přijetí a rozšíření nového programovacího jazyka pomalejší a méně pravděpodobnější. Carbon, pokud by se začal používat, tak mimo Google na nových projektech za 5 - 10 let. Jako náhrada C++ (že by se začaly stávající projekty přepisovat) to je možná horizont 10-30 let. Nový jazyk nemá programátory, nemá lektory, neexistují pro něj osnovy a ani studenti.
Ne každý z těch nových jazyků byl propagovaný jako náhrada C++. A to jsem ani nepsal a nemyslel. Ale o neřešitelných problémech C++ se ví déle než 20 let (tím myslím baroknost návrhu, redukce C++ není možná z důvodů zpětné kompatibility), a tudíž se dá čekat, že tu budou vznikat nové kompilované OOP jazyky aspirující na to, aby C++ nahradili. Vzpomínám si na SWIFT, NIM, C#
Swift měl myslím nahradit zastaralé Objective-C, i když zrovna na něj platí “baroknost návrhu” taktéž. U Go si vzpomínám, že jeho vznik obhajovali pomalostí překladu C++. Evidentně problémy C++ pálí kdekoho :) U těch nových jazyků ale také bývají komplikace, Rust se kompiluje stejně pomalu jako C++, Swift je víceméně jen pro macOS, iOS, iPadOS, tvOS a watchOS — wow, pět OS :D — takže Carbon možná smysl dává, pokud nepřinese zase jiné problémy.
Swift je pro všechny OS: https://www.swift.org/download/
Tady máš jako příklad kalkulačku pro Windows:
https://www.swift.org/blog/swift-on-windows/#example-application
Podobně Objective-C byl taky i pro Windows a Linux (tam je dokonce přímá podpora jeho systému předávání zpráv v kernelu).
EDIT: A samozřejmě Swift, ObjC (a třeba i C#) nejsou pro všechny OS jen v podobě holého jazyka, ale včetně standardní knihovny:
https://www.swift.org/standard-library/
U ObjC vznikly jedna nebo více OSS implementací Cocoa knhovny.
25. 7. 2022, 13:39 editováno autorem komentáře
To tady asi všichni víme, ale všude mimo applí OS je to prakticky nepoužitelné (v IBM to zkoušeli a vzdali). ObjC na Linuxu bylo taky pakárna, jiný runtime, zastaralé verze, nemožnost statického linkování, napůl (ne)funkční ARC, prostě vopruz. Je to jako C# mimo Windows, přeloží se “hello, world” a s trochou štěstí kalkulačka, ale k produkci to má stejně daleko jako trakař ke stavbě kosmodromu (kromě Bajkonuru onehdá).
.NET má z historických dôvodov problém s UI, tak teraz vyvýjaný
.NET MAUI nepodporuje Linux. Plus viaceré knižnice sú naviazané
na MS SQL (beží ale pod Linuxom.)
Väčšina vecí funguje bez problémov. Stačí zopár príkazov a pár minút, a máme pod Linuxom k dispozícii jeden z najviac prepracovaných a najrozsiahlejších vývojárskych ekosystémov k dispozícii. Od webu, po gaming, IOT, či machine learning.
Pokud vím, hlavní předností Rustu (oproti třeba Go) má být fakt dobrá interoperabilita s C++, tak aby je bylo možné pohodlně kombinovat v rámci jednoho softwarového balíčku / knihovny.
Podobné je to s Kotlinem a Javou - interoperabilita je tak dobrá, že vzít čistou Java knihovnu, udělat z ní kombinovanou Kotlin+Java knihovnu (v Bazelu java_library -> kt_jvm_library), a připsat novou třídu v Kotlinu, aniž by se někde jinde něco po*ralo, není těžké.
Bez tohohle "file by file adoption" by se nedalo doufat v nějaký zásadní posun k novému jazyku v tak mamutím repozitáři, jako je google3 (který máme rozdělený do mrtě balíčků, vlastněných různými týmy, a celé se to bez ustání kompiluje pořád dokola).
Neříkám, že je to postačující podmínka, ale je nutná. U Go tohle nejde, a je to znát.
Jinak takřka dokonalou interoperabilitu s C++ má Objective-C (blahé paměti). Ta má navíc zajímavou historii, došlo k tomu víceméně náhodou a z lenosti. Dodnes to je relevantní pro níže zmíněný Swift, ten si rozumí nativně jen s C, ale přes ObjC runtime namapovaný na svůj typový systém zvládne přímo i C++.
radsi meli forknout c++ treba 20, zmenit vse co potrebovali zmenit, ale co nejvic nechat syntaxi i kdyz by se neco nezkompilovalo, fn, var se mi moc nelibi.
nazval bych to radsi c+=20
libi se mi vice golang, ze ma jenom pointery.
ale dal bych prednost moznosti chytrym pointerum a ne jenom gc.
rust chapu jako lepsi vyvoj od c++, ale vadi mi v nem a taky i v c++ michani
pointeru a referenci.
novemu c+=20 bych nechal pointery a const pointery misto referenci,
reference bych nepouzival.
treba = by bylo automaticky move jako v rustu pro slozitejsi typy.
Zrovna syntaxe c++ je dost špatná. Strašně blbě se parsuje a je plná pastí jako Most Vexing Parse. Kdyby se mělo vyházet všechno, co je blbě, tak z té původní syntaxe stejně moc nezůstane.
V c++ třeba překladač jednoduše nezjistí, jestli parsuje deklaraci funkce nebo definici a inicializaci proměnné.
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
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.)
Chtěli jsme si to zkusit, protože byl (je) kolem embedded Rustu hype. Došli jsme k závěru, že to není nejvhodnější (nejproduktivnější) nástroj na tuhle práci, což bylo taky účelem toho experimentu. Rust elegantně řeší správu paměti, ale lámat to na věci jako stav hardwaru (který může změnit i něco jiného než aplikace, např. přerušení) mi přišlo spíš krkolomné.
“Cílem je, aby Rust měl keci” Ultimátním cílem je, aby kecy neměl, jelikož to pak znamená, že člověk píše kód z fleku dobře a ušetří těch 80% úsilí, které vynakládal, když Rust ještě pořádně neuměl. Tohle je výhoda Rustu oproti Go, které moc keců nemá, takže mizerný kód s chybami dojde tiše až do produkce.
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.
Zig má language server, takže v podstatě všude funguje "intellisense"... vscode, ale i ve všech možných odrůdách Vimu (včetně neovim, kakoune, helix). Většina z uvedených má i vlastní tree-sitter parsery.
Jo, ta syntaxe mi taky úplně nesedí, povinné odsazení 4 mezerami mě vyloženě sere (preferuju tab se šířkou 2 znaky), ale zkousnu to, když výsledek funguje.
25. 7. 2022, 13:40 editováno autorem komentáře
Nestandardní modifikace C++ - to už tady bylo a je to na adopci horší něž nový jazyk. Jinak těch __attribute__ a __declspec__ je málo?
Problém C a C++ je ten, že bez __attribute__ a různých __declspec v podstatě nejde napsat portabilní kód. A aby to bylo portabilní, tak se to celé použije přes makra, které se pro různý compiler / OS definují různě.
Takže za mě by bylo třeba super standardizovat něco tak triviálního jako třeba "jak exportovat funkci".