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

Ответ 1

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

При работе на языке с сильной системой типов вы произвольно доказываете бесплатные теоремы о своем коде при каждом компиляции.

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

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

Но мне тяжело отказаться от защитного одеяла, которое, как обычно говорят, в Haskell, если оно выглядит, вероятно, правильно.

Ответ 2

Мы используем Haskell, OCaml и (теперь) F #, поэтому для нас это не имеет никакого отношения к отсутствию синтаксиса типа C. Скорее мы пропускаем Erlang, потому что:

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Мы исследовали относительные достоинства С++ и Erlang в реализации трассировки параллельного акустического луча алгоритм для ВМС США. Мы нашли гораздо меньшая кривая обучения и улучшенная среда отладки для параллельный Эрланг, чем для программирование на С++ на основе pthreads. наш Реализация С++ превзошла Эрланг по крайней мере 12 раз. Попытки использовать Erlang на IBM Cell BE были расстроены Эрланг памяти. (Источник)

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

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

Ответ 6

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

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

Ответ 7

Несколько причин:

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

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

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

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

Сильвио

Ответ 12

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

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

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

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

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

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

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

Теперь я буду смотреть на D.

Ответ 15

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

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

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

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