[C++?] Серьезный вопрос.

> > Или в Google на их сотнях тысяч PIII-PIV машинок исключительно Erlang крутится?

> А что, у Гугла в датацентрах дорогие сервера стоят?

Напротив -- очень дешевые. Настолько, что Erlang-овская VM там не будет показывать таких выдающихся результатов, как в тестах на Sparc-ах с десятками гигабайт RAM (когда удавалось поднять 1M тестовых Erlang-овых процессов).

>Они сделали свой инструмент для решения своих задач. Инструмент, надо сказать, сильно заточенный под специфические цели. Написать на нем, скажем, текстовый редактор, будет гораздо сложнее, чем на C++.

Так о чем и речь, зачем писать текстовый редактор на эрланге, никому в голову это никогда не придет %-) Просто тут некоторые пользователи взяли и сказали "эрланг - говно, хаскель - говно, оберон - говно, лисп - говно, все говно кроме си/си++" а это уже реально кащенко, согласись.

> Так о чем и речь, зачем писать текстовый редактор на эрланге, никому в голову это никогда не придет %-) Просто тут некоторые пользователи взяли и сказали "эрланг - говно, хаскель - говно, оберон - говно, лисп - говно, все говно кроме си/си++" а это уже реально кащенко, согласись.

Соглашусь. Но ведь не я это писал. Хотя по поводу Лиспа...

Хотя я вроде понимаю откуда у них такая ненависть, наверное они кроме формочек ничего никогда не рисовали, и для них что-то писать - это только конкретно обязательно x86/пользовательская машина, которая будет рисовать менюшку юзеру с кнопочками. Т.е. тоже достаточно ограниченая ниша так если пораскинуть мозгами %-)

> Не мог бы кто-нибуть из защитников С++ переписать его на любимом языке. Мы бы тогда и сравнили производтельность и трудозатраты. С числами в руках легче рассуждать. А то сейчас одно сплошное переливание из пустого в порожнее.

Всяких пенисометрий вокруг детских задач было уже написано множество. Вот, например, хорошая задача: Wide Finder (http://wikis.sun.com/display/WideFinder/Results). Первые два места за реализациями на C++. Там хорошо видно, во что обходится скорость работы.

> Вот, например, хорошая задача: Wide Finder (http://wikis.sun.com/display/WideFinder/Results). Первые два места за реализациями на C++.

Причём третье место за окамлом с отставанием около 20% от первого места. Ну вот в упор не вижу разницы в 6 раз, как некоторые утверждают. 8))

> Причём третье место за окамлом с отставанием около 20% от первого места. Ну вот в упор не вижу разницы в 6 раз, как некоторые утверждают. 8))

Зато окамл в три раза короче первого места и в два - второго. Наверняка в крестах ещё секс с памятью был.

> Зато окамл в три раза короче первого места и в два - второго. Наверняка в крестах ещё секс с памятью был.

Зато этот вариант на OCaml-е был третьей попыткой одного и того же человека. Так что честнее будет просуммировать объемы всех версий решений на OCaml-е от Фернандеза (подробности своих решений он описывал у себя в блоге).

> Напротив -- очень дешевые.

Так о чём и речь. Если система хорошо масштабируется на кластер и сбой одного нода для неё не критичен (как для гуглового map/reduce), то можно обойтись дешёвым железом. Erlang тоже прекрасно себя чувствует на кластере из дешёвых машинок.

> Настолько, что Erlang-овская VM там не будет показывать таких выдающихся результатов, как в тестах на Sparc-ах с десятками гигабайт RAM (когда удавалось поднять 1M тестовых Erlang-овых процессов).

Ну и что? Перестало хватать производительности - добавил в кластер ещё пару дешёвых железяк. У эрланга масштабируемость чуть ли не линейная.

> Узнай о существовании Эрланга и утопись.

Если не ошибаюсь, то науке известен ЕДИНСТВЕННЫЙ ДЕЙСТВИТЕЛЬНО МАССОВЫЙ продукт на Эрланге. Это eJabber. Если я не ошибаюсь. Что-то ещё показать можете? На Эрланге...

> Ну и что? Перестало хватать производительности - добавил в кластер ещё пару дешёвых железяк. У эрланга масштабируемость чуть ли не линейная.

Тогда расходы перейдут из категории "зарплата программиста" в категории "амортизация техники", "электроснабжение" и "зарплата администраторов".

Масштабируемость Erlang-а -- это сферический конь в вакууме. Масштабируемую прикладную систему еще нужно написать. Тут проектирование будет играть такую же важную роль, как и выбор инструментария. Если не важнее.

> Тогда расходы перейдут из категории "зарплата программиста" в категории "амортизация техники", "электроснабжение" и "зарплата администраторов".

Сам же про Гугл пример давал. Расскажи им, что они деньги считать не умеют.

> Масштабируемость Erlang-а -- это сферический конь в вакууме. Масштабируемую прикладную систему еще нужно написать. Тут проектирование будет играть такую же важную роль, как и выбор инструментария. Если не важнее.

Насколько хорошо ты знаешь Erlang/OTP, чтобы делать такой вывод?

> Сам же про Гугл пример давал. Расскажи им, что они деньги считать не умеют.

Они как раз умеют. Поэтому у них софт написан на C++, а не на Erlang-е. При этом расходы на обеспечение своих датацентров у них чуть ли не самая большая статья расходов.

> Насколько хорошо ты знаешь Erlang/OTP, чтобы делать такой вывод?

Поверхностно. Но достаточно для того, чтобы понять, что Erlang/OTP не может волшебным образом обеспечить линейную масштабируемость любой прикладной задачи. Поэтому и сказал, что сама по себе масштабируемость Erlang-а никому не нужна.

> Если не ошибаюсь, то науке известен ЕДИНСТВЕННЫЙ ДЕЙСТВИТЕЛЬНО МАССОВЫЙ продукт на Эрланге. Это eJabber. Если я не ошибаюсь. Что-то ещё показать можете? На Эрланге...

Опять аргументы из серии "миллионы мух не могут ошибаться"?

Yaws, RabbitMQ, CouchDB, Wings 3D.

Эрланг конечно же сейчас менее распространён, чем С++, и, следовательно, софта на нём тоже меньше. Но давай тогда и на качество софта тогда смотреть для объективности.

>Yaws

Можно узнать, где он реально применяется?

Хорошо. Я понял чего господа вы не то что бы не понимаете, скорее не желаете понять.

> Если ты так и не понял, Хаскелл и Окамл - статически типизованные компилируемые языки.

Кто это назвал компилятором? Если предположить что под словом компилятор понимается "программа, транслирующая код на некоем языке в код, близкий к машинному" (более-менее "классическое" определение), то пардон, но компилятор есть даже в php. Не говоря о Java и С#. В этом смысле ваш "компилятор" чётко встаёт в этот рядок ибо без "платформы" (как минимум библиотек поддержки) оно жить не может. Но в случае с С оно почти так же? Да. Вот только одно отличие -- стандартные библиотеки так названы не зря. Они, в отличие от предлагаемой "платформы" есть в любой системе. Хотим мы того или нет.

Если исходить из того, что gcc это "соборный компилятор", включающий в себя ряд компиляторов, то покажите мне там Хаскел? Тогда покажите мне систему с превалирующим языком, отличным от С/С++. Ну, на Хаскеле, что ли... он же настолько из себя "бездат" что просто круть несусветная... Пока же я сижу и рыдаю от истинных слёз счастья над кодом из haskell-platform-2009.2.0.2.tar.gz... CGI-3001.1.7.1 называется. К чёрту. Если это ваш подход, то лучше я на ассемблере писать буду. Будет короче.

Всё становится на свои места, если перестать бредить и взглянуть на вещи реально -- то, что называется компилятором таковым является только по определению. Не более. В реале оно требует столько поддержки, что ну его на ... И, до той поры, пока это будет происходить, называйте "ЭТО" компилятором... Не называйте это компилятором -- дело Ваше. Я это называть компилятором отказываюсь. Несмотря на то, что оно даже в объектный код результат компиляции выводит.

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

> И то, что для них есть интерпретаторы, этих свойств не отменяет.

Даже спорить не собираюсь. Нет ни какого предмета для спора.

> Но считать всё то, что тебе непонятно - наукообразным онанированием - это уже идеология быдла.

Если Вы подумали что приравняв меня к быдлу Вы тем самым меня оскорбили, то я разочарую. Ни в коей мере. Да. Я то самое быдло, которое работает в как это модно нониче говорить "реальном секторе экономики". Я зарабатываю денег и себе и, будучи team-leader'ом, команде. С этих денег мы платим налоги. В том числе и на "жрецов науки". Вспоминается определение некоего госп. Ландау (академика который), говаривавшего что "жрец науки это тот, кто жрёт за счёт науки".

Однако, оставим в стороне колкости и язвительности. Прошу показать аналог postfix на Хаскеле. Кроме того, прошу показать аналог PostgreSQL (на нём же). Ну, и самое простенькое -- аналог 1С в студию. Для полноты картины. В конце-концов наверное надо ужо явить мощь... полно факториалы-то на ощупь искать... =))) К использованию CGI (даже, не говоря о более интересных вариантах) оно не пригодно. Судя по исходникам. Убиться можно...

> Просто кодить на С++

Прошу меня простить, но меня учили "писать программы". Слово "кодить" вызывает стойкие аллюзии со словом "гадить". Это, наверное, способ использования "компилятора" Хаскел? А! Тогда я понял -- вот по какой причине нет супер-массового наи-новейшего языка всех времён и народов... Ясно...

> Кстати, там про С++ тоже есть.

Пардон. Я ни когда не называл себя апологетом С++. Я, в основном больше по С, Jave... Там про это то же есть? А то я ниасилил... =)))

> При этом расходы на обеспечение своих датацентров у них чуть ли не самая большая статья расходов.

Через год интернет вырастет еще в 1,5 раза и гугл обанкротится. Или возьмет кредит у МВФ

В этом смысле ваш «компилятор» чётко встаёт в этот рядок ибо без «платформы» (как минимум библиотек поддержки) оно жить не может.

kemm@redsun ~/tmp/hs $ ghc -o eps eps.hs
kemm@redsun ~/tmp/hs $ ldd ./eps
        linux-vdso.so.1 =>  (0x00007fffc93dc000)
        librt.so.1 => /lib/librt.so.1 (0x00007f5fbe3f5000)
        libutil.so.1 => /lib/libutil.so.1 (0x00007f5fbe1f2000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f5fbdfee000)
        libm.so.6 => /lib/libm.so.6 (0x00007f5fbdd6b000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f5fbdb0e000)
        libc.so.6 => /lib/libc.so.6 (0x00007f5fbd7b3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5fbd597000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5fbe5fe000)
kemm@redsun ~/tmp/hs $ ocamlopt -rectypes -inline 1000 -ccopt -ffast-math ray.ml -o ray
kemm@redsun ~/tmp/hs $ ldd ./ray
        linux-vdso.so.1 =>  (0x00007fff9cbb2000)
        libm.so.6 => /lib/libm.so.6 (0x00007f5e866fa000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f5e864f6000)
        libc.so.6 => /lib/libc.so.6 (0x00007f5e8619b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5e8697d000)

О чём ещё можно с тупицей говорить?

> Они как раз умеют. Поэтому у них софт написан на C++, а не на Erlang-е.

В гугловом софте важен алгоритм - map/reduce. Именно тем, что он хорошо масштабируется на кластер. Согласен, Эрланг *именно* в этом случае для Гугла подошёл бы хуже, т.к. он медленнее из-за своей динамической натуры.

Но речь шла не о том. Ты только что говорил, что использование парка дешёвых железок слишком сильно увеличивает расходы на админов, электричество и т.п.

> При этом расходы на обеспечение своих датацентров у них чуть ли не самая большая статья расходов.

А с чего ты решил, что замени они много дешевого железа на мало дорогого, у них расходы на датацентры уменьшились бы?

> Поверхностно. Но достаточно для того, чтобы понять, что Erlang/OTP не может волшебным образом обеспечить линейную масштабируемость любой прикладной задачи.

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

> Опять аргументы из серии "миллионы мух не могут ошибаться"?

Извини. Мне не с мухами соревноваться. =))) Мне бы чтоб работало.

> Yaws, RabbitMQ, CouchDB, Wings 3D.

1. "Исчо один веб сервер". Бл?... Да сколько их писать-то можно??? Или только для Эрланга не хватало? Вот на всём есть. А на Эрланге нет...

2. Так. Мессейнджер. Не. Новое gadu-gadu с 6 млн. пользователями где-то в Польше? Бррр... Извини. Стебаюсь. Но ЗАЧЕМ переписывать то, что уже нормально работает?

3. Хорошая штука. Обхожусь на кластере без неё. Не хочется городить огород во-первых, с самим по себе Эрлангом, а, во вторых, отказываться от PostGIS. Ибо туева хуча работы уже сделана. А! Ну, извини. Не на Эрланге.

4. Wings 3d. Хорошая штука. Очень далёкий конкуррент блендера.

В сухом остатке похоже на список того, что можно написать. Если ОЧЕНЬ захотеть. Я лично не против. Но комментарии выше. И недоумение -- а чё, с тупым и банальным С так сложно разобраться, что нужно придумать что-то настолько "новое"? В чём тут прикол-то?

> В реале оно требует столько поддержки, что ну его на ... И, до той поры, пока это будет происходить, называйте "ЭТО" компилятором... Не называйте это компилятором -- дело Ваше. Я это называть компилятором отказываюсь. Несмотря на то, что оно даже в объектный код результат компиляции выводит.

Вы абсолютно правы, уважаемый. О чём можно говорит с безграмотным тупицей, даже русского языка не выучившим -- мне не понятно. Я с Вами, вообще-то, по этой причине и не говорю. Вот разве что в данном случае убогому разъясняю. так это же богоугодное дело... =)))

>synchronized (this) {

>... Мы в домике...

>}

Видел на лоре, удивился. О какой производительности можно вести речь, если все чтения становятся в одну очередь с записями?

> Ниша эрланга типично серверная -- обработка множества параллельных запросов. И там обеспечить хорошую масштабируемость не так уж сложно.

Эээ... А что, ряд решений, на которых основан тот же Беовульф (OpenMP, PVFS2 просто как примеры) не обеспечат Беовульфу хорошую масштабируемость? Или их недостаточно? Тогда можно вопрос -- в чём именно проблема?

>Оптимизацией надо заниматься когда уже есть рабочий неоптимизированный вариант.

Это в сферической индии в вакууме так. На практике если об оптимизации не думают с самого начала, то она не делается вообще никогда.

> Ты только что говорил, что использование парка дешёвых железок слишком сильно увеличивает расходы на админов, электричество и т.п.

Я не говорил что сильно. Я сказал, что если экономить на производительности софта в расчете на масштабируемость, то те же самые деньги, которые пришлось бы заплатить программистам за оптимизацию кода, уйдут на расходы по эксплуатацию большего количества железа.

> А с чего ты решил, что замени они много дешевого железа на мало дорогого, у них расходы на датацентры уменьшились бы?

Это вы за меня решили. Я предполагал, что напиши Google-овцы свой софт на Erlang-е, расходы бы у них были еще больше.

> Ниша эрланга типично серверная -- обработка множества параллельных запросов. И там обеспечить хорошую масштабируемость не так уж сложно.

Имею основания не согласиться.

> Тут проектирование будет играть такую же важную роль, как и выбор инструментария. Если не важнее.

Важнее. И намного. Её потом ещё и "поддерживать" и "расширять" как правило надо. Но и "цена вопроса" здесь совершенна иная. Чем просто "написать".

> О чём можно говорит с безграмотным тупицей, даже русского языка не выучившим

Ты, тупица, русского языка не знаешь. Ты, тупица, мало того, что нём писать не умеешь, так ещё и свой же бред прочитать не способен. Показывай в предоставленном выводе ldd "библиотеки поддержки", про которые ты так красиво бредил.

> Примеры задач со сложными графами объектов таки будут или нет?

Чем тебе задача написания своего Application Server не нравится? Или ты думаешь, что там только лес или одно дерево. Кстати, дерево - частный случай графа. Так что, сам понимаешь... ;)

> Кто это назвал компилятором? ... [бред поскипан]

Компилятор -- это термин, т.е. вполне определенное понятие во вполне определённой области знаний. А то, что ты под этим словом хоть свой член подразумеваешь, никого не волнует.

> Если Вы подумали что приравняв меня к быдлу Вы тем самым меня оскорбили, то я разочарую. Ни в коей мере. Да. Я то самое быдло, которое работает в как это модно нониче говорить "реальном секторе экономики". Я зарабатываю денег и себе и, будучи team-leader'ом, команде. С этих денег мы платим налоги. В том числе и на "жрецов науки". Вспоминается определение некоего госп. Ландау (академика который), говаривавшего что "жрец науки это тот, кто жрёт за счёт науки".

Ты жрёшь за счёт тех, кто тебя снабдил компилятором, библиотеками и прочими инструментами. Гордый юзер лопаты, йопт.

> Видел на лоре, удивился. О какой производительности можно вести речь, если все чтения становятся в одну очередь с записями?

Есть read/write локи в java.util.concurrent.

> RabbitMQ

> 2. Так. Мессейнджер. Не. Новое gadu-gadu с 6 млн. пользователями где-то в Польше? Бррр... Извини. Стебаюсь. Но ЗАЧЕМ переписывать то, что уже нормально работает?

Ты действительно думаешь, что это типа аськи? :-D

> Чем тебе задача написания своего Application Server не нравится?

Там нет сложных структур данных.

> Кстати, дерево - частный случай графа.

Смею напомнить благородному дону его собственное утверждение: "На нетривиальных задачах Java с ее gc справляется зачастую лучше. Подчеркну, нетривиальных. С циклическими связями, с многочисленными локами и прочим непотребством." (http://www.linux.org.ru/jump-message.jsp?msgid=4088836&cid=4131234)

Так что не нужно отмазываться деревьями. Пример сложной структуры с циклическими связями, плз. А то вы лихо обвинениями в адрес C++ разбрасываетесь, а видели всего одну многопоточную C++ программу.

> Ты, тупица, русского языка не знаешь. Ты, тупица, мало того, что нём писать не умеешь, так ещё и свой же бред прочитать не способен.

Оууу... Какая патетика... "Если бы криком можно было построить дом, то ишак бы выстроил целую улицу". Это так... Вскользь и для начала.

Продолжаем.

> Показывай в предоставленном выводе ldd "библиотеки поддержки", про которые ты так красиво бредил.

Очень интересный и познавательный материал есть тутттаааа -> http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-src-extralibs.tar.bz2

Но это, Вы абсолютнейше, совершеннейше правы, такая мелочь -- всего пол-метра говна...

В остальном, глядя на 7.7 метра говна, расположенного тутта -> http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-src.tar.bz2 Я не вижу ровным счётом ничего нового. Прокладки к существующим реализациям. Не более. Уссаться от одного Task.c в /rts. Кстати, а то такое rts, не просветите убогого? И на хер было ваять собственный TaskManager? Чем-то системный шедьюлер не угодил? Или это новая мода такая -- изваять собственный менеджер задач и вопить о невъипенной крутости реализации?

Всё остальное онанирование мне не интересно. Я могу продолжить, но мне просто и откровенно лень.

Вы там предлагали мне санитаров вызвать? Мой далёкий недалёкий друг, жизнь прекрасна и удивительна, если правильно подобрать анти-депрессанты. =)))))))))))))))))

> Компилятор -- это термин, т.е. вполне определенное понятие во вполне определённой области знаний. А то, что ты под этим словом хоть свой член подразумеваешь, никого не волнует.

Точно. Я не спорю. Заметь. Я просто постарался объяснить свою точку зрения. Она (возможно и не правильная) но имеет право на существование.

> Ты жрёшь за счёт тех, кто тебя снабдил компилятором, библиотеками и прочими инструментами. Гордый юзер лопаты, йопт.

Не совсем так. Наша организация делала и делает вполне ощутимые взносы. Жрать за чей-то счёт не приобыкшие.

> Ты действительно думаешь, что это типа аськи?

Нет. Не "типа аськи" это. Это довольно интересно. Соглашусь. И с радостью заинтересовался бы, если бы не использовал (и для администрирования в том числе) XMPP в данный момент. В варианте Jabber2. Уж больно удобно...

Мой далёкий недалёкий друг, жизнь прекрасна и удивительна, если правильно подобрать анти-депрессанты. =)))))))))))))))))

Ммм... Так вот в чем секрет неиссякаемого бреда!

Привели же конкретный пример, задали простой вопрос... Так сложно признать, что лоханулся?

Показывай в предоставленном выводе ldd «библиотеки поддержки», про которые ты так красиво бредил.

Очень интересный и познавательный материал есть тутттаааа -> http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-src-extralibs.tar.bz2

Но это, Вы абсолютнейше, совершеннейше правы, такая мелочь — всего пол-метра говна...

Ты о чём? Там есть «библиотеки поддержки», а не библиотеки языка, которые нужны только на машине разработчика? Ты о чём в настоящий момент, переведи на русский, будь добр? А то ведь оно как-то так выглядит:

$ equery f ghc | fgrep .so
$

Или теперь будем смотреть на размер тарбола с gcc?

И всё таки, где в предоставленном выводе ldd на бинарники, скомпилированные компиляторами хаскелля и окамла в штатном режиме их (компиляторов) работы, обещанные тобой библиотеки пддержки?

Чем-то системный шедьюлер не угодил? Или это новая мода такая — изваять собственный менеджер задач и вопить о невъипенной крутости реализации?

Подумай на досуге, почему на ерланге можно наплодить около ляма ерланговых процессов. Системный шедулер сдохнет в муках гораздо раньше этой цифры.

Мой далёкий недалёкий друг, жизнь прекрасна и удивительна, если правильно подобрать анти-депрессанты. =)))))))))))))))))

Я заметил. Попроси врача подобрать другие, от этих у тебя галлюцинации.

> Ммм... Так вот в чем секрет неиссякаемого бреда!

Ну конечно же... =)))

> Привели же конкретный пример, задали простой вопрос... Так сложно признать, что лоханулся?

Хорошо. Я могу признать что лоханулся. Боле того! С радостью это сделаю. Вот только мой вопрос так и останется "за скобками"?

Он же очень прост... Упс. Ошибся. Там их два. Я там про Task.c поминал. Итак, вопрос #1. нахер писать было TaskManager? Чем-то не угодил системный шедьюлер? И вопрос #2. А что такое в данном случае rts? Можно простенько и без патетики? Для "крестьян от лопаты, йопт".

А то чего-то суть ускользает от меня... Как бы это не я лоханулся... =))))

>> Ты жрёшь за счёт тех, кто тебя снабдил компилятором, библиотеками и прочими инструментами. Гордый юзер лопаты, йопт.

> Не совсем так. Наша организация делала и делает вполне ощутимые взносы. Жрать за чей-то счёт не приобыкшие.

Я не про деньги. Ты тут про компиляторы такую чушь несёшь, что совершенно понятно, что создания даже простенького в жизни не осилишь. А самое весёлое, что тебя похоже просто гордость от этого распирает.

А то чего-то суть ускользает от меня... Как бы это не я лоханулся... =))))

Не-не. Про rts и таск манагер я пока молчу ибо не хаскелит ни разу. Я только за вагон рантайма уточнил для повышения конструктивности беседы :)

Не. Уж прошу меня простить, но к моему величайшему сожалению погоня за изыками Вашей мысли меня несколько притомила. Их довольно много. И, самое поганое, что дискуссия с Вами либо сводится к какой-то мне лично неясной истерике. Либо к увёрткам. Это было не далее как вчера. Это есть сегодня.

Вот пример...
> Системный шедулер сдохнет в муках гораздо раньше этой цифры.

Видимо, по счастью системный шедьюлер этого не знает. По этой причине, сцуко и не дохнет... Ты хоть проверял это? Замеры делал? На чём? Где цифры? Нет? Ну а с куя ли такая уверенность-то? У меня вот на основании практического решения это вызывает резкое недоумение. Ну не дохнет он, падла такая... И от существующего решения я, пожалуй, отказываться не буду.

В общем, рад сообщить что я, пожалуй, от спора с Вами уклонюсь.

> Нет. Не "типа аськи" это. Это довольно интересно. Соглашусь. И с радостью заинтересовался бы, если бы не использовал (и для администрирования в том числе) XMPP в данный момент. В варианте Jabber2. Уж больно удобно...

Пипец. Он действительно думает, что это такой instant messenger. %-)

Погугли про message queuing, просветись.

> Ты тут про компиляторы такую чушь несёшь, что совершенно понятно, что создания даже простенького в жизни не осилишь.

Yacc/Bison для создания лексического анализатора не считается? Ну и хрен бы с ним.

> А самое весёлое, что тебя похоже просто гордость от этого распирает.

Ага. Конечно. Не всем ведь компиляторы создавать. Кому-то ими и пользоваться...

>При этом следует держать в уме, что за зарплату хороших С++ кодеров за время написания, тестирования и отладки С++ сервера можно купить кластер в десяток-другой машинок под эрланг-сервер.

И сколько же лет должен разрабатываться такой "сервер", чтобы набрать на зарплатах кластерок на десяток-другой машин? Кстати, ты видимо забываешь, что размещение кластеров в датацентре тоже денег стоит и немалых.

>Он годится для написания высоконадёжных многопоточных масштабируемых систем.

А я говорю, что не годится. И ejabberd тому пример.

> Про rts и таск манагер я пока молчу ибо не хаскелит ни разу.

Извини. Я то же. Вот только HOOGLE мне по-рекомендовали... Да и так... На CGI-3001.1.7.1 поглядел... оторвавшись от лопаты. Ты знаешь, море фана. =))))))

> Я только за вагон рантайма уточнил для повышения конструктивности беседы :)

Да я бы не салупался так, если бы не довольно провокационные заявления. Основанные на том, что там всё так бездато, что хоть брось всё и метнись на нём шарашить.

Ну говно вопрос -- для начала пущщай ужо в gcc его включат. GCC -- компилятор "соборный", там даже Chill был включён... И не такое выносил... ну в чём проблема-то?

> Пипец. Он действительно думает, что это такой instant messenger. %-)

Покамест мне хватает документации. В частности -> http://www.rabbitmq.com/documentation.html#server

> Погугли про message queuing, просветись.

Пипец. Он действительно думает что XMPP это только протокол messanger'а? %-)

>Во втором номере журнала "Практика функционального программирования" размещён небольшой пример на эрланге.

Мвахаха... Цитата оттуда:

>Одна из первых версий программы запускала независимый процесс сохранения для каждого адреса. К сожалению, это не заработало. Я не смог получить ни одной картинки. Я не знаю истинной причины.

В этом весь ваш "промышленный" ерланг.

>Но потом их место прочно заняли серверы приложений на Java.

Что-то я не вижу засилия "серверов на Java". Кажется, они не применяются нигде, кроме "энтерпрайза", где требуется обслужить 1000 человек в сутки. Такое можно писать хоть на шелле.

Да ладно тебе... =))) Не волнуйся -- завтрева всенепременно всё "эрланггируют", поедем мы старые, сирые да убогие картошку сеять да копать...

Во всём этом треде мне топикастера жаль разве что...

Да. Кстати. В джаббере можешь нарисоваться или перезвонить? Темка есть.