Comdiv писал(а):
Поэтому мне непонятны необдуманные утверждения про "безнадёжно испорченный".
Это уже существенные изменения семантики, создающие другой язык. Безнадёга — она в библиотеках, кишащих программными ошибками. Либо брать с ошибками, либо никаких библиотек, можно считать, и нет.
Вот с Modula-2+ — другое дело. Там, конечно, впоследствии были эксперименты с TGC, но штатным режимом был ARC, поэтому как в Objective-C 2.0, можно было ожидать от библиотек, что они на любой режим будут расчитаны, просто тумблером щёлкай, и всё.
Comdiv писал(а):
OCTAGRAM писал(а):
В XUL без JavaScript ничего не обходится. Он постоянно в фоне что-то делает, начинает сборку мусора, потом сообщение вылезает, что скрипт долго не отвечает, и там какой-нибудь JavaScript указан.
И какую долю занимает XUL - 90 % или всё-таки меньше 10%?
Просто представьте, что вам нужно нанять нового сотрудника для Фонда Мозилла, и либо можно найти такого, что будет писать на C++ хорошо, понимать XPCOM и XPConnect и уметь собрать это всё хотя бы для своей OS, либо можно найти разработчика на JavaScript.
Получается, что на C++ только сокеты и базовый UI, а солидная часть — в JavaScript, и там много живых объектов. Если в ARC один раз платить за мёртвые, то в TGC платить за живые. Постоянно. Снова и снова. Оно не будет тихо сидеть, оно постоянно будет делать обход за обходом. На иную программу можно разозлиться, мысленно спросить: «ну ты закончишь там свои дела уже, нет?» Трассирующий сборщик мусора не таков. Ему всегда есть, чем заняться.
Comdiv писал(а):
злоупотреблении динамической памятью
Ну будет вечный двигатель наоборот работать в темпе чуть более медленном, чем обычно.
Comdiv писал(а):
для мобильных телефонов с 64 кб оперативной памяти я писал приложения тоже на Java с этим ужасным GC, и это работало
О, нет, это как раз, на мой взгляд, и есть причина, по которой проблема TGC так далеко зашла. Там не могут программы посоревноваться за своп, буксуя при этом. Там живых объектов может быть не больше, чем эти 64 кб. В Оберон ОС память всех программ была общей, не было свопа и не было конкуренции за него. Программистов завораживало освобождение памяти как бы по волшебству, и ещё не было убийственных побочных эффектов. Tо, что было красиво на 64 кб и даже 640 кб, смасштабировали на несколько Гб, и
…Cyberax писал(а):
Так можешь не искать, у нас задержка примерно в две минуты на сервере с 16Гб хипом после тюнингов. Что еще не так плохо, кстати. Нам это не так важно, так как неотзывчивый сервер у нас просто из кластера блокируется — Oracle Coherence рулит.
… всё это уже не так хорошо выглядит.
Comdiv писал(а):
Мне, к примеру, как пользователю GNU/Linux портит жизнь тормознутость Python
Пользуюсь TortoiseHg и очень доволен, что если оставить его в фоне, он не напоминает о себе, в отличие от некоторых других программ. Насколько мне известно, в Python есть CIL, а раз оно там есть, то источник наиболее частых претензий к ARC, атомарные операции, там должен отсутствовать как явление. Насчёт аномального засилья скриптов и виртуальных машин в Linux у меня есть кое-какие соображения, но это отдельная тема.