Почему вы решили "против" использования Эрланга?

мы используем Haskell, OCaml и (теперь) F# поэтому для нас это не имеет ничего общего с отсутствием c-подобного синтаксиса. Скорее мы пропустим Эрланг, потому что:

• он динамически типизирован (мы поклонники системы типов Haskell)
• не дает "реальный" тип строки (Я понимаю, почему, но это раздражает, что это не было исправлено на уровне языка)
• имеет тенденцию иметь плохие (неполные или неподдерживаемые) драйверы базы данных
• это не батареи включены и, похоже, нет сообщества, работающего над исправлением этого. Если это так, то он не очень заметен. Хаскелл, по крайней мере, был здесь, и я предполагаю, что это то, что нас выбрали, что язык на любой другой. В средах Windows F# собирается иметь окончательное преимущество здесь.

вероятно, есть и другие причины, о которых я сейчас не могу думать, но это основные моменты.

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

несколько недель назад я прочитал анти-Erlang blog rant, и одна из критических замечаний автора Erlang заключается в том, что он не мог понять, как заставить функцию возвращать другое значение каждый раз, когда он вызывал ее с теми же аргументами. Чего он действительно не понял, так это того, что Эрланг нарочно так себя ведет. Вот как Erlang удается так хорошо работать на нескольких процессорах без явная блокировка. Чисто функциональное программирование-это программирование без побочных эффектов. Вы можете arm-twist Erlang в работу, как хотел наш разглагольствующий блоггер, добавляя побочные эффекты, но при этом вы отбрасываете ценность, которую предлагает Erlang.

чистое функциональное программирование-это не единственный правильный способ программирования. Не все должно быть математически строгим. Если вы определяете, что ваше приложение будет лучше всего написано на языке, который неправильно использует термин "функция", лучше вычеркнуть Erlang ваш список.

Я уже использовал Erlang в нескольких проектах. Я часто использую его для спокойных услуг. Однако я не использую его для сложных интерфейсных веб-приложений, где такие инструменты, как Ruby on Rails, намного лучше. Но для воротила за кулисами, я не знаю лучшего инструмента, чем Эрланг.

Я также использую несколько приложений, написанных на Erlang. Я использую CouchDB и RabbitMQ немного, и я установил несколько серверов EJabberd. Эти приложения являются самыми мощными, простыми и гибкими инструменты в своей области.

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

PS: после прочтения моего комментария обратно в контексте я заметил, что это выглядело, как я называл oxbow_lakes a код обезьяны. Я действительно не был и извиняюсь, если он так это воспринял. Я обобщал о типах программистов, и я бы никогда не назвал человека таким отрицательным именем, основанным на одном его комментарии. Он, вероятно, хороший программист, хотя я призываю его не делать JVM каким-то прерывателем сделки.

пока у меня нет, другие в интернете есть, например

мы исследовали относительные достоинства C++ и Erlang в реализации параллельной трассировки акустических лучей алгоритм для ВМС США. Мы нашли гораздо меньшая кривая обучения и лучшая среда отладки для параллельный Эрланг чем для программирование на C++ на основе pthreads. Наш Реализация C++ лучше Программа Erlang по крайней мере в 12 раз. Попытки использовать Erlang в ячейке IBM БЫТЬ микропроцессор был разочарован След в памяти Эрланга. (источник)

и что-то ближе к моему сердцу, что я помню, читая назад после конкурса ICFP:

кодирование было очень простым, перевести псевдокод на C++. Я могли бы использовать Java или C#, но я в точка, где программирование на высоком уровне уровень в C++ так же просто, и я хотел сохранить за собой возможность быстро падение в какой-то низкий уровень если бы дело дошло до этого, то я бы немного покрутился. Эрланг-мой другой любимый язык для взлома вокруг, но волновался о какой производительности проблема, которую я не мог вытащить сам от себя. (источник)

для меня тот факт, что Erlang динамически типизирован, это то, что заставляет меня насторожиться. Хотя Я do используйте динамически типизированные языки, потому что некоторые из них просто очень ориентированы на проблемы (возьмите Python, я решаю с ним много проблем), я бы хотел, чтобы они были статически типизированы.

тем не менее, я на самом деле намеревался дать Эрлангу попробовать в течение некоторого времени, и я только начал загружать источник. Так что ваш "вопрос" все-таки чего-то достиг. ; -)

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

ряд причин:

• потому что он выглядит чужеродным от любого, кто привык к семейству языков C

• потому что я хотел иметь возможность работать на Виртуальная Машина Java чтобы воспользоваться инструментами, которые я знал и понимал (например, JConsole) и годы усилий, которые пошли в JIT и GC.

• потому что я не хотел переписывать все библиотеки (Java), которые я создал над годы.

• потому что я понятия не имею об "экосистеме" Erlang (доступ к базе данных, конфигурация, сборка и т. д.).

в основном я знаком с Java, его платформой и экосистемой, и я вложил много усилий в создание материала, который работает на JVM. Это было намного проще чтобы перейти к scala

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

использовал его для шлюза сообщений для проприетарного, многоуровневого, двоичного протокола. Шаблоны OTP для серверов и отношений между службами, а также сопоставление двоичных шаблонов сделали процесс разработки очень простым. Для такого случая использования я бы, вероятно, снова предпочел Эрланг другим языкам.

JVM-это не инструмент, это платформа. Хотя я все за то, чтобы выбрать лучший инструмент для работы, платформа в основном уже определена. Если я не разрабатываю что-то автономное, с нуля и без желания повторно использовать любой существующий код/библиотеку (три аспекта, которые вряд ли уже изолированы), я могу быть свободен в выборе платформы.

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

Сильвио

хотя мне нравились многие аспекты дизайна среды выполнения Erlang и платформы OTP, я обнаружил, что это довольно раздражающий программный язык для разработки. Запятые и точки полностью хромают, и часто требуется переписать последний символ многих строк кода, чтобы изменить одну строку. Кроме того, некоторые операции, которые просты в Ruby или Clojure, утомительны в Erlang, например обработка строк.

для распределенных систем, использующих общую базу данных, система Mnesia является действительно мощный и, вероятно, хороший вариант, но я программирую на языке, чтобы учиться и получать удовольствие, и раздражающий фактор Эрланга начал перевешивать фактор удовольствия, как только я прошел основные учебные пособия по банковскому счету и начал писать плагины для сервера XMPP.

Я люблю Erlang с точки зрения параллелизма. Эрланг действительно сделал параллелизм правильно. Я не использовал erlang в первую очередь из-за синтаксиса.

Я не программист по профессии. Я обычно использую C++, поэтому я жажду своей способности переключаться между стилями (ООП, императив, Мета и т. д.). Мне казалось, что Эрланг заставляет меня поклоняться священной корове непреложных данных.

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

совсем недавно я обнаружил, что язык программирования D предложения параллелизм стиля Erlang С привычным синтаксисом в стиле C и мультипарадигменный язык. Я еще не пробовал ничего массового одновременного С D, поэтому я не могу сказать, является ли это идеальным переводом.

поэтому профессионально я использую C++ , но делаю все возможное, чтобы моделировать массово параллельные приложения, как я бы в Erlang. В какой-то момент я хотел бы дать D инструменты параллелизма реальный тест-драйв.

Я даже не собираюсь смотреть на Эрланга.

два сообщения в блоге прибили его для меня:

1. Erlang machinery проходит весь список, чтобы выяснить, есть ли у них сообщение для обработки, и единственный способ получить сообщение означает прохождение всего списка (я подозреваю, что фильтрация сообщений по pid также включает в себя прохождение всего сообщения список)

   http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang

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

   erlang - как ограничить очередь сообщений или эмулировать ее?

оба (1) и (2) намного ниже наивны в моей книге, и я уверен, что внутри Erlang machinery есть больше программных "драгоценных камней" аналогичной природы.

Итак, для меня нет Эрланга.

похоже, что как только вам придется иметь дело с большой системой, которая требует высокой производительности при перегрузке C++ + Boost по-прежнему является единственной игрой в город.

Я собираюсь посмотреть на D далее.

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

проблема была в том, что мы должны поставить наше приложение на нескольких платформах: Linux, Solaris и AIX, и, к сожалению, на данный момент нет установки Erlang для AIX.

будучи небольшой операцией исключает усилия в портировании и поддержании версии AIX Эрланг, и просить наших клиентов использовать Linux для части нашего приложения не идет.

Я все еще надеюсь, что AIX Erlang прибудет, чтобы мы могли его использовать.