Но в массовом юникс-коммюнити таки наблюдается... раздолбайское презрение к "высокоуровневым штучкам", согласитесь
Занятно было бы провести опрос хотя бы по реакции на понятие "сборка мусора" - сколько процентов среди юникс-программистов охарактеризуют его как отрицательное и сколько - среди Windows-программистов Скриптовых программистов не опрашивать (ну а функциональные особо не дадут значения ).
Не, не соглашусь. Как-то резко все под одну гребенку. Давайте делить на мух и котлет оную субстанцию.
Итак, что мы имеем? Во-первых мы имеем разработчиков пишущих драйвера, куски ядра, системные сервисы, вообще вещи критические как по быстродействию так и по памяти. Тут, очевидно, соборщику мусора не место, тут не место даже просто жирному рантайму и стандартным либам. Поэтому это в основном Си (именно Си еще и потому, что posix на си завязян, кстати, я настолько уверен что позикс завязан на си, что уже начинаю в этом сомневаться, надо бы доки внимательно зачесть).
Далее мы имеем скриптинг. То есть автоматизацию рутинных операций пользователя ЭВМ. Не важно кто этот пользователь – программист, домохозяйка или доктор физмат наук. Важно что он сам автоматизирует оную рутину посредством написания так называемых скриптов. Тут важна хорошая интеграция языка с шелом (оболочкой в которой пользователь обычно работает) системы, посему тут рулят языки которые умеют легко и просто работать со стандартными потоками ввода-вывода и строками. А также не грузят пользователя-скриптопрограммиста своими мегапарадигмами навроде ООП там, строгой типизации и прочими артефактами программинга, ручное управление памятью сюда тоже входит. Соответственно тут рулят такие языки как shell, python, perl. У некоторых из них есть сборщик мусора, у некоторых нет. Но память в любом случае там управляется не руками.
Далее имеем разработку всякого прикладного софта, который с одной стороны пишется один раз, а используется многими и при этом достаточно сложен (посему это не скриптинг), с другой стороны он должен быть достаточно технологичен, то есть дешев в производстве и при этом там нет таких жестких ограничений на память и проц как в системных сервисах, но они все равно
есть. Поскольку он сложен, тут уже без программерских артефактов, вроде того же ООП не обойтись, ибо нужно как-то со сложностью бороться. Поскольку он должен быть достаточно дешев, тут автоматическое управление памятью желательно, хотя и не обязательно (ряд задач например все равно требует таки реалтайма, например те же игры). Да, и при этом он должен быть легко скомпилирован на большенстве машин потенциальных пользователей оными пользователями не программистами. То есть инструментарий должен быть легко доступен во всех смыслах этого слова. Тут рулит сонма языков. Это: vala, java, c#, c++, ObjC, C, python, erlang, ruby, js, lua и так далее. Причем часто используются сочетания языков. Например C + Python. Подавляющее большенство этих языков имеют автоматическое управление памятью в том или ином виде, большенство из них имеют сборщик мусора.