Carbon: nový jazyk od Googlu má být nástupcem C++

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ř.:

• zrychlit asociativný kontainery ve standardní knihovně
• opravit std::regex (implementace je hrozná, nepodporuje unicode a navíc je pomalá)
• pročistit standardní knihovnu od historických reliktů (např. scoped_lock byl přidán kvůli tomu, že nebylo možné kvůli zachování ABI upravit lock_guard)
• zrychlit zpracování výjimek

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í.

To je sice pochopitelné, ale mohli použít své Go nebo Rust, oba jazyky už jsou dost vyzrálé a prověřené.

Pro projekty na zelené louce ano. Ale oni mají dost codebase v C++, kterou používají a rozšiřují a chtěli by zefektivnit její běh.

Go je kvuli GC spatne pouzitelne pro psani knihoven ktere maji byt volane mimo Go. Napriklad TF.

24. 7. 2022, 11:40 editováno autorem komentáře

Ono se hodně diskutuje i neefektivita tak základní věci jako je "std::unique_ptr<>" - a kvůli zachování ABI se s tím nedá nic dělat.

Takže to končí tak, že kdo chce opravdu výkon, tak nepoužívá tyto věci z std knihovny. No, a kdo nechce výkon, tak může sáhnout po jiném jazyku že jo...

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áší.

C++ má součtové typy od C++17. Taky má HKT, na rozdíl od veškerého mainstreamu (kromě Haskellu).

std::variant je součtový typ asi jako std::unique_ptr je prokazatelná správa paměti :) HKT v C++ opravdu nejsou.

Tak HKT má i Scala a OCaml, kromě "mainstreamu" jménem Haskell.

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

První tři věci nejsou věcí jazyka, ale standardní knihovny. Kdyby to bylo to jediné, co Google trápí, tak prostě bude využívat svou vlastní implementaci asociativních kontejnerů, svou vlastní implementaci regulárních výrazů a nebude používat historické relikty ze standardní knihovny.

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.

Jo... obecně se říká, že pokud chceš tu nejhorší implementaci nějakého containeru v C++, tak použij tu ve standardní knihovně :)

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.

Pokud parsuješ nějaký AST a ten chceš pak zahodit až ho zpracuješ, tak práve C++ je na toto ideální - stačí arena alokátor a pak ty data prostě zahodit.

Ale jo, custom kolekce to je něco co vidím hodně často právě kvůli té pomalosti v C++ - dokonce i custom string, atd...

MS už dávno ABI nerozbíjí. Když rozlišíte ty debug a release buildy, tak bez problémů přilinkujete statické libky ze starší verze visual studia. Ve VS22 teď linkuju věci zbuilděné VS17.

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"....

Já bych to nechal na vývojářích, ať používají jazyky, jaké chtějí. Když nejste vývojář, nedokážete to posoudit, co to znamená „pořádně se naučit“ nebo jaké jsou rozdíly v používání různých jazyků.

Dart, Golang, teď Carbon...

Aneb kdo chce psát "var x : f32 = 1" a přijde mu to lepší než "float x = 1" ...

jo, někdy platí "ignorance is strength" :)

V jakém jazyku? V Pythonu to řeším type-aliasem, kde to jde snadno. V C++ se to také tak dělá, ale nevím jak třeba v Java, tam to asi nejde. Díky.

24. 7. 2022, 11:29 editováno autorem komentáře

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...

Ak narazas na roman 1989 tak potom: Vojna je mier, sloboda je otroctvo, nevedomost je sila.

Že románem „1984“ často argumentují lidé, kteří vůbec neví, o čem je, jsem si zvykl. Ale jste první, kdo netrefil ani název.

Jo ja jsem taky konzervativni a kdyz sleduju jak ty nove jazyky nastupuji jeden za druhym, tak mam pocit ze se to lidi ani nestaci naucit, tim min v tom pracovat (coz chce praxi, nejlepe letitou). Zachovani kompatibility je pro me taky docela dulezita vlastnost.

Na tom něco je, mnozí v nových jazycích píšou hrozně, částečně možná proto, že na školách se jede většinou akorát C++ a/nebo Java. Ty novější se lidi většinou učí až při práci na projektech v praxi, a pokud v týmu není nikdo, kdo jazyk pořádně umí a ostatní de facto učí, je to bída.

Blbý je, že se nedá poznat, jestli ten jazyk má budoucnost, nebo ho korporát časem sám opustí... Proto tyhle korporátní jazyky víceméně ignoruju.

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).

Jenže v Go a Rustu se to už ustálilo a stejně je to pořád bída. Carbon si bude muset nějakých 10 let počkat, pokud se tedy uchytí.

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.

Tak oni si to asi píší hlavně pro sebe. Podobně jako Go to prostě bude otevřené pro kohokoliv. Go mělo tu výhodu, že tehdy nemělo ve své doméně silnou konkurenci. Teď je Carbon ve fázi “beru na vědomí, podívám se znova za rok dva”.

Jaký jiný jazyk než Rust (se zavřenýma očima Go) jsi během těch třiceti let viděl vzniknout, který aspiroval na to nahradit C++ ?

Java to kdysi dávno také měla jako deklarovaný cíl.

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#

Žádný GC jazyk nikdy nenahradí C++

Jinak je zajímavé, že to hlásá interoperabilitu s C++, ale nemá to ani ekvivalent size_t.

Pokud se pamatuju, size_t je jenom alias na unsigned long, nebo něco podobného, ne?

24. 7. 2022, 13:22 editováno autorem komentáře

Podle platformy je to alias na unsigned long, unsigned long long nebo i něco jiného. Psát přenositelný kód přímo s inty a longy se moc nedá.

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.

Na to, že má Go své ABI a GC, není interoperabilita s C zas tak špatná. Ale téměř ve všech projektech vidím, že se Cgo zakazuje (kvůli Dockeru).

Rust má dobrou interoperabilitu s C. C++ nijak zvlášť.

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é.

To je v C++ peklo, ale různé druhy ambiguity mají i jiné jazyky (například Go), tam to ale při parsování ignorují a řeší až v rámci sémantické analýzy — to pak člověk občas zírá, co se bez keců přeloží. Jenže Go jde ve více záležitostech vlastní cestou.

Tak mne sa napríklad veľmi pozdáva fn, hoci namiesto var by som radšej videl let.

Funkcia je v modernom programovaní tak dôležitá entita, že si zaslúži svoj špecifický identifikátor. Na rozdiel od C/C++, kde to bol pôvodne iba akýsi organizátor kódu.

Let jsem tam v dokumentaci taky zahlédl. Mít co nejjednodušší způsob jak dělat neměnné věci mi přijde hodně rozumné.

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.

No nevim, skoly nemam, ale co se tyce te nemennosti ABI, to by jako nestacilo pridat uplne novou regex knihovnu a ten stary zprasek tam nechat jako deprecated?

Java to dela bezne a ze bylo potreba povyhazovat sakra nanos stareho hnoje.

Viz java.io vs java.nio
Vyhozeni javax

Částečně to samozřejmě dělají. Ale vzhledem k tomu, jak hluboko některé jsou, by to bylo tak na celou novou standardní knihovnu.

Myslím si, že než vymýšlet nový jazyk, bylo by užitečnější jít cestou modifikací C++, klidně nestandardních rozšíření kompilátoru, nemusí být hned vše ve standardu. Jenže reakcí na oznámení takového projektu by pak nebyl plný Internet a přes 100 komentářů tady na Rootu...

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".

Jo, sběř na Rootu o tom rozhodne :)

Jinak těch nestandardních rozšíření překladače už máme až až.

K doplnění, už se držkuje :) https://www.techtarget.com/searchsoftwarequality/news/252523183/Shadow-cast-over-future-of-Googles-C-replacement

"Hmm, zajímavé, pochybujem" a spousta nudné omáčky aby se vešli do počtu slov. :-D

Jako většina článků :)