Microsoft pracuje na novém programovacím jazyce pro systémové programování

Tohle nemá nic do činění s transparentností.

Prostě se tomu musí přizpůsobit datové struktury, tím pádem i algoritmy atd. V důsledku to je pro programátora stejné jako momentálně v C++.

Ne, datové struktury a algoritmy zůstanou úplně stejné. Neexistuje algoritmus, který by se kvůli tomu musel nějak měnit.

class A { A * p; A() {p = this;}};
while(true) { new A(); }

Na tomto programu RC alokátoru dojde paměť, tracing GC to v O(1) vyhodnotí jako volnou paměť.

Můžeš argumentovat, že to optimalizátor prokoukne, v tom případě tě mohu ujistit, že na každý optimalizátor lze najít algoritmus, kde to selže. A samozřejmě čím složitější data a algoritmus, tím hůř se to bude programátorovi hlídat (a hlídat to musí vždy).

Tento kód v Rustu nejde přeložit, nelze vytvořit referenci na sebe sama. C++ sem netahej, nemá borrow checker.

On neví, co je borrow checker.

Rust vypadává už na tom, že se tomu musí programátor výrazně přizpůsobit.

Co to je za blbost? Tady bude čítač nula a hned se zavolá deinit i při naivní implementaci. Fakt si nejdřív RC nastuduj.

Naivní RC zvedne při přiřazení čítač o 1. Dále viz předchozí příspěvek.

Tak si ten svůj nesmysl pusť třeba ve Swiftu, ať vidíš, žes jen blábolil.

No ještě trochu jinak jsem to myslel já. Když navrhnu data a algoritmus, tak tam žádný koncept vlastnictví není potřeba. Je to nutné vymyslet až ve chvíli, kdy se to má implementovat v jazyce, který bez toho nedovede spravovat paměť. Ale programátoři jsou tak vycvičení, že si tento posun ani neuvědomují a automaticky a skrytě ten trasovací GC zakomponují do svého řešení. U jednoduchých problémů se to tak neprojeví, ale já se dost zabývám grafovými úlohami a tam to jsem nucen řešit pořád dokola.

To není jen dojem, to je fakt. Nicméně i "jednoduché věci" můžou být pro někoho nepřekonatelnou překážkou.

Nebo tomu rozumí a místo vymýšlení kravin použije weak reference.

Ono je samozřejmě víc způsobů jak to omezení obejít.

Stejně jako je více způsobů jak obejít omezení tracing GC. Akorát tím, že jste na ně zvyklý, tak už je ani nevnímáte. Úplně stejně my nevnímáme důsledky počítání referencí, protože je to trivialita.

Weak reference můžete použít tak v nějaké pomocné technické struktuře, např. cachei, kdežto model obsahuje významové, modelované vztahy, takže na ně asi těžko budete moci použít slabý odkaz!
Zde jste naopak ukázal, že tomu nerozumíte.

Zajímavé, jak si kdejaký lepič kódu myslí, že technikality jako slabé reference nějak souvisí s modelováním.

SB : Ale kdepak. Modelované vztahy neříkají nic o tom, jestli mají být udělané silnou nebo slabou referencí. To je implementační detail.
Ty modelované objekty málokdy musí existovat ve vzduchoprázdnu aby je musel udržovat při životě jakýkoliv odkaz na ně. Když existují v kontextu nějakého "světa" nebo něco podobného (graf, ...), tak není problém mít řetěz silných referencí, které je udržují naživu. A zbytek významových vazeb můžou být slabé odkazy.

Nevím, jestli tomu rozumím. Každopádně to naprosto běžné používám a není s tím sebemenší problém.

On ten prvotní problém je, že někteří naivové chtějí modelovat svět programovacím jazykem. To mohla být před půl stoletím zajímavá myšlenka v kontextu OOP, jenže se neosvědčila a dnes jde o těžký anachronismus. Lpění na starých nefunkčních myšlenkách a konceptech je znakem ignorantství (v tom lepším případě).

A to zatím nebylo zmíněno, že slabé reference se používají i s tracing GC.

Havel:
Přeloženo: Musíte vytvořit a udržovat další strukturu, která bude realizovat silné vazby, přestože vůbec nemusí být potřeba, jenom proto, že VM něco neumí.

Ta struktura tam stejně bude. I v trasovaných jazycích obvykle nebude např. graf jen ad-hoc hromada objektů pro uzly a hrany, ale bude tam i objekt pro graf, ze kterého bude přístup na všechny uzly a hrany toho grafu.

Trasované jazyky zase neumí jiné věci. Třeba je problém s nedeterministickým úklidem. Sockety, soubory a podobné věci nemůže uklízet GC, protože nesmí zůstat viset. Takže tam bude muset být velmi podobná další struktura, přes kterou se jedním voláním proleze a uklidí celý ten graf.

Vždycky budou potřeba nějaké další struktury, které řeší implementační detaily a to bez ohledu na jazyk nebo prostředí. A to jenom proto že každé VM může umět jen omezenou množinu vzájemně kompatibilních věcí.

> ale bude tam i objekt pro graf, ze kterého bude přístup na všechny uzly a hrany toho grafu.

No právě že tam být nemusí pokud není vyžadován přímo algoritmem. O tom celou dobu mluvím. Tohle jsou právě ty případy, kdy je řešení úlohy ovlivněno potřebou po sobě uklidit, protože nemá trasovací GC a tyto praktiky pak programátoři tahají i tam, kde to není třeba (a ani si toho nevšimnou, že dělají něco zbytečné až škodlivé).

Zdroje jako soubory a sockety lze většinou snadno uvolnit deterministicky. V jazycích jako C++ je to spojeno s uvolňováním paměti, protože se tam uklízí deterministicky vše, ale to neznamená, že by to existence GC nějak zesložiťovala. Ještě jsem nenarazil na situaci, kdy bych se nedeterministickému úklidu musel nějak přizpůsobovat. Snad před 20 lety, když bylo paměti málo a bylo to pomalé.

Ještě si dovolím poznámku - mluvíme o úklidu paměti u trasovacích GC, ale to je poněkud zavádějící pohled. Pro pochopení celého paradigmatu je dobré nahlédnout, že to ve skutečnosti předstírá prostředí, kde je k dispozici nekonečné množství paměti (jak je toho dosaženo lze brát jako implementační detail). V takovém prostředí se nutně zjednoduší celý návrh dat a algoritmů, protože s nekonečným množstvím paměti odpadá spousta starostí :-) Dnešním GC takový přístup navíc mnohem lépe "chutná". Pokud se narazí na problémy s výkonem, tak to lze řešit jako jakoukoli jinou optimalizaci (čili ne slepě a předčasně).

> Ještě jsem nenarazil na situaci, kdy bych se nedeterministickému úklidu musel nějak přizpůsobovat. Snad před 20 lety, když bylo paměti málo a bylo to pomalé.

Ono nejde až tak o uvolňování paměti. Uzavření socketu nebo souboru je uvolnění jiného zdroje a v neposlední řadě má typicky i další dopady. Nebylo by dobré nechat otevřený socket nebo soubor, jen proto, že mám dost paměti. U zámku (který na Windows k otevřeným souborům dostaneme automaticky) je to ještě zřejmější.

V neposlední řadě tu jsou případy, které sama o sobě neřeší ani deterministická dealokace. Mějme nějaký datový model a nějaké GUIčko, které si v datovém modelu zaregistruje listenery. GUIčko ukončíme (může jít jen o zavření jednoho okna). Pokud si to nepohlídáme, zůstanou nám listenery v modelu, a tím i samotné GUIčko v paměti. Co hůř, nemáme jen nepořádek v paměti, ale s každým updatem modelu updatujeme nepotřebnou instanci GUIčka, což nás stojí čas CPU. Lze to sice „vyřešit“ pomocí slabých referencí, ale to je jen částečné řešení. Bude-li dost paměti, může tento nepořádek zabíjet CPU ještě dlouho před tím, než zaberou slabé reference. Jednoduše, garbage collectory jsou určeny k tomu, aby řešily paměť, ale těžko mohou počítat s dalšími dopady, jako je dopad na CPU. Dokonce to může s trochou heuristik fungovat naopak – můžeme se snažit GC spouštět jen v případě nízké zátěže CPU (samozřejmě někdy to nevyjde), pak to bude zátěž CPU jen oddalovat.

Dobrý konzervativní tracing GC měl Apple ve svém dynamickém runtimu, ale pak ho nahradili novým ARC.