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

По ряду причин:

• Потому что это выглядит чуждым для тех, кто привык к семейству языков C

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

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

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

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

Ахх, товарищ Ада путешественник я вижу.

Единственный реальный способ сделать это в C++ - объявить классы. Что-то вроде:

class first_100 {
public:
    explicit first_100(int source) {
        if (source < 1 || source > 100) {
           throw range_error;
        }
        value = source;
    };
    // (redefine *all* the int operators here)
private:
    int value;
};

Необходимо определить конструктор int явным образом , чтобы C++ не использовал его для неявного преобразования между типами. Таким образом, это не будет работать:

first_100 centum = first_100(55);
int i = centum;

, но что-то подобное может быть (если вы его определите):

int i = centum.to_int();

Битовые столбцы обычно используются для представления значений типа T/F или Y/N, по крайней мере, в SQL Server. Хотя пурист базы данных может сказать вам, что столбцам Bit нет места в базах данных, потому что они "слишком близко к оборудованию" - Джо Селко.

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

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

Сильвио

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тем не менее, я действительно собирался некоторое время попробовать Erlang и только что начал скачивать исходный код. Значит, ваш «вопрос» все-таки чего-то достиг. ; -)

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

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

Пока я этого не делал, в других интернет-ресурсах есть, например

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

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

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