Dlaczego programiści C++ mają alergię na termin Garbage Collector?

Cześć,

Czytając czy słuchając różnych wypowiedzi programistów języka C++ odnoszę nieodparte wrażenie, że środowisko to ma poważną alergię na termin Garbage Collector. Do tego stopnia, że zliczanie referencji wyrzuciło poza nawias strategii odśmiecania, aby tylko z terminem odśmiecania nie mieć nic wspólnego. Trochę to śmieszne a trochę straszne, bo śledzone wskaźniki pomagają w rozwiązywaniu niektórych problemów, więc jako opcjonalne lepiej byłoby je mieć niż nie mieć. Zastanawiałem się, czy ta niechęć skierowana jest tylko w odniesieniu do globalnego mechanizmu odśmiecania, analogicznego do tego dostępnego w języku D, ale po obejrzeniu prezentacji Herba Suttera dotyczącej grafów i pomyśle na wskaźnik deferred_ptr dochodzę do wniosku, że niechęć środowiska do potencjalnego mechanizmu odśmiecania jest niezależna od tego, jak taki mechanizm miałby działać.

Co o tym sądzicie?

To nie tak, że mają alergię na GC, tylko tam gdzie jest sens używania C++ najczęściej GC nie ma zbytnio racji bytu (a przynajmniej niedeterministyczny GC). Ref-count jest w pewnym stopniu deterministycznym GC, co jeszcze się mieści w "akceptowalnych ramach". Jak masz możliwość użycia języka z GC, to C++ najczęściej nie będzie miał sensu.

@hauleth:

Prawda.

Skądinąd szkoda, jeden z niewielu jezyków, że mozna podmieniać new jako zestandaryzowany proces bez hakerki.
Widywałem w necie, te i ów podobno zrobił i używał C++ GC, ale to widziene przez ramię.

Ja tam nie mam alergii, ale z reguły GC to dodatkowy kod do wykonywania a nie ma na tyle zasobów, żeby go puszczać.

To dlatego język o idealnej wręcz składni czyli D nie zdobył popularności bo posiadał GC który można było wyłączyć w ekstremalnych sytuacjach skierowanych na szybkość.

Bo kupa stosów ma po 10-20 lat i nikt tego nie będzie przepisywał bo D ma GC. Zobacz na Rust jak powoli się przyjmuje. z resztą w :dużym"(stb, getway itp.) kupa obiektów zwyczajnie istnieje cały czas i tyle.

Sporo dużych systemów napisanych w C++ ma garbage collector. Ot chociażby silniki gier takie jak unreal engine. I często są z tym spore problemy wydajnościowe.

Tak 25 lat temu byłem wielkim miłośnikiem C++ i pisałem w zasadzie tylko z użyciem własnego GC (domowej roboty, okropny RC - ale działał mi ok).
Problem 1 - nie było standardu,
Problem 2 - używanie gc, const Ref, stl, powodowało, że byłem bardziej samotny niż programista funkcyjny w javie.
(od tego czasu troche się C++ zmieniło, ale community jest "rozstrzelone" - od void* do funkcyjnego C++ z kosmicznymi templatami, przynajmniej tak to widać z daleka)

Z tego co rozumiem, dla niedeterministycznych GC znaczącym problememem są destruktory. Java miała finalize(), ale w sumie nie było gwarancji jego użycia, D ma taki zapis:

The garbage collector is not guaranteed to run the destructor for all unreferenced objects. Furthermore, the order in which the garbage collector calls destructors for unreferenced objects is not specified. This means that when the garbage collector calls a destructor for an object of a class that has members which are references to garbage collected objects, those references may no longer be valid. This means that destructors cannot reference sub objects.

W C++ nie do pomyślenia jest aby destruktor obiektu był wykonany inną liczbę razy niż 1, a w czasie jego wykonania obiekt był w innym stanie niż poprawnym do normalnego działania.

Osobiście chętnie bym widział ustandaryzowany sensowny GC w C++, ale patrząc na to, jakim fiaskiem zakończyło się dodanie API GC do C++11 (usunięto kilka standardów później, 0 implementacji), to nie wróżę sukcesu.

dochodzę do wniosku, że niechęć środowiska do potencjalnego mechanizmu odśmiecania jest niezależna od tego, jak taki mechanizm miałby działać

Jeżeli masz na myśli odśmiecanie znane z VMek javy czy .net, które potrafi "zatrzymać świat" to nawet ciężko się dziwić, bo C++ to nie lekkie bzduro apki na desktopie ani jeden z kilku procesów na serwerze, który jak nie wyrabia to zostanie automatycznie ubity i zastąpiony nowym. Wyobrażasz sobie sprzęt medyczny, który się zatrzymuje całkowicie na kilka/kilkanaście sekund, żeby sobie pamięć zwolnić? Albo "autopiloty" w samochodach, można by dodać status dla kierowcy żeby przynajmniej wiedział dlaczego złamał kręgosłup w wypadku breaking will start shorty, please wait... :D

Poza tym taka całkowita niechęć i opór to też nie do końca prawda. Memory Arena czyli idea by zaalokować więcej pamięci na później i pogodzenie się z jakimiś tam wyciekami by nie prosić się systemu o pamięć co chwile to jednak dość popularna technika tam gdzie zasoby na to pozwalają.

@several:

który się zatrzymuje całkowicie na kilka/kilkanaście sekund

ile?? src?

Your GC algorithm has a major influence on the GC pause time. If you are a GC expert or intend to become one (or someone on your team is a GC expert), you can tune GC settings to obtain optimal GC pause time. If you don’t have a lot of GC expertise, then I would recommend using the G1 GC algorithm because of its auto-tuning capability. In G1 GC, you can set the GC pause time goal using the system property ‘-XX:MaxGCPauseMillis.’

WeiXiao napisał(a):

ile?? src?

Your GC algorithm has a major influence on the GC pause time. If you are a GC expert or intend to become one (or someone on your team is a GC expert), you can tune GC settings to obtain optimal GC pause time. If you don’t have a lot of GC expertise, then I would recommend using the G1 GC algorithm because of its auto-tuning capability. In G1 GC, you can set the GC pause time goal using the system property ‘-XX:MaxGCPauseMillis.’

Otóż, kluczowe jest to, że nieważne jak to będzie tuningowane to gwarancji(!!!) nie masz. Większość javowych algorytmów GC (w tym G1GC) niestety ma fazy, które mogą trwać dłużej niż ustawiono i nie da się ich przerwać. Co więcej masz globalny stop the world (więc nawet jakiś krytyczny wątek, który nic nie allokuje, to i tak będzie zatrzymany - na nie wiadomo ile ).
I nawet jak w praktyce to się raczej nie wydarzy to po prostu eliminuje JVM z zasosowań RT (jest więcej takich "braków gwarancji" - w szczególności przy wątkach).
Tu sprawa jest dość zero-jedynkowa - nie masz gwarancji (Hard)RT - to w wielu miejscach nie powinno się stosować danego komponentu (OS, platforma, itp). To, że wiele firmy robi sobie jaja i jedzie na soft RT to inna sprawa (ale może się to źle skończyć).

Jest taki broker Apache Qpid. Ma dwie implementacje, javowską i C++
Kilka lat temu były tam pokorne tłumaczenie się zespołu C++ "przepraszamy, nie jesteśmy tak samo wydajni (throughput) jak javowska"

Moje mniemanie: smart pointery C++ bardziej są związane ze statyczną strukturą np często stosową - GC w stosunku do obiektów młodych, starych i co tam mu dane, w mojej wyobraźni MOŻE być bardziej wydajny akurat w brokerze messagingowym

Nie jestem idiotą, i wiem, czy się różni throughput od wymogów RT - żebyśmy odcięli niepotrzebne polemiki na zbędnych obszarach

podstawową sprawą przy omawianiu odśmiecania jest to, że jest wiele rodzajów gc, jak sami wspomnieliście. jednak dla wielu ludzi termin "gc" jest dokładnie tożsamy z https://en.wikipedia.org/wiki/Tracing_garbage_collection

In computer programming, tracing garbage collection is a form of automatic memory management that consists of determining which objects should be deallocated ("garbage collected") by tracing which objects are reachable by a chain of references from certain "root" objects, and considering the rest as "garbage" and collecting them. Tracing garbage collection is the most common type of garbage collection – so much so that "garbage collection" often refers to tracing garbage collection, rather than other methods such as reference counting – and there are a large number of algorithms used in implementation.

co do wymogów real-time to (poważnie rzecz biorąc) java się do tego nie nadaje, podobnie jak .net, javascript czy inne zarządzane wynalazki. jeśli klepiecie coś prawdziwie real-time to piszcie w ruście, żebym czuł spokój :)

z drugiej strony, w javce robi się https://en.wikipedia.org/wiki/High-frequency_trading czy nawet gry jak minecraft. jak widać nie są to zastosowania na tyle hard real time (czy jak tam to nazwać), żeby wykluczyć javę z tych branż.

@enedil: Jaki widzisz problem w tym, że obiekt będzie przechowywał cokolwiek podczas destrukcji? Nie wiem także jaki jest problem z dereferencją nulla, przecież w destruktorze można sprawdzić czy wskaźnik którego chce się użyć jest pusty. — Pebal 22 minuty temu

Jeszcze raz - załóżmy, że nie ma gwarancji, że destruktor w momencie wywoływania operuje na poprawnym obiekcie - czyli, że jego składowe mogły być już zniszczone. No to są problemy, powiedzmy, że mamy sobie strukturę

struct X { 
    Y* ptr;
    X& ref;
    T value;
};

. Jak zamierzasz

1. wyzerować wskaźnik ptr przy jego destrukcji, wewnątrz obiektu X (do którego w środku Y nie ma wskaźnika na X który na niego wskazuje),
2. wyzerować referencję (w ogóle!)? przecież referencji nie da się nadpisać
3. wyzerować wartość? co to w ogóle znaczy, wyzerować wartość? Czy to by musiało się ograniczać tylko do jakiegoś podzbioru typów?

To oni nie wygineli?

Dziękuję za wasze wypowiedzi.

Podsumowując dyskusję. Głównym argumentem przeciwników GC w języku C++ są problemy z GC w innych językach programowania oraz przekonanie, że w języku C++ da się wszystko zaimplementować bez GC. Co do pierwszego argumentu. Moim zdaniem, problemy z GC w innych językach programowania wynikają głównie z tego, że języki te zostały w większości oparte na mechanizmie GC i bez niego w zasadzie nie funkcjonują. Język C++ nie będzie miał podobnych problemów, gdyż posiada bogaty wachlarz opcji zarządzania zasobami i wskaźniki GC byłyby tylko jedną z wielu dostępnych dla programisty opcji. Co się tyczy drugiego argumentu. Tak, w języku C++ można zaimplementować praktycznie wszystko bez GC. Podobnie jak można zaimplementować wszystko bez wielu rozwiązań, które zostały dodane do języka C++ na przestrzeni ostatnich lat. Obecnie zdarza się jednak, że dla niektórych rozwiązań implementuje się własne mechanizmy GC, podobnie jak kiedyś implementowało się np. zliczanie referencji. Herb Sutter uważa, że wskaźniki GC byłyby w języku C++ przydatne i widziałby je w bibliotece standardowej.

Gdyby ktoś byłby ciekaw, jak takie wskaźniki GC mogłyby działać w języku C++, to zapraszam do repozytorium. Zastosowany mechanizm GC uruchamia się leniwie, więc nie ponosi się żadnych kosztów, gdy się go nie używa. Pracuje w tle w sposób całkowicie bezpauzowy, więc nigdy nie zatrzymuje wątków aplikacji.

Jestem programistą C++ z alergią na GC. Oo moja historia:

Programowałem sobie w różnych wysokopoziomowych językach. Stopniowo zaczęły pojawiać się różne dolegliwości: na początku swędzenie oczu, ale założyłem, że to pewnie zespół suchego oka od zbyt długiego siedzenia przy komputerze; następny był katar i kichanie, dalej pojawił się kaszel, w końcu napady duszności. Badania lekarskie w LuksusMedzie wykluczyły infekcję wirusową lub innym malware'em, internista zlecił testy alergiczne. Podejrzewałem, że źródłem alergenów jest kot, ale okazało się, że jednak kod. Wyszło mi, że mam silną reakcję immunologiczną przy kontakcie z garbage collectorem; lekarz zalecił zmianę języka programowani. Musiałem zrezygnować z pracy, na złagodzenie objawów do końca okresu wypowiedzenia dostałem receptę na leki przeciwhistaminowe. W międzyczasie nauczyłem się nieco C++, jednak ze względu na diametralnie inną branżę i brak doświadczenia w tej technologii zmuszony zostałem do przyjęcia pozycji juniora. W ramach programu odczulania piszę czasami małe skrypty utilsowe w Pythonie; póki co mogę ograniczać się do takich, w których GC zwalnia tylko jedną zmienną. Jeżeli przez najbliższy miesiąc objawy nie nasilą się, zwiększymy rozmiary skryptów do takich, w których dwie zmienne są czyszczone przez GC.

Obiecałem sobie, że będę silny. Wytrwam w tym real time embeddedowym szambie, a jeszcze kiedyś wrócę sobie na ciepłą posadkę klepacza crudów w Javie.

Jaki problem rozwiązuje GC w przypadku używania C++ który nie możesz rozwiązać innym językiem z GC?

Marcin Marcin napisał(a):

Jaki problem rozwiązuje GC w przypadku używania C++ który nie możesz rozwiązać innym językiem z GC?

Widzę dwa.
Pierwsze to oczywistość: chcemy GC ale musimy mieć C/C++, bo w tym języku jest projekt, bo używamy bibliotek, bo team umie ten język, bo krytyczna wydajość jest kluczowa, bo piszemy na platformę, gdzie działa tylko C/C++.

Drugi to możlwość mieszania kodu GC/non-gc (choć tutaj chyba jest też C#). Wiele języków wspierająych GC stanowi dużo ułatwień np. słynne javowe everything is an object, gdzie każdy obiekt jest alokowany na stercie co ułatwia kod (generalnie im mniej przypadków tym lepiej a, że chcemy mieć alokację na stercie to czemu by nie wszystko tam alokować).

Inna sprawa. Istnieje błędne przekowanie, że wszystko da się zrobić, bo czemu nie. Tylko jak popatrzy na języki to nie jest tak kolorowo, wielu kombinacji ficzerów po prostu nie ma albo trzeba wybierać to co się ma. Przykładowo znajdź mi popularny język, gdzie masz zarówno GC i pola w strukturach, gdzie inne pola nie są koniecznie wskaźnikiami (co ma miejsce w podejściu everything is an object). C#? Go? Zgaduję, że ten pierwszy dostał ten ficzer (struktury) w okolicach 2005 co daje nam 35 lat od czasów języka C. Całkiem długo jak na taką oczywistość, która mocno wpływa na wydajność (Java też chce mieć value objecty)

One thing that that I hadn't fully understood until recently is that garbage collectors can actually allow you to write more efficient code.

Previously, I had the general understanding that you were trading convenience (not thinking about memory management or dealing with the related bugs) in exchange for performance (GC slows your program down).

That's still true broadly, but there's an interesting class of algorithms where GC can give you a perf. improvement: immutable data structures, typically used in high-concurrency situations.

Consider a concurrent hash map: when you add a new key, the old revision of the map is left unchanged (so other threads can keep reading from it), and your additions create a new revision. Each revision of the map is immutable, and your "changes" to it are really creating new, immutable copies (with tricks, to stay efficient).

These data structures are great for concurrent performance, but there's a problem: how do you know when to clean up the memory? That is: how do you know when all users are done with the old revisions, and they should be freed?

Using something like a reference count adds contention to this high-concurrency data structure, slowing it down. Threads have to fight over updating that counter, so you have now introduced shared mutable state which was the whole thing you were trying to avoid.

But if there's a GC, you don't have to think about it. And the GC can choose a "good time" to do it's bookkeeping in bulk, rather than making all of your concurrent accesses pay a price. So, if done properly, it's an overall performance win.

Interestingly, a performant solution without using GC is "hazard pointers," which are essentially like adding a teeny tiny garbage collector, devoted just to that datastructure (concurrent map, or whatever).

co sądzicie?

Sądzę, że autor tu opisuje problem bezpieczeństwa a nie wydajności.

how do you know when all users are done with the old revision

Najprostsza odpowiedź dzisiaj to, używam rusta, który nie skompiluje mi kodu gdzie stworzony wątek używa referencji, która może nie być we właściwym stanie w każdym momencie trwania tegoż wątku.

Each revision of the map is immutable, and your "changes" to it are really creating new, immutable copies (with tricks, to stay efficient).

Uuu, a które cudo tak robi? Nie ironicznie pytam, bo ja się zatrzymałem na wariacjach javowej ConcurrentHashMap gdzie, w uproszczeniu, blokujemy pojedyńcze kubełki zamiast całej kolejkcji, oraz takie, które robią użytek z dzielonych muteksów/blokad - shared mutex/lock.

A tak poza tym, to słaby wpis, skąd to? Takie bardziej głośne myślenie, niż jakiś educated guess. Autor teoretyzuje, że GC może pozwolić pisać efektywniejszy kod, co zawsze będzie prawdą niezależnie od problemu, tak samo jak zdanie, że kod w C może być wolny od problemów z pamięcią. Potem opisuje problem bezpieczeństwa a nie wydajności a na końcu jako argument podaje masowe zwolnienie pamięci, które to jako zaleta istnieje przynajmniej od lat 90' (techniczną świadomością nie sięgam dalej niż względnie nowoczesne IBM PC, Apple Next itp.) i trochę niepokojące, że dopiero teraz ją odkrył. Żadnych pomiarów, kodu, badań, takie sobie gdybanie.

several napisał(a):

Uuu, a które cudo tak robi? Nie ironicznie pytam, bo ja się zatrzymałem na wariacjach javowej ConcurrentHashMap gdzie, w uproszczeniu, blokujemy pojedyńcze kubełki zamiast całej kolejkcji, oraz takie, które robią użytek z dzielonych muteksów/blokad - shared mutex/lock.

Tu mogę się odnieść - bo temat jest mi znany z praktyki. W programowaniu funkcyjnym od dawna używa się Functional Data Structures - niestety trzeba poczytać, żeby ogarnąć (jest dużo prezentacji i video).
Paradoks tych struktur danych polega na tym, że w dowolnym małym benchmarku wyjdą oczywiście gorzej od mutowalnych (klasycznych) wersji (lista, hashmapa, etc.). Jeśli jednak wprowadzi się je w większym kodzie (np, aplikacji bankowej w javie) to okazuje się, że dostajemy zysk i na CPU i na RAM. Pierwszy raz jak to zobaczyłem to aż się zdziwiłem :-). Magii aczkolwiek nie ma.
Normalnie te struktury dają lekki narzut - powiedzmy 5-30% (w złośliwym benchmarku to i wiecej niż 200%) - tu mocno zależy co robimy.
Co ważne, wbrew powszechnym wyobrażeniom, niemutowalna lista nie oznacza, że jak chcemy coś dodać to się nie da. Da się, po prostu dostajemy nową listę. A oryginalna się nie zmienia. I nie, nie oznacza to, że kopiujemy dane. Magia?! Nie, zachęcam do poczytania.

I teraz dowcip. W praktycznie każdej większej aplikacji, gdzie mamy klasyczne mutowalne listy, mapy, gdzie miesiącami (latami) pracuje wielu ludzi, używa się defensive copying. Człowiek się szybko uczy, że bez tego tylko śledzi dziwne błędy, bywa, że dc jest wręcz wymuszane na review.
Przykład: Tworzymy nowy obiekt z listą (jako pole), który dostaje ją jako arg konstruktora - najpierw kopia, bo cholera wie co to za lista, i co ktoś z nią zaraz zrobi. Przy zwracaniu tej listy (getter) da się zwykle załatwić bez kopiowania (widok), ale zwykle też zaraz ktoś to kopiuje. W ten sposób aplikacja ciągle coś kopiuje.
(Tu się zgadzam, że to problem bezpieczeństwa, ale w znaczeniu poprawności programu).

Przejście na persistent (functional) data structures powoduje, że całe to kopiowanie nie jest już potrzebne, można bezpiecznie sobie wszędzie przekazywać struktury (szczególnie jeśli obiekty w nich są niemutowalne). I nagle wychodzi, że benchmarki o które się obawialiśmy - po wprowadzeniu niemutowalności zamiast się pogorszyć - poprawiają się istotnie.

Trudniej mi to odnieść do GC. W zasadzie to funkcyjne struktury danych wymagają jakiegoś GC, bo nie wiemy kto obiekt (listę na przykład) trzyma i możemy zwolnić dopiero jak nikt nie korzysta (oczywiście możemy użyć Rust, ale używanie niemutowalnych struktur w Rust to coś czego jeszcze sensownie nie poćwiczyłem).
Mogę zgadywać, że autor cytowany przez chinkę (:-)) odnosić się może do sytuacji - defensive copy bez GC - vs functional data structures + GC (ale to nie jest przykład, który miałem, bo moje doświadczenie dotyczyło kobył javowych z GC w obu przypadkach).

Przykładowo znajdź mi popularny język, gdzie masz zarówno GC i pola w strukturach, gdzie inne pola nie są koniecznie wskaźnikiami (co ma miejsce w podejściu everything is an object). C#? Go? Zgaduję, że ten pierwszy dostał ten ficzer (struktury) w okolicach 2005 co daje nam 35 lat od czasów języka C. Całkiem długo jak na taką oczywistość, która mocno wpływa na wydajność (Java też chce mieć value objecty)

C# ma struktury od samego początku, czyli okolic 2000 r. Wypominanie ile to lat po jakimś innym języku nie ma sensu, skoro mówimy o języku nowopowstałym…

Takie małe moje podsumowanie tego co tu przeczytałem,bo trochę się zrobiło zamieszanie przez dodatkowe wątki (jak struktury)
Ustrzeżenie: będę pisał trochę o Javie/Scali i JVMie, ale to nie dlatego uważam że od czegoś lepsze są tylko JVMa znam najlepiej z środowisk zarzadzanych

1. GC powoduje zatrzymanie świata (stop-the-world problem) - Nie jest to zatrzymanie na cały czas odśmiecania pamięci a tylko na czas oznaczenia które obiekty powinny zostać usunięte. Potem resztę można wykonywac już równolegle. (Jednak na odwrót, jak pisze niżej @Wibowit ) Podobno jedna firma kiedyś chwaliła się że rozwiązała ten problem bo pauza u nich jest tak krótka że można to już liczyć za real-time XD

2. Mieszanie kodu zarządzanego (przez GC) i niezarzadzanego (gdzie ręczne trzeba czyścić pamięć) - Takie rzeczy się robi i takie rzeczy są problematyczne. Ale jeśli mówimy w kontekście C++ (albo jednego języka) i wciąż chcemy mieć możliwość pisania aplikacji w całości niezarządzanych musiałoby to oznaczać że biblioteki są dostarczanwe w dwóch wersjach XD Ogrom roboty. Raczej stawiam że biblioteki byłyby pisane i tak w postaci niezarządzanej. Ale wtedy mogły by powodować wycieki pamięci w aplikacjach zarządzanych. Ewentualnie doprowadziłoby to społeczność do rozpadu na dwa. Część używającą tylko bibliotek z GC i część używającą tylko bibliotek bez GC

BTW taki mały suplement dla programistów C++ (kodu niezarządzanego). Ja rozumiem że jak w C++ trzeba zwolnić jakiś zasób deterministycznie to daje się to do destruktora. W Javie czy innych językach zarządzanych z GC może szokować to że finalizer jest wywoływany nieteterministycznie. Ale nikt nie zamyka zasobów w finalizerach (przynajmniej nie w Javie/Scali czy ogólnie na JVM, to nawet jest uważane za antypattern). Od tego jest Interfejs Autocloseable i konstrukcja Try with Resources która zastępuje deterministyczny destruktor. Można powiedzieć że połaczenia do bazy i dostęp do plików jest zarzadzany ręczie w Javie. Ale jak jakiś junior nie da rady zamknąć zasobu ręcznie to jak się zgubi (zasób, nie junior) to zamknie go GC, tylko że to trwa i mogą nam się np wyczerpać połączenia do bazy lub liczba otwartych plików (na unixie)

I to mnie prowadzi do kolejnego punktu czy akapitu że ciekawy byłby język gdzie ręcznie zarzadzamy obiektami jak w C++, ale jest jeszcze wpięty GC który potrafi czasem przejrzeć obiekty na stercie i sprawdzić czy jednak czagoś nie zgubiliśmy i nie ma wycieków. BTW2 tak, wiem że wycieki są dalej możliwe jak mamy GC

Pebal napisał(a):

Dlaczego programiści C++ mają alergię na termin Garbage Collector?

A mają?

Który język systemowy jest najbardziej podobny do Rust pod względem bezpiecznego zarządzania pamięcią? Ale jest mniejszy i prostszy o bardziej czytelnej składni?
Mam tu kilka opcji Vale, Val, V, Bog oraz bflat czyli kompilowanie C# do sprzętu. Także Zig, Odin, Jai, Roc, Toit, Haxe nie wymieniam ponieważ tak samo rozwiązują problemy z pamięcią jak C/C++.

https://github.com/Vexu/bog
https://github.com/bflattened/bflat
https://vale.dev/
https://www.val-lang.dev/
https://vlang.io/

Pebal napisał(a):

odnoszę nieodparte wrażenie, że środowisko to ma poważną alergię na termin Garbage Collector.

Nie sądzę, że to alergia.

1. Owszem GC jest fajne ale da się bez tego żyć i to wciąż bardzo wygodnie;
2. Jak masz mało zasobów a duże wymagania to tylko przeszkadza (np. embedded);
3. Jest to dodatkowy kod, który często wykonuje się w momentach, w których tego nie chcemy. W szczególności gdy zależy nam np. na dokładnych synchronizacjach czasowych...

Jasne, że jak się pisze jakie okienka i formularze to szkoda czasu na pilnowanie pamięci ale jak już piszesz coś co zajmuje pamięć "pod korek" to czasem trzeba to zrobić ręcznie.
Jak zacząłem pisać w językach z GC to dłuuuugo jeszcze miałem nawyk ręcznego zwalniania zasobów. To wchodzi w krew i nie jest jakimś szczególnym "obciążeniem".
Oczywiście, że czasem znajdą się karkołomne sytuacje gdzie taki GC pewnie zadziała sprytniej niż mógłby to samodzielnie wymyślić programista...

W ogólności oceniam GC jako bardzo komfortowy dodatek ale jednak trochę mieszający po swojemu a ludzie piszący w takim C++ lubią czuć co program robi nie tracąc nad nim kontroli w żadnym momencie.