Производительность F # против производительности Erlang, есть ли доказательства, что виртуальная машина Erlang работает быстрее?

Я потратил время на изучение функционального программирования и пришел к той части, где я хочу начать писать проект, а не просто копаться в уроках / примерах.

Проводя свои исследования, я обнаружил, что Erlang кажется довольно мощным, когда речь идет о написании параллельного программного обеспечения (что является моей целью), но ресурсы и инструменты для разработки не так развиты, как продукты разработки Microsoft.

F # может работать на Linux (Mono), так что это требование выполнено, но, просматривая Интернет, я не могу найти сравнения F # и Erlang. Прямо сейчас я склоняюсь к Erlang только потому, что он, кажется, имеет наибольшее давление, но мне любопытно, есть ли действительно разница в производительности между этими двумя системами.

Так как я привык к разработке на .NET, я, вероятно, смогу освоить F # намного быстрее, чем Erlang, но я не могу найти никакого ресурса, чтобы убедить меня, что F # так же масштабируем, как Erlang.

Меня больше всего интересует симуляция, которая будет запускать много быстро обрабатываемых сообщений постоянным узлам.

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

Что вы подразумеваете под "жизнеспособным?" «Больше всего прессы» не обязательно лучший способ выбрать язык.

Утверждение Эрланга о славе заключается в его способности к массовому распараллеливанию. Вот почему он обычно используется в телефонных коммутаторах Ericsson. Erlang работает в режиме реального времени, поэтому вы можете дать определенные гарантии производительности.

F # извлекает выгоду из возможностей оптимизации .NET Jitter. Кроме того, сам язык разработан, чтобы быть высокопроизводительным функциональным языком (это вариант OCaml, широко используемый в финансовой индустрии из-за его скорости).

В конечном счете, если вы не планируете запускать миллионы крошечных агентов одновременно (для этого оптимизирован Erlang), F # должен быть в состоянии выполнить эту задачу.

На этой странице объясняются подходящие варианты использования для Erlang.

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

Единственный совет, который я могу дать, это то, что F # имеет преимущество в производительности системы статического типа, и CLR хорошо справляется с этой задачей, чтобы повысить производительность. F # имеет асинхронные агенты и передачу сообщений, но он не был оптимизирован, а синхронный код часто более чем в 10 раз быстрее.

Erlang имеет динамическую типизацию, что ставит его в существенный недостаток с точки зрения производительности (ожидайте гораздо большего количества бокса), но он был построен с нуля для поддержки быстрой передачи сообщений между асинхронными агентами, так что вполне может быть намного быстрее, чем эквивалентный F # , Тем не менее, у меня нет контрольных результатов, подтверждающих это: это всего лишь мое ожидание.

Кроме того, и Erlang, и F # являются относительно периферийными языками с небольшими сообществами, и из-за их различных целевых рынков люди, знакомые с обоими, встречаются редко. Единственный человек, о котором я могу думать, кто почти готовится - это Джеспер Луи Андерсен, но я не уверен, сколько F # он сделал.

Вы должны прочитать это сообщение Джо Армстронга: http://erlang.org/pipermail/erlang-questions/2012-Feb February/ 064277.html

Суть в том, что Эрланг не был разработан, чтобы быть быстрым! Во многих случаях это достаточно быстро, но это вторично по отношению к таким проблемам, как отказоустойчивость и стабильность.

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

Я также хотел бы отметить, что в ближайшие 6–9 месяцев, похоже, наблюдается бум в книгах по функциональному языку. Я знаю по крайней мере 4 на Erlang (включая мой), один на Haskell, а также названия на OCaml, Clojure и F #.