Vlákno názorů k článku
Úvahy o Borrow Checkeru pro C++ od Ink - RIIR!

[KubaV]
Psal jste, ze je lepsi (levnejsi) nez testovani, kdyz chyby ve zprave pameti odhali uz prekladac. Je tvrdim, ze podle me je nejlepsi (a nejlevnejsi), kdyz se na zpravu pameti mysli uz od zacatku, behem celeho procesu vyvoje a rozhodne se nespoleha jen na techniky prekladace. Jinak receno, i kdyby byl nakrasne borrow checker v kompilatoru implementovan, rozhodne bych radne testovani uniku a chyb pameti nepodcenoval.

A co mi na tom vadi? Obecne - kdyz se na to ptate, vadi mi hned nekolik veci:

Jedna je, ze posledni dobou mi prijde, ze Rust fans se snazi vschno ohybat podle svych modelu a predstav a ty vsem potom vnucovat. Skoro to pripomina nabozensky tazeni: Stare svatyne rozvratit, vypalit, pozabijet kneze a upalit, ty kteri nehodlaji konvertovat. A na dobitem spalenisti pak postavit svuj vlastni kostel....

Druha vec - jak jsem psal vyse - nechci nekompatibilni zmeny ve standardech. Pracuji s C++ protoze ho mam rad takovy jaky je, a jsem velmi vdecny tvurcum C++ standardu, ze mysli na jejich plnou zpetnou kompatibilitu. A byl bych rad, aby to tak zustalo. Kdybych chtel neco jinyho, budu se venovat tomu.

Myslim, ze jsem toleratni v tom smyslu, ze necham na zvazeni kazdeho, co je pro nej a jeho projekt dobre. At laskave tohle pravo dopreji ostatni i dalsim, vcetne me a prestanou nam vnucovat co je "lepsi".

25. 9. 2021, 23:08 editováno autorem komentáře

[KubaV]
Klidne at se technologie vyvijeji, ale at se nestvou do kam je nikdo nezve. Nekteri lide, maji totiz neodbytny pocit, ze oni maji tu jedinou spravnou technologii a musi ji necpat kazdymu - at uz o to stoji ci ne.

A ano, samozrejme ze to beru hodne osobne. Vlastne zacinam byt na takove lidi dost alergicky a zacina mi byt z nich zle. A to neni jen Rust.

[KubaV]
Jiste, typicke. Pokus s Vami clovek nekejve jak osel, tak je zraly na cvokhaus. Proste sektari : krasne opisujete vzor ktery jsem popsal - ty co nemini konvertovat je potreba upalit. ;)

26. 9. 2021, 21:39 editováno autorem komentáře

[KubaV]
Ale ja nemam nic proti vyvoji IT. Kdyz uz jsi tak skvele cetl ten muj prispevek, divim se ze muzes takovou hloupost vypustit z klavesnice. Me vadi neustale vmesovani a vnucovani nejruznejsi techno-it nadsencu - zde zrovna rust fans - tam kde o to nikdo nestoji a jejich temer sektarsky postoj.

To se dá snadno ignorovat. Na druhou stranu není na škodu trochu se s novými jazyky (Swift, Go, Rust, ...) seznámit. Člověk nemusí hned měnit kariéru, jednoduše to rozšíří rozhled a někdy v (blízké) budoucnosti se to může hodit.

Mně takhle okolo roku 2000 vnucovali Javu. Dlouho jsem odolával, a pak jsem najednou musel psát něco pro Lotus Notes, kde byla na výběr Java a LotusScript (přejmenovaný Visual Basic). A už byla motivace.

[Calculon]
"Na druhou stranu není na škodu trochu se s novými jazyky (Swift, Go, Rust, ...) seznámit..."

Jo, proti tomu samozrejme nic nenamitam. Ja to mel podobne s C# .

26. 9. 2021, 23:11 editováno autorem komentáře

Jenže tady je právě zve. Jsou to vývojáři Chromu, co se zajímají o Rust, ne, že by se Rusťáci rozhodli se za každou cenu zmocnit Chromu.

[klokan]
Ano, to je pravda, nejak to v toku vzajemnych dojmu, uvach nazoru a protinazoru zaniklo. Ale zas na druhou stranu, ...

Na druhou stranu co? Jestli vám tolik sejde na tom, že prohlížeč musí být jedině v C++, tak si ho forkněte a dál si ho vyvíjejte podle svého. Máte na to právo. Upstream vývojářům připadá, že by chtěli se nemuset stále dokola zabývat jistými problémy a hledají na to řešení. Třeba se vám to nelíbí, třeba byste chtěl, aby dál ztráceli čas debugováním pádů a záplatováním zbytečných bezpečnostních děr, ale jenom vám pro radost to dělat nebudou.

Ten clanok sa ale zaobera tym ci by bolo mozne do C++ implementovat BC tak ako to ma rust. Mate nejaky odkaz kde sa pise ze cely projekt prepisu do rustu? Myslim ze ziadny fork nebude treba...

Pokud vím, přepisování Chromu do Rustu nikdo nechystá, ale když někomu vadí, že schopnosti statické analýzy se od 80. let poněkud posunuly a že to někdo chce nedej bože i používat, tak takový člověk bude asi nešťastný i z takovéhoto článku - a zřejmě taky je, soudě dle příspěvků.

Takze ako oznacit vas vyrok, citujem: Jestli vám tolik sejde na tom, že prohlížeč musí být jedině v C++, tak si ho forkněte a dál si ho vyvíjejte podle svého. Máte na to právo. Zavadzanie, nepochopenie, nepozornost? Aky checker zlyhal?

27. 9. 2021, 01:46 editováno autorem komentáře

Nemyslel jsem tím vás, ale jiné příspěvky výše.

Jj, ja si zvesa precitam aj prispevky vyssie aby som sa dostal do kontextu. Ono je to celkom dobrym zvykom sa spytat pri zapojeni do diskusie o com sa toci, alebo si moze jednoducho precitat komentare vyssie. Moze sa potom vyjadrit k veci.

Kontext vasej poznamky mi v suvislosti jak so spravickou, tak s diskusiou stale akosi unika...

[klokan]
Kde jsem presne napsal neco o tom, ze mam problem s tim ze prevedou ten zatracenej prolizet do jinyho jazyka? Umis doprcic cist? Celou dobu sakra pisu, ze by mi vadili pripadne zpetne nekomptibilni zmeny ve standardech jazyka C++. O tom co maji nebo nemaji delat vyvojari v Google se s svym projektem jsem ani nepiskl. V podstate me to ani nezajima.

A ta narazka "na duhou stranu" mela znamenat, ze to ze se tahle (a dalsi) diskuze takhle zvrtne si tak trochu muzou rust hateri sami. Trebaze v tom tentokrat byli aspon ze zacatku nevinne.

28. 9. 2021, 17:50 editováno autorem komentáře

Ono jde asi hlavně o zpětnou kompatibilitu. Nikdo skutečně nechce zažít situaci, že se aktualizuje překladač a najednou program nefunguje a musí se radikálně překopávat. Obětování zpětné kompatibility a nasazení nových konceptů do překladače před pár lety zkusili v Mozille, vydali to a nazvali to Rust :)

Mě naopak připadá, že C++ zkompiluje absolutně cokoli a pak to (většinou) dělá psí kusy při běhu.

Před lety jsem dělal v R&D v jisté velké, známé firmě, na statickém analyzátoru kódu pro C/C++ - něco jako Coverity, Fortify apod, ale byl to interní projekt určený pro vývojáře produktů té firmy. Doba strávená vývojem algoritmů na analyzování C++ programů mě naučila, že kód v C++ (psaný čistě, striktně v "moderním" C++ atd) může být podělaný způsobem, jaký bych si v živote vůbec nebyl dokázal představit. Zároveň mě to dovedlo k dojmu, že C++ je v podstatě nespasitelné - jakékoli vylepšení umožní se některým problémům lépe vyhýbat, ale ne je vyřešit. Nakonec totéž tvrdí i známý článek "Modern C++ Won't Save Us".

C je jiná story. Má sice řadu vlastností, které se zpětně ukázaly jako špatné (preprocesor, řetězce zakončené nulou...), ale je nutné si uvědomit, že jeho vznik byl podřízený dvěma cílům: aby bylo efektivní na architektuře PDP-11, a aby bylo snadné pro něj napsat překladač. Připadá mi, že dodnes má smysl, mj. protože je snadné vidět "zkrz" kód v C a představit si, co to generuje v assembleru. V některých případech je to důležité a nedocenitelné. V Rustu to alespoň já tak dobře nedokážu, je to přece jenom mnohem abstraktnější jazyk. Což je někdy obrovská výhoda a jindy zase nevýhoda.

C++ je skutečně občas zákeřné. Mně sice většinou stačí něco s GC, ale když jsou požadavky přísnější, tak taky radši upřednostním Rust, na C++ už nemám nervy.

V mnoha případech je GC jazyk správnou volbou, ale pak jsou situace, kde GC použít nelze (RT problémy, low-level systémové programování atd) a tam dostává slovo Rust.

[Calculon]
"GC to řeší. Jakmile se v tom někdo hrabe už v době návrhu, dopadne to jako původní MSIE blahé paměti."

Jako jo, uznavam, ze vzit se to da za spatny konec vzdycky, ale nedelal bych z toho uplne ... jak to rict ... pravidlo?

IMHO ve velké aplikaci správa paměti moc plánovat nejde, je to prostě chaos (byť deterministický). Pomůže buď kvalitní tracing GC, nebo překladač, který si to ohlídá (v C++ move a případně chytré pointry).

Přesně tak to funguje. Jen se vylévá automaticky.

ondra05: GC ale funguje jinak. GC nedělá to, že by paměť nechávalo unikat a pak se ji pokoušelo sbírat. GC automaticky sleduje paměť, která se přestává používat. Mimochodem, i s GC jde vyrobit únik paměti – kdyby to byl automaticky vylévaný kbelík, při vylití by se ten únik odstranil.

Každá metafora kulhá. Kolega nejspíš narážel na fakt, že v případě tracing GC zůstává v paměti spousta nedosažitelných objektů, které se jednou za čas odstraní a tím “zbytečně” zabranou paměť uvolní. To je to “vylití”. Dosažitelné objekty ve kbelíku nejsou.

Jednak jsou různé typy GC. Jednak ta metafora kulhá především v přirovnání k netěsnícímu potrubí. Netěsnící potrubí je závada, nevíte kde netěsní, situace se často v průběhu času zhoršuje. GC je naproti tomu řízený proces.

Jo, a taky kulhá tím, že ne všechny GC jsou tracing, třeba RC žádný kbelík nemá, odpad leje přímo do kanálu. Prostě kulhá na všechny nohy…

RC je GC přímo z definice, je to prostě jedna z variant. Má spoustu podvariant, klidně to může dělat překladač transparentně. Taky existuje distribuované RC (pro vzdálené objekty přes síť), představivosti se meze nekladou.

A pravidelne vylevani kybliku neni rizene ? :D

Me vsak fascinuje jina vec: Zrovna v C++ podpora GC se nezahrnuje v prubehu navrhu projektu? Chytre ukazatele take ne?

26. 9. 2021, 21:03 editováno autorem komentáře

Samozřejmě jsem myslel nezkompiluje

Jsem osobně všemi deseti pro ruční správu paměti, když překladač zajistí bezpečnost, ale zrovna Rust má ten problém, že jakmile jsou v aplikaci složité hierarchie objektů na haldě, je alokace pomalá a musí se ladit konfigurace (alokátor). Na to jsem narazil u všech netriviálních projektů a samotný překladač Rustu je taky “potuněný”.

Nicméně na proškolení namyšlených javistů je Rust ideální (kolega tomu říká “buzerace překladačem”).

[klokan]
" Nevím, co tím autor doopravdy myslel, pravděpodobně ono klišé "Rewrite It In Rust"."

Ja to pochopil uplne stejne.

Pokud o vtip byla i moje interpretace :) Co tak občas pozoruju, mnohé týmy následují heslo “rewrite it first in Go, then in Rust”…

Tak s tím jsem se ještě nesetkal, za to jsem už párkrát viděl Rewrite it in C++, then in C++, then in C++, then in Rust.

Taky dobrý :) Tu trajektorii Go->Rust zvolil například následník node.js, tuším se jmenuje Deno.

Zajímavý. Psát interpret v Go by mě teda nikdy nenapadlo.

To asi nebyl interpret, pro JS používají V8, ale celá ta síťová vrstva byla nejdříve v C (node.js) a pak ji přepsali do Go (beta verze Deno). Jenže někdo si pak všimnul, že najednou tam mají dva tracing GC (JS a Go), tak ten kód v Go přepsali do Rustu.

No jasně, že přepsat do Rustu. Dnes existuje dogma, že napsat znovu browser je nemožné, což mi přijde jako dost bídná situace. Každopádně, kdyby se něco podobného Google odvážil udělat, rozhodně mi přijde lepší napsat to přímo v Rustu, než dělat z C++ Rust. A fakt mě štve, jak se "oxidace" Firefoxu zadrhla, protože jsem doufal, že jim to postupně vyjde.

Napsat nový prohlížeč jistě není nemožné, ale přepsat již existující do jiného jazyka by byla obludná práce, navíc to není samostatný projekt ale integrace několika různých projektů (interpret JS, interpret WASM, vykreslovací jádro HTML, CSS engine, grafický engine, 3D engine, implementace síťových protokolů, podpora všemožných kodeků a formátů atd), kde mnohý z nich je sám o sobě nesmírně komplexní software. Takže přepisovat to nikdo nebude, jako nikdo nebude přepisovat celý kernel Linux.

Z C++ asi Rust neudělají, ale do Swiftu proniká jím inspirovaná statická analýza alokací a referencí na objekty na haldě.