Можете раскрыть тему: что в Erlang-е, не важно в языке ли, в платформе ли, обеспечивает real-time-овые гарантии, хотя бы софтовые? И почему вы считаете, что реалтаймовость в других языка (в частности в C, в C++, в Modula-2, в Ada) находится в зачаточном состоянии?
По сути, Эрланг выступает в виде современного Лиспа То, что было когда-то в Лиспе постепенно переползло в мейнстрим. Сейчас то, что есть в Эрланге тоже медленно переползает в мейнстрим Плюс концепции, заложенные в Эрланг, доказали, что они работают. Причем настолько, что чуваки, разрабатывающие распределенные базы данных, открыто говорят, например, что они стараются пользоваться только тем, что доступно в стандартной поставке Erlang'а — в 99% случаев этого более, чем достаточно.
1% процент это видимо проблема консенсуса в распределенной системе, которая не решается эрлангом. Без ее решения распредленная база данных это просто кэш, содержимое которого размазано по нодам кластера, где читающий может прочитать, что угодно, а писатель также в праве перетирать чьи угодно записи. Такое можно написать на любом языке программирования общего назначения, наверное на эрланге будет меньше букавок, но приниципиальной разницы тут нет.
Ключевые слова (Paxos, Raft, Vector Clocks, CRDT, etc), которые мелькают в инженерных блогах и докладах разработчиков подобных решений, не имеют отношения к эрлангу и пишутся на любом ЯП. Ведь организовать распаковку байтов, полученных из сокета в структуру данных, которая потом засовывается в нужный алгоритм, можно написать на чем угодно. Проблемы распределенных систем (по Лэсли Лампорту) ни один из общеизвестных языков в 2015 не решает и это факт жизни
A distributed system is one in which the failure of a computer
you didn't even know existed can render your own computer
unusable.
В остальном же
Эрланг может как-то и делает передачу сообщений между процессами, разделенными сетевым интерфейсом проще, но в 2015 эта проблема решена библиотеками везде, где применяется сетевое программирование.
Запуск/перезапуск процессов при желании тоже можно написать в упрощенном виде, а дальше и не нужно. Ведь если же у вас система разваливается по 20 раз на дню, то долго это продолжаться не будет и скорее всего скоро от вас уйдут и клиенты, а в месте с ними уйдут и деньги
Хот деплой это супер экспертная фича, которую можно давать только после того, как команда научилась делать обновления без остановки всех серверов сама (если это вообще имеет смысл для данной системы), а иначе в современных реалиях это превратится в "фигак-фигак и в продакшен".
S>Можете раскрыть тему: что в Erlang-е, не важно в языке ли, в платформе ли, обеспечивает real-time-овые гарантии, хотя бы софтовые? И почему вы считаете, что реалтаймовость в других языка (в частности в C, в C++, в Modula-2, в Ada) находится в зачаточном состоянии?
Можете раскрыть тему: почему вы берете ровно одно из всего списка?
JDV>По сути, Эрланг выступает в виде современного Лиспа То, что было когда-то в Лиспе постепенно переползло в мейнстрим. Сейчас то, что есть в Эрланге тоже медленно переползает в мейнстрим Плюс концепции, заложенные в Эрланг, доказали, что они работают. Причем настолько, что чуваки, разрабатывающие распределенные базы данных, открыто говорят, например, что они стараются пользоваться только тем, что доступно в стандартной поставке Erlang'а — в 99% случаев этого более, чем достаточно.
JDV>1% процент это видимо проблема консенсуса в распределенной системе, которая не решается эрлангом.
Нет, не видимо. Все остальные мысьи по древу, вытекающие из попытки что-то телепатировать, скипнуты.
JDV>
JDV>Эрланг может как-то и делает передачу сообщений между процессами, разделенными сетевым интерфейсом проще, но в 2015 эта проблема решена библиотеками везде, где применяется сетевое программирование.
Не как-то. И не только передачу. Подавляющее большинство библиотек, как тут уже выяснили, упирается строго в «создать миллион корутин». Остальные библиотеки — это, я так понимаю, Кафка и прочие сотоварищи. Ну-ну. Хорошее «решение».
JDV>Запуск/перезапуск процессов при желании тоже можно написать в упрощенном виде, а дальше и не нужно. Ведь если же у вас система разваливается по 20 раз на дню, то долго это продолжаться не будет и скорее всего скоро от вас уйдут и клиенты, а в месте с ними уйдут и деньги
При желании. Можно нписать. В упрощенном виде. Ага-ага. Свежо предание, только нифига не существует.
JDV>Хот деплой это супер экспертная фича, которую можно давать только после того, как команда научилась делать обновления без остановки всех серверов сама (если это вообще имеет смысл для данной системы), а иначе в современных реалиях это превратится в "фигак-фигак и в продакшен".
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Состояние то зачем сериализовать? Сейчас как то стараются без состояния в памяти между вызовами обходиться. И если оно все же нужно, то хранят его в сессии, а сессия связана с системными сборками, которые перегружать не надо. Поэтому перегрузка прикладной сборки состояние не затрагивает и никаких сериализаций не нужно.
Это как так????
Предположим, что у нас доисторический код, без новомодных фишек типа сохранения состояния конечного автомата в замыканиях, а просто в конце нашего RequestHandler мы пишем что-то типа Session["ShoppingCart"] = cartContents; а в начале следующего, ессно, var cartContents = (ShoppingCart)Session["ShoppingCart"];.
Ну так это же и есть, дословно, сериализация/десериализация, разве нет?
А если мы попробуем реализовывать переходы автомата в замыканиях, то у нас внезапно вместо рукописных классов типа ShoppingCart возникнут сгенерированные классы для замыканий, которые умением сериализовываться не оборудованы. Каким образом удастся подменить их реализацию между обращениями клиента — я вообще не понимаю.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это отдельный вопрос как там живет игровой мир. Держать в памяти большие игровые миры на каждого клиента — отличный способ отстрелить себе ногу. EP>>А зачем его держать на каждого клиента? Он один общий на всех НС>Для этого потребуется уникальный рантайм как минимум. Ну и общий на всех прямо в памяти — тоже хороший способ отстрела ноги.
А где ты предлагаешь его хранить? В СУБД?
Конкретный пример — есть общая арена на которой происходит сражение, например что-то типа того же Quake или Starcraft.
Здравствуйте, so5team, Вы писали:
S>Смотря на каких задачах. Если в ситуациях, когда все 100K нитей готовы к работе и нуждаются в кванте процессорного времени, то еще более интересно, как с такой ситуацией будет справляться расхваливаемый здесь Erlang.
Такая ситуация — это ошибка дизайна, на более-менее любой системе. Поясню очевидное:
1. нам вообще известно не очень много параллельных алгоритмов. Большинство алгоритмических решений известных нам задач построены на пошаговом исполнении с модификацией состояния — см. например алгоритм Евклида. Его в принципе распараллелить нельзя никак, т.к. каждый следующий шаг зависит от предыдущего.
2. в тех редких случаях, когда мы можем поделить задачу на относительно независимые подзадачи, выигрыш в принципе достижим только в тех случаях, когда у нас есть доступные для этого ядра. Не обязательно делить задачу ровно на столько частей, сколько есть ядер — для выравнивания нагрузки может иметь смысл задать гранулярность примерно на порядок мельче. Тем не менее, попытка вычислить 100К микрозадач на 4х ядрах — это в чистом виде нагревание атмосферы и замедление работы.
3. Даже для случая, когда у нас есть неограниченное количество ядер, эффективных решений не существует. Простой пример: если у вас есть 100К ядер, то сортировка массива целых чисел длиной в 100К элементов, размазанная на всех, окажется медленнее, чем размазанная на 1000 ядер. Это для наиболее дружественного к паралелльности среди известных человечеству алгоритмов сортировки.
Итак, человека, порезавшего тяжёлую вычислительную задачу на 100К мелких задач, нужно увольнять за профнепригодность. По крайней мере, пока. Вопросы оптимизации шедулинга такого количества задач пока что относятся к категории теоретических исследований, а не прикладной инженерии.
В реальной жизни 100К одновременно выполняемых задач связаны с ожиданием. И вот тут аппаратные реализации многозадачности сосут со страшной силой. Вот вы по соседству приводили пример, который на 100К нитей сожрал 7GB памяти. Отличная иллюстрация непригодности механизмов ОС: ожидание ответа от каждого клиента отжирает 70kb накладных расходов. А ведь это — расходы электроэнергии, вытеснение из кэша, и замедление рестарта сервера при failover. Не говоря уже о том, что нам внезапно нужно докупать лишнюю память — потому что типичный размер состояния микрозадачи, которая нам нужна для продолжения исполнения — это десятки байт. Никакая аппаратура неспособна нам предложить ничего интереснее стековой архитектуры, которая жрёт память и адресное пространство как не в себя. Потому что она по необходимости тупая, и неспособна адаптировать код вытеснения под специфику задачи.
S>Покажите, пожалуйста, что для этих целей предназначен Erlang.
Я уже показывал, как HTTP-сервер на динамическом Эрланге держит нагрузку наравне с передовиками, написанными на C.
При этом идиоматичная реализация в традиционной архитектуре, ака Apache, вообще сосёт с т.з. производительности сильнее промышленного пылесоса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
S>>Можете раскрыть тему: что в Erlang-е, не важно в языке ли, в платформе ли, обеспечивает real-time-овые гарантии, хотя бы софтовые? И почему вы считаете, что реалтаймовость в других языка (в частности в C, в C++, в Modula-2, в Ada) находится в зачаточном состоянии?
M>Можете раскрыть тему: почему вы берете ровно одно из всего списка?
1. Вы сами настаиваете на важности всех элементов приведенного вами списка
Поэтому для того, чтобы реализовать весь функционал, что есть в Эрланге, вам нужно как минимум вот что...
...В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии
Т.е. не какого-то набора из элементов списка, а всех элементов. Следовательно, ваша картина мира базируется на уверенности, что все элементы вашего списка актуальны для Erlang-а. И эта картина будет разрушена, если это не так.
2. Где ответ на вполне конкретный вопрос? Знаете -- отвечайте, не знаете -- вычеркивайте данный пункт.
Здравствуйте, Sinclair, Вы писали:
S>>Смотря на каких задачах. Если в ситуациях, когда все 100K нитей готовы к работе и нуждаются в кванте процессорного времени, то еще более интересно, как с такой ситуацией будет справляться расхваливаемый здесь Erlang. S>Такая ситуация — это ошибка дизайна, на более-менее любой системе. Поясню очевидное:
В сухом остатке получается, что возможность Erlang-а создать 100K процессов является лишь маркетинговой фишкой, которая далеко не всегда будет востребована на практике.
S>>Покажите, пожалуйста, что для этих целей предназначен Erlang. S>Я уже показывал, как HTTP-сервер на динамическом Эрланге держит нагрузку наравне с передовиками, написанными на C. S>При этом идиоматичная реализация в традиционной архитектуре, ака Apache, вообще сосёт с т.з. производительности сильнее промышленного пылесоса.
Не помню, чтобы я видел ваш пример. Но пусть будет так. При обработке HTTP запросов Erlang заруливает Apache, который уже лет 15 считается одним из самых тормознутых HTTP-серверов. Один пример есть. Еще будут?
Здравствуйте, vdimas, Вы писали:
V>Асинхронные мьютексы ставят раком всю аснхронность. V>Собсно, как синхронные мьютексы ставят раком вытесняющую многозадачность. V>И точно так же на асинхронных мьютексах возможен тот самый дедлок. V>Асинхронный мьютекс делает ровно одно — task reordering, то бишь пуляет продолжение текущего кода в конец очереди вычислений. Вот так два асинхронных мьютекса и будут бесконечно пулять две задачи при асинхронном дедлоке. V>И это при том, что асинхронщина толкается как инструмент №1 для избавления от дедлоков, ы-ы-ы.
Правильно. Потому ручная диспетчеризация асинхронного кода — адский АДъ. В многопоточном коде ты можешь остановить все потоки и глянуть, что же там не так. В асинхронном коде у тебя такого фокуса нет. И многих других — тоже нет.
I>>Собственно я сейчас уперся именно в такие кейсы и всё дело идет замене на чтото более серьезное. V>Еще пару лет назад тебя приглашали озвучить ТЗ. Ты так и не сподобился.
Да, я помню "любой студент за пару часов", когда реально любая внятная асинхронная либа в JS это практически всегда хардкор.
V>А изобретателей асинхронных мьютексов вменяемые разработчики давно послали туда, где им место. V>Это же надо было, вместо того, чтобы создать нужные зависимости, додуматься тупо отпуливать таски в конец очереди... бррр... ))
Не только не послали, но и активно развивают это направление. Ибо — дёшево.
А что еще тогда задачи нужно решать для создания распределенной базы данных? Доступ системным вызовам для работы с файловой системой у Эрланга наверное есть...
Что из стандартной поставки эрланга мне нужно использовать, если я хочу реализовать репликацию машины состояний? Paxos из коробки там есть?
M>Не как-то. И не только передачу. Подавляющее большинство библиотек, как тут уже выяснили, упирается строго в «создать миллион корутин». Остальные библиотеки — это, я так понимаю, Кафка и прочие сотоварищи. Ну-ну. Хорошее «решение».
Задача «создания миллиона корутин» лишена смысла т.к. это техническая деталь работы отдельной платформы — если в эрланге, чтобы обработать поток из N сообщений, нужно обязатательно создать N эрланговских «процессов», то это не означает, что для решения такой же задачи на другом ЯП нужно также копировать решение на эрланге.
А Kafka это очередь, которую написали в Linkedin(?) что ли? Если да, то тогда ее нужно сравнивать с Rabbitmq, а не эрлагом.
M>
JDV>>Запуск/перезапуск процессов при желании тоже можно написать в упрощенном виде, а дальше и не нужно. Ведь если же у вас система разваливается по 20 раз на дню, то долго это продолжаться не будет и скорее всего скоро от вас уйдут и клиенты, а в месте с ними уйдут и деньги
M>При желании. Можно нписать. В упрощенном виде. Ага-ага. Свежо предание, только нифига не существует.
Различные схемы failover-а люди и без эрланга реализовывают.
Здравствуйте, so5team, Вы писали:
S>В сухом остатке получается, что возможность Erlang-а создать 100K процессов является лишь маркетинговой фишкой, которая далеко не всегда будет востребована на практике.
Нет. В сухом остатке получается, что возможность Erlang-а создать 100К процессов является полезнейшим инструментом для разработки современных сетевых приложений, которая остро востребована на практике.
Под сетевым приложением понимается приложение, в котором есть разделяемое состояние, и массовое количество территориально распределённых клиентов.
Поэтому эрланг рулит в тех местах, где много коммуникаций. Например, объём кода Yaws примерно втрое меньше, чем у сишного NGinx — при сравнимых характеристиках производительности.
S>Не помню, чтобы я видел ваш пример. Но пусть будет так. При обработке HTTP запросов Erlang заруливает Apache, который уже лет 15 считается одним из самых тормознутых HTTP-серверов. Один пример есть. Еще будут?
Конечно. Попробуйте написать код GSM-switch на С++.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Ну и еще в Windows 16 работали перывания прямо в юзверском коде )) V>Поэтому, если твоя прога сидела на прерываниях, то эти прерывания тоже как-то обыгрывались: либо ресурсы защищались теми же критическими секциями, либо для какого-то участка кода запрещались прерывания.
Ты наверное с ДОС попутал. В Win16, по моему, прикладной код не имеет доступа к прерываниям.
I>>Как так, ведь в кооперативной многозадачности "гонок нет"
V>В Windows 16 (если ты о ней) кооперативный шедулер срабатывал на КАЖДЫЙ вызов системного АПИ, наверно в этом дело?
Это не важно.
V>Т.е., ты пытаешься сравнить ситуацию, когда ты вручную расставляешь точки переключений задач с ситуацией, когда у тебя эти точки переключения задач расставлены даже в тех местах, где ты бы НЕ ХОТЕЛ, чтобы переключение произошло.
Переключение делается само, внутри нода того же. Все что мне надо — связывать.
V>В базе жабаскрипта есть вполне детерминированная однопоточная модель вычислений — ты можешь пользоваться знаниями об этом.
Этого недостаточно, что бы все программы обладали детерминированым поведением. Время, например, никуда не девается.
V>Но в жабаскрипте для обеспечения детерминированности достаточно, чтобы м/у точками (1) и (2) не произошло переключения задач. Т.е. не вставляй м/у точками (1) и (2) никаких await/yield и всех делов.
И наверное ты посоветуешь использовать синхронное АПИ нода, а когда не хватит производительности — перейти на С++, а заказчику сказать, что уже решенная задача на самом деле не стоит того, что бы над ней работать ?
V>Если же ты м/у этими точками вставляешь инструкции переключения потоков, то твоя недетерминированность создана искусственно, т.е. является эмуляцией недетерминированности с помощью детерминированного инструмента.
Весь интересный функционал асинхронный до самого дна. сеть, файловая система, бд и тд. У них своё время, не такое как у VM джаваскрипта. То есть, уже просто http.get вносит неопределенность, потому что это внешний, то есть, time-bound фактор. Любой функционал OS, база данны — ровно то же.
В этом плане правильно эмулировать IO не через setTimeout(fn, 1000) а вот так setTimeout(fn, Math.random(10*1000))
I>>У тебя плохой пример. Раздели чтение переменной и запись на две операции. Внезапно, обнаруживаем инвариант — поток затирает ровно то значение, которое перед этим прочёл.
V>Да, но где здесь недетерминированность?
http.get, filesystem.readFile, database.execute. Нет и никогда не будет функционала навроде "в какое место очереди эвентлупа вставить колбек респонса http.get"
V>Пример тоже полностью детерминированный. Ты можешь полагаться на значение локальной переменной x1, но уже не можешь полагаться на значение x после ручного переключения потоков на await.
Пример детерминированый, но полагаться нельзя
Детерминированый, это когда можно точно сказать, что на что изменится и в каком случае.
V>Слава те хосподя, об этом и пример ))
Посмотри внимательно — я про это и говорю что два года назад, что сейчас.
I>>И именно эта последовательность ломает состояние. То есть, гонки налицо. Видишь их?
V>Для случая С++? Конечно, это же был мой пример.
I>>Теперь твой пример на JS, вместо потока — задача. Что читаем i и записываем отдельно. I>>Запускаем один таск — никаких нарушений инварианта нет, всё шоколадно. I>>Запускаем второй таск, опаньки — инвариант ломается.
V>Ну он же не сам поломался, это ты специально, ручками, сделал так, чтобы переменные i и actual изменялись/проверялись в РАЗНЫХ циклах запуска жабаскрипта. А ты сделай так, чтобы эти переменные изменялись в рамках одного цикла запуска скрипта и всё будет ОК.
Пример доказывает существование проблемы которую ты отрицал два года Как переписать — абсолютно не важно.
I>>Здесь, внимание, порядок выполнения зависит исключительно от того, в какой момент стартовал новый таск.
V>Да похер, сорри.
Это не так. Если правильно угадать время, инвариант ломаться не будет. Можешь поэкспериментировать, выбери задержки побольше и всё.
V>Ты НЕ можешь полагаться на значение переменных, оставшихся с прошлого запуска, потому что тебе недоступна история этих прошлых хапусков, не предоставляет жабаскрипт такой инфы, ты можешь полагаться на значения переменных, прочитанных в рамках текущего запуска.
Ну вот, ты узнал, откуда в асинхронном коде недетерминизм
1. время
2. история
3. глубина ветвления
количество прерываний по каждой ветке зависит от 1.2.3
V>Ты вообще смотрел мой пример? Не обратил внимание на такой момент:
Они абсолютно идентичны. Ну разве что ты в каждом примере хочешь показать всё сразу, на все возможные темы.
I>>И если два потока пишут в один файл, не важно, логических или физических, результат может быть недерминирован.
V>Ну так открывай файл с исключительным доступом, елки. И не шарь владение хендлом на файл.
У меня нет никаких хендлов. речь про последовательность транзакций вида "open-append-close"
Каждая такая транзакция нигде не прерывается, но последовательность таких вот транзакций зависит, скажем, от того, какой респонс вернулся первым — от бд или от нетворка.
I>>Это, в частности, проявляется в том, что содержимое файла при одном запуске будет "111222" а во втором случае "121212" а в третьем "122211"
V>Ну это согласно ТЗ так или из-за ошибок в коде?
Это за того самого недетерминированого порядка выполнения. Смотри внимательно мой пример.
Здравствуйте, Joie de vivre, Вы писали:
JDV>Задача «создания миллиона корутин» лишена смысла т.к. это техническая деталь работы отдельной платформы — если в эрланге, чтобы обработать поток из N сообщений, нужно обязатательно создать N эрланговских «процессов», то это не означает, что для решения такой же задачи на другом ЯП нужно также копировать решение на эрланге.
Не "нужно", а "можно". Обработка сообщения в отдельном потоке — это естественная реализация интуитивно понятных алгоритмов.
На "другом ЯП" нужно отказаться мыслить терминами реализуемого вами RFC, а заниматься epoll, рукопашным написанием и отладкой конечных автоматов, бороться с race condition и проездами по памяти, возвращаться к уже написанным местам, потому что при 100К параллельных реквестов выбранная вами в прошлый раз архитектура складывает ласты в интересные фигуры, и т.п.
JDV>Различные схемы failover-а люди и без эрланга реализовывают.
Вы, судя по всему, не вполне понимаете, что такое failover, и что есть для этого в эрланге.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>В сухом остатке получается, что возможность Erlang-а создать 100K процессов является лишь маркетинговой фишкой, которая далеко не всегда будет востребована на практике. S>Нет. В сухом остатке получается, что возможность Erlang-а создать 100К процессов является полезнейшим инструментом для разработки современных сетевых приложений, которая остро востребована на практике.
В Erlang-е.
В других языках это делается другими средствами.
S>Поэтому эрланг рулит в тех местах, где много коммуникаций. Например, объём кода Yaws примерно втрое меньше, чем у сишного NGinx — при сравнимых характеристиках производительности.
А откуда данные по производительности?
Ну и еще интересно, почему огромное количество сайтов работает на nginx, а о Yaws говорят только Ыксперты на RSDN-е? Может количество строк и язык программирования к качеству/успешности/востребованности продукта не имеет отношения?
S>>Не помню, чтобы я видел ваш пример. Но пусть будет так. При обработке HTTP запросов Erlang заруливает Apache, который уже лет 15 считается одним из самых тормознутых HTTP-серверов. Один пример есть. Еще будут? S>Конечно. Попробуйте написать код GSM-switch на С++.
Это намек на AXD301? Так ведь Ericsson не смог написать его без С и C++, что характерно.
А другие производители телекомоского оборудования, скажем, Alcatel, не использовали в своих продуктах Erlang, зато C++ использовали.
Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике.
Здравствуйте, Sinclair, Вы писали:
S>На "другом ЯП" нужно отказаться мыслить терминами реализуемого вами RFC, а заниматься epoll, рукопашным написанием и отладкой конечных автоматов, бороться с race condition и проездами по памяти, возвращаться к уже написанным местам, потому что при 100К параллельных реквестов выбранная вами в прошлый раз архитектура складывает ласты в интересные фигуры, и т.п.
Sinclair, выньте наконец голову из убогого .NET-овского мирка. Посмотрите хотя бы на Scala+Akka или на то, что LinkedIn делает вообще на голой Java. Те мифические драконы, которыми вы пугаете читателей форума, существуют только у вас в мозгах.
Здравствуйте, so5team, Вы писали: S>А откуда данные по производительности?
Ещё раз: http://joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/
S>Ну и еще интересно, почему огромное количество сайтов работает на nginx, а о Yaws говорят только Ыксперты на RSDN-е? Может количество строк и язык программирования к качеству/успешности/востребованности продукта не имеет отношения?
Конечно. Никакие технические характеристики не имеют отношения к успешности и востребованности. Потому что к примеру тот же Nginx в разы проигрывает Апачу.
Из чего, конечно же, никак не следует то, что Апач не сосёт. Поэтому давайте мы выбросим вопросы "востребованности" и "распространённости" из технической дискуссии, ок?
S>Это намек на AXD301? Так ведь Ericsson не смог написать его без С и C++, что характерно.
Ага. И я о том же.
S>Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике.
У вас есть какие-то замеры производительности, чтобы доказать это утверждение? А то вот в области HTTP порвать тормозной Эрланг способны очень немногие из "статически типизированных" решений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Приводя в 2015-ом году данные замеров от 2009-го года вы рассчитываете, что вас будут принимать сколько нибудь всерьез?
S> Потому что к примеру тот же Nginx в разы проигрывает Апачу.
Ну вы бы на динамику обратили внимание. Nginx появился намного позже Apache и свою долю постоянно увеличивает. В отличии от Yaws на расхваливаемом здесь Erlang-е.
S>>Это намек на AXD301? Так ведь Ericsson не смог написать его без С и C++, что характерно. S>Ага. И я о том же.
О чем же? Софт для телекома пишут на C++ без Erlang-а давно и успешно.
S>>Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике. S>У вас есть какие-то замеры производительности, чтобы доказать это утверждение?
Нет, публично доступных в Web-е нет.
S> А то вот в области HTTP порвать тормозной Эрланг способны очень немногие из "статически типизированных" решений.
Здравствуйте, so5team, Вы писали:
S>Sinclair, выньте наконец голову из убогого .NET-овского мирка. Посмотрите хотя бы на Scala+Akka или на то, что LinkedIn делает вообще на голой Java.
Я посмотрел. Если у вас есть пример более шустрого HTTP-сервера на "голой Java", чем MochaWeb, то мы можем попытаться найти для него метрики производительности.
Потому что MochaWeb как-то не впечатляет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
