Haskell для сервера?
Что касается создания игрового сервера, кажется, что Erlang всегда является языком, который «создан для такого рода вещей» с его функциями масштабируемости и параллелизма. У меня нет опыта ни в Haskell, ни в Erlang, но на первый взгляд они кажутся одинаковыми. Заглянув в документацию Haskell, кажется, что он поддерживает многопроцессорную масштабируемость и параллелизм, а Haskell считается более надежным языком и имеет заметно лучшее сообщество. Тогда мой вопрос: считается ли Haskell таким же хорошим решением для построения серверов, как предположительно Erlang?
Haskell был определен в 1990 году. C++ также был разработан телекоммуникационными компаниями.
Ответы 8
Я уверен, что вы можете найти людей, которые так думают, но я думаю, что вы ошибаетесь насчет способности Erlang поддерживать такое использование; он широко используется в телефонных приложениях и на самом деле довольно надежен. Erlang в значительной степени оптимизирован для высоконадежных серверов с высоким уровнем параллелизма.
Думаю, меня немного смутил ваш ответ - вы сначала говорите, что я ошибаюсь, что Erlang можно использовать для чего-то вроде создания игрового сервера, а затем закончите, сказав, что он оптимизирован для работы с надежными параллельными серверами?
Вопрос о том, так ли хорош Haskell и Erlang, зависит от того, чего люди хотят от языка. Я думаю, что оба они вполне подойдут в качестве игрового сервера, но это в основном зависит от того, чего вы хотите или ожидаете от языка программирования. Одно из самых простых отличий заключается в том, что Haskell - это язык со статической типизацией с выводом типов, а Erlang - это язык с динамической типизацией. В целом, я бы сказал, что Haskell требует немного большей «сложности» для тех, кто не привык к функциональному программированию.
Это зависит от того, что вы хотите делать со своим сервером. Как и следовало ожидать от телекоммуникационного приложения, Erlang отлично справляется с простыми задачами с очень высокой степенью параллелизма. Если вашему серверу потребуется миллиард подключений в секунду или сразу, Erlang - ваш друг. Erlang также предлагает лучшую поддержку для распределения нагрузки между несколькими серверами.
Haskell превосходит сложные символьные вычисления и по состоянию на апрель 2009 г. также может обрабатывать большое количество потоков (см. Обновление ниже). Более того, в Haskell есть больше инструментов для правильного написания сложного кода: такие вещи, как Быстрая проверка, SmallCheck и система статических типов. Так что, если ваш сервер выполняет сложные, интересные вещи, и вы можете обойтись только одним сервером, вам, вероятно, будет лучше с Haskell.
Обновление от 13 апреля 2009 г.: Дон Стюарт, надежный источник, сообщает, что «последняя ошибка масштабирования потоков в компиляторе Glasgow Haskell была устранена несколько месяцев назад», и что некоторые пользователи сообщают об использовании миллиона потоков Haskell без проблем. По состоянию на январь 2009 г. существует новая, неопубликованная статья от разработчиков, который может описывать, как это достигается.
Обновление 21 февраля 2012 г.: Компания Джона Хьюза, QuviQ, теперь делает QuickCheck для Erlang. Они обнаружили ряд очень интересных ошибок. Вы можете скачать QuickCheck Mini бесплатно; он сравним с Haskell QuickCheck. Также есть более мощная коммерческая версия.
Можете ли вы привести доказательства в пользу своего утверждения о том, что Haskell быстрее ударится по тредам? Возможно, с потоками ОС ... но как насчет потоков Haskell?
мой пузырь Erlang немного лопнул, когда я увидел это: nabble.com/Chameneos.rednux-micro-benchmark-td19925134.html ... Я проверил результаты на своих ящиках, и они верны, похоже, есть огромная проблема с масштабируемостью SMP и обменом сообщениями. Реализация GHC работает намного лучше ...
@ja: Все мои доказательства получены из разговоров в коридоре с ребятами из Erlang и GHC в ICFP (icfpconference.org). Это правда, что ребята из GHC потратили последний год на подготовку к многоядерности и параллелизму, тогда как у меня сложилось впечатление, что Erlang сейчас находится в стадии коммерциализации.
Последняя (?) Проблема масштабирования потоков GHC была устранена несколько месяцев назад, и было несколько сообщений о более чем миллионе потоков без проблем. Тем не менее, Erlang уделяет больше внимания распределению, а не многоядерности с разделяемой памятью.
Думаю, я должен отметить, что в Erlang также есть Quickcheck, и он даже немного более развит, чем версия Haskell. И Erlang QC, и Haskell QC разрабатываются одним и тем же человеком, но теперь EQC стал даже коммерческим.
Это действительно хорошее резюме того, в чем хороши два соответствующих языка и в чем заключаются их сильные стороны.
Тесты этих документов показывают, что Haskell может конкурировать с Apache:
Разработка высокопроизводительного веб-сервера на Concurrent Haskell
- Саймон Марлоу
Объединение событий и потоков для масштабируемых сетевых служб:
Реализация и оценка Monadic,
Примитивы параллелизма на уровне приложения
- Пэн Ли Стефан А. Зданцевич (см. Рисунок 19)
К сожалению, статья Марлоу больше не является общедоступной.
Намного проще внести утечки памяти в ваше приложение Haskell из-за лени. Долгосрочные серверы - это точно программы, в которых вы В самом деле не хотите иметь утечек памяти.
Хотя я согласен с тем, что Haskell - более надежный язык и более приятный для программирования, Erlang намного проще и имеет множество библиотек, специально предназначенных для подобных целей.
Я не думаю, что существует эквивалент Haskell, скажем, Mnesia, и написать его будет сложно. Вы может пишете версии gen_server, gen_event и т. д. Для Haskell, но они не будут оптимизироваться и настраиваться более десяти лет.
Фактически, утечки памяти невозможно вызвать без использования FFI или чего-то подобного: вся память учитывается сборщиком мусора и может быть восстановлена. Вы имеете в виду «утечки пространства», что означает использование памяти для неоцененных преобразователей. Просто оцените их (или выбросьте) освободит память. Тем не менее, решение этой проблемы, поскольку она совершенно незнакома большинству программистов, сначала требует значительного объема работы, и вы должны спланировать ее.
Курт абсолютно прав, утечка пространства технически не то же самое, что утечка памяти, но они будут вести себя одинаково во многих программах, которые повторяются бесконечно. Я бы сказал, что много легче непреднамеренно ввести утечку пространства в программе Haskell, чем утечку памяти в программе C, поскольку это требует внимательного отношения к ленивому порядку оценки, который часто не интуитивно понятен. Тем не менее, я новичок в Haskell - полагаю, с практикой станет легче.
I don't have experience in either Haskell nor Erlang, but on the surface they seem the same.
Между Haskell и Erlang есть довольно существенные различия. Erlang специально разработан для параллельных систем. И язык, и виртуальная машина предназначены для поддержки многих, многих процессов, и Erlang использует систему акторского стиля для управления связью между ними. Haskell также довольно легко поддерживает параллелизм, из-за его функциональной природы, но, параллельное программирование на Haskell все еще немного сложнее, и язык специально не настроен для этого.
Как и Haskell, Erlang не разделяет состояние между процессами, поэтому легко писать многопроцессорное программное обеспечение. Но стиль программирования между Haskell и Erlang немного отличается, поскольку Erlang подчеркивает использование небольших процессов для выполнения параллельной обработки.
Я люблю Haskell - это один из моих любимых языков, но если бы я собирался писать серверное программное обеспечение, я бы, вероятно, использовал Erlang. Но, безусловно, можно написать сервер на Haskell, если вы знаете Haskell лучше или считаете, что поддержка библиотеки лучше.
> На самом деле это язык логического программирования. Нет, это не так. Нет встроенного поиска, вы не можете работать с неинициализированными переменными, без полной унификации и т. д. Синтаксис прологичен, и сопоставление с образцом позволяет использовать одну и ту же переменную слева (не справа!) , но это функционально.
Теперь появилась новая опция: используйте Haskell / Erlang FFI, чтобы написать свою логику на Haskell и общаться с помощью Erlang.
Haskell родился до Интернета. Erlang от телекоммуникационной компании.