Vlákno názorů k článku
Carbon: nový jazyk od Googlu má být nástupcem C++ od linuxák - Tady je zajímavý kontext, proč to Google udělal...

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.