Web in BB.

[valexey]

В высоконагруженных приложениях идёт другой режим работы с памятью - и вещи, написанные в расчёте на автоматическую сборку мусора, не катят. Про что здесь много говорят Сергей и Алексей. И многие, решающие подобные задачи, сейчас приходят к этому пониманию.

Идёт закономерный виток спирали развития - "отрицание отрицания", ручное управление, но на новом уровне, в герметичном языке.

Эрланг расчитан на создание высоконагруженного серверного ПО, и там сборщик мусора вполне справляется с работой.
Почему же там это катит, а в других языках -- нет?

Во-первых там не некое обобщенное высоконагруженое приложение, а вполне конкретное (система массового обслуживания).
Во-вторых оный erlang под это заточен, то есть под конкретное применение. По сути erlang это эдакий DSL от эриксона. Для других задач erlang не применим.

Ах, да. Почему ты о них говоришь в единственном числе. :-) Там же у каждого процесса свой собственный сборщик мусора. (а процессов да, десятки и сотни тысяч).

[Geniepro]

Ах, да. Почему ты о них говоришь в единственном числе. :-) Там же у каждого процесса свой собственный сборщик мусора. (а процессов да, десятки и сотни тысяч).

Ну а как иначе-то? Это же не примитив типа .NET, естественно, что там должен быть собственный GC у каждого процесса... 

[Peter Almazov]

... или вон Visual Studio. Напишите какой-нибудь элементарный плагинчик, шоб прочувствовать.

Вообще-то сайте http://visualstudiogallery.msdn.microsoft.com/ лежит уже 3302  плагинчика.
Попробуйте написать простенький плагинчик в ББ типа такого http://forum.oberoncore.ru/viewtopic.php?p=51289#p51289

[Илья Ермаков]

Ну так это пример на задачу, которая выходит за сферу гибкости базовой модели (ББ-шного текста).
Я точно так же могу предложить задачу написать плагинчик для Студии, который поддержит внедрение прямо в исходник какого-нибудь графического объекта, схемы, с возможностью редактирования "по месту", по которой потом будет генерироваться код в это место.