Vlákno názorů k článku
Zemřel Brad Cox, tvůrce programovacího jazyka Objective-C od klokan - Objective C byla podle mne mnohem lepší vize...

Možné to je, ale je to demence, když to takhle někdo udělá. Takového programátora bych nezaměstnal. Udělat to zaměstnanec, má vytýkací dopis jasnej.

Jde o to, že jazyk to moc nehlídá. A pokud si to má řešit sám programátor, tak může jet rovnou klidně C pointery. A ne vždy za to může programátor - může jít o spolupráci více programátorů a problém v komunikaci, nebo využívání knihovny od jiného programátora (dokonce nějakého, který není váš zaměstnanec).

Jenže za prvé vyhnout se tomu doopravdy je mnohem složitější, než by si člověk myslel. Před pár lety jsem pracoval na statickém analyzátoru C++ kódu a nevidět to na vlastní oči formou dataflow rovnic, v životě bych si nebyl dokázal představit, jaké svinstvo může být i zdánlivě banální kód v C++. A to nemluvím o tom, jak často člověk spoléhá na undefined chování aniž by si to vůbec uvědomil a program funguje v podstatě čirou náhodou.

Hlavní problém ale vůbec není, jestli to je nebo není demence. Problém je v tom, že v C++ to v obecném případě nejde matematicky prokázat. Takže reálným řešením je buď GC, nebo statická prokazatelnost zadrátovaná přímo do jazyka jako v Rustu.

Nepřijatelné jak v čem. Pro RT je to evidentně nepřijatelné. Pro desktopové aplikace je to naopak výborné.

Jak který real time (soft vs hard). Myslím, že právě třeba v Drážďanech nějak ukazovali, že lze prakticky používat hard i soft real time na stejném stroji s jedním OS, lze virtualizovat a jistě lze i spouštět něco s GC - jen to holt musí být asi real time aware GC.
Další aspekt je, že GC může běžet tzv. na dluh. Program se prostě po nějaké době restartuje a tím pádem GC vlastně nikdy neproběhne. To se snad používá nebo používalo ve finančním sektoru, kde se některé kritické systémy psaly v Javě a bylo nutné, aby to fungovalo jen v obchodních hodinách na burze... přes noc si "GC" mohl klidně uklízet. :-)

> GC narušuje běh programu a to je nepřijatelné

Až se děsím, jak vůbec lidstvo může fungovat s takovým množstvím nepřijatelného kódu.

A proc je GC neprijatelne?
Od dob multicore CPU osobne nemam s GC zadny problem, nijak me neomezuje.

Je mozne ze to nekdo ma jinak, u RT kodu urcite, ale jake ze jsou ty realne duvody, proc GC nee?

https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

https://twitter.com/_rsc/status/1224802727773065221?lang=en

OK, jestli s tím výrazně pohnuli, tím líp. Ale vzhledem k tomu, že ten blog post tvrdí, že si s tím hráli docela důkladně, divil bych se, kdyby nezkoušeli aktuální verzi v době, kdy to řešili (což nemusí být nutně čas publikace blog postu).

Zřejmě nezkoušeli. Ale v tomto případě je Rust evidentně lepší volba. Rust už dospěl a co se týče správy paměti, převyšuje jazyky s tracing GC, Go nevyjímaje.

Nemyslím, že je "převyšuje". Jasně převyšuje ostatní jazyky bez GC (C/C++ apod), pokud jde o GC jazyky, má dost jinou filozofii a z hlediska jednoduchosti použití a programátorské "produktivity" je např. Go jasně lepší.

To ano, pro vývojáře je jednodušší. To je příklad toho, že technická sofistikovanost a jednoduchost pro vývojáře jsou spojené nádoby. Proto taky vzniká tolik flamewarů, lidi si vyberou nějaký aspekt, který obhajují, a ostatní zatracují.

Tak ono opravdu není nutné z toho dělat flamewary. Nejsou to spojené nádoby, jsou to dvě naprosto odlišná řešení daného problému a obě mají své opodstatnění, i svá ideální pole využití.

Vždycky budete řešit tu hranici, kde existuje formální definice vynucená jazykem a definice, kterou si určil člověk.

Asi tak jako když v programu budu mít proměnou, která se jmenuje counter a v nějaké iteraci ho předělám na weight a dám mu typ float. Když ho nepřejmenuju, tak jsem teď porušil svou vlastní definici a jednoho dne se mi to šeredně nevyplatí.

To je to samý jako elektrikáři. Taky se dá zásuvka zapojit různě a neexistuje systém, který by matematicky spočítal, že mám zapojený barák dobře a nevyhořím. Proto se dodržují nějaké normy, třeba že černá je fáze, modrá je pracovní vodič a žlutozelená je nulák. Když tohle poruším, jsem dement a o požár si koleduju, nebo o to, že budu mít na svědomí elektrikáře, který to půjde zapojovat po mně

> Takového programátora bych nezaměstnal

To jsou ale silácké řeči. Co když je to nejlepší možný kompromis?

Není!

Unique je unique. Pokud někdo používá unique jinak, ať použije něco jiného. Je to o tom, že narušuje to, k čemu ta věci je určena.

Ano, plochým šroubovákem lze odšroubovat křížový šroub, ale mít takového profesionála v teamu, který takhle šroubuje většinu šroubů, tak ho vyrazím.

Unique není unique, v tom to je. Kód, kde "unique" vůbec unique není, vezme jakýkoli moderní překladač, aniž by hnul brvou a tudíž to není problém kodéra. Je to stejné, jako kdyby "špatný programátor" používal bool, který klidně může mít i jiné hodnoty, než true a false, nebo "špatný řidič" sešlápl brzdový pedál, který nemusí nutně sevřít brzdy, ale místo toho klidně třeba někdy zapne blinkry a jindy pro změnu ovládá ruční brzdu.

Problém je v jazyku. C++ je od začátku nedomyšlený, katastrofálně špatně navržený jazyk s nedostatečně definovanou sémantikou a k tomu "vylepšený" frankeinsteinskou akumulací featur, které se snaží problémy nikoli řešit, ale přeplácat, přičemž v mnoha případech prostě vůbec nefungují ani samy o sobě (viz např. koncepty v C++20 nebo právě ten unique). Natož dohromady.

Když to neumíte používat...

Tak jako všechno ostatní, je to nástroj. Ne víra.

Nejde ani o nástroj ani o víru, ale o prokazatelnost. Tvrzení, že něco "umíte používat" ke mi k ničemu, pokud není možné provést důkaz.

Co chceš pořád dokazovat? C++ je nízkoúrovňový jazyk co poskytuje vysokoúrovňové konstrukce a zero-cost abstraction. To je to nejdůležitější - nízkoúrovňové věci obalit a používat tak, aby to neprosakovalo dál. Dokazovatelnost nic neřeší, se podívej kolik unsafe kódu je v Rust knihovnách. Rust má unsafe explicitně, C++ implicitně.

C++ není určitě na všechny projekty, ale jako jazyk tu bude ještě hodně dlouho a diskuze na rootu to nezmění :)

Zero cost abstraction nijak neodporuje prokazatelnosti, právě naopak. Např. v Rustu díky prokazatelnosti si u pointerů překladač sám odvodí ekvivalent atributů noalias, restrict, volatile apod, což umožňuje lépe optimalizovat kód. Zvlášť při monomorfizaci generických funkcí to má někdy podstatný vliv.

A právě u nízkoúrovňového kódu je ta prokazatelnost extrémně důležitá. Když se zamíchají pointery a dojde k use after free apod. v uživatelské aplikaci, tak v nejhorším případě spadne proces. Je to jistě nepříjemné, ale když k tomu dojde na úrovni jaderného ovladače, může se např. zkorumpovat celý souborový systém. Kdybych někdy nedej bože potřeboval kardiostimulátor, budu mnohem radši, když jeho mikrokontrolér bude řídit prokázaný kód spíš než kód, který psal nějaký Re4l pr0gramM3r co o sobě tvrdí, že to "umí používat".

V rustových knihovnách je spousta unsafe kódu tam, kde to volá knihovny v C. Jinak se v Rustu člověk s unsafe občas setkává u SIMD kódu a jinak v naprosto výjimečných případech. C++ nemá unsafe "implicitně", ve skutečnosti C++ vůbec nemá safe.

Tento týpek vysvětluje FP z trošku jiného pohledu. Je tedy trošku rozvláčnej, ale uvidíme, kam nakonec po pár živých přednáškách dojde (po několika iteracích si to trošku líp uspořádá): https://lispcast.com/

Má dost zajímavé články.

> C++ hlavně uměl vždycky nabalovat. To, že něco pořád přidává věci odjinud a zesložiťuje je ukázka scházejícího designu.

Došel jsem ke stejnému závěru. C++ je z podstaty nespravitelné a vývoj posledních let to jen dokazuje. Na papíře to vypadá, jakoby to bylo konečně lepší, ale ve skutečnosti je to jen složitější (způsobů jak někam poslat objekt už je snad 10).
V zásadě se dá říci, že když jazyk nemá GC, tak používá jen jinou formu obskurnosti jak to obejít (staré C++ se s tím vlastně vypořádalo celkem dobře) a nevypadá to, že by od té doby byla přijatelná náhrada.

Mně přijde Rust v tomhle úplně v pohodě. Z pohledu programátora se nic moc nemění, ale výsledek je lepší, než u GC.

Máte pravdu těch možností je v C++ více, je to daň za zpětnou kompatibilitu. A komunitní řízení rozvoje jazyka. Už zde ten odkaz byl, ale Bjarne (autor prvních návrhů C++) o tom napsal hezký článek (spíše knihu) https://www.stroustrup.com/hopl20main-p5-p-bfc9cd4--final.pdf

Pro psaní jakéhosi čistého C++ je nutné aplikovat guidelines např. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
Netvrdím, že je to dokonalé, zcela jistě najdete nějaké mezní případy, kdy lze prasit i za použití těchto doporučení, nebo naopak co nejde, pokud to dodržíte... ale je to jakýsi soupis best practice, které snižují riziko obtížně odhalitelné chyby a zvyšují přehlednost a udržitelnost kódu.

Je trochu nešťastné, že na úrovni překladače nejsou tyto záležitosti vymahatelné, např. nějakým přepínačem vypnout zpětnou kompatibilitu s prasáckým psaním tak, aby to nebylo možné.

Ale existují i nástroje, které napomohou dodržování tohoto vymáhat (statické analyzátory). VS na to má knihovnu, clang-tidy má také nějaké možnosti to kontrolovat.

Tedy ano C++ toho umožňuje mnoho bariéra používat dobře C++ je někde jinde než u jiných (zpravidla novějších) jazyků, ale je univerzální a má své využití.