Вышел Erlang/OTP R15B

Вывод имени файла и номера строки в трассировке исключений

Здравствуй, тормоза!

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

Не прошло и ста лет. Но все равно, когда пишешь OTP Application и допускаешь ошибку в стартовых функциях, разобраться не возможно из-за объема выхлопа. Вот бы удобство разработки JVM + возможности BEAM VM совместить. Но идеального ничего не бывает.

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

Да уже не очень то и хотелось, лол.

Интересная штука. Как-то ковырял, но за неимением под рукой задачи бросил. Раньше про него говорили, мол, хайлоад только под ерлангом, тогда будешь успешным молодым человеком, два раза съездишь в Египет итд. А как, интересно, сейчас?

Официальная компания Ericson вроде как загнулась, уже года четыре в хайлоаде .NET используется.

Няшечка. Заценил GTKшный observer :-)

толсто же ну! Тоньше надо!

Ericsson загнулась? http://www.ericsson.com/

Это только в Sony-Ericsson Sony выкупила весь пакет акций у Ericsson.

А с хайлоудом надо просто правильно писать. Вон на infoq была презентация с трейдовым сервером на Java, и обработкой огромного (боюсь соврать, но 1 000 000 сек^(-1) вроде был) числа транзакций.

Вывод имени файла и номера строки в трассировке исключений

Нарешті! Ибо за$%ло.

Тихо! Спугнешь...

с более новой реализацией SSL.

А если еще годик поработаю с R14B и с более старой реализацией SSL - то я буду выглядеть как унылое говно и старпёр?

Когда они уже, нехорошие люди, стандартную библиотеку причешут?

Полезных функций регулярно не находится. Каждый раз смотрю на Haskell'евскую Prelude с жалобными глазами и в очередной раз изобретаешь велосипед а-ля my_utils:intersperse/2.

А что есть — закопано так, что можно даже похапэ-кодерам позавидовать. Для тех же строк все раскидано по трем, чтоб их, модулям, не считая re/regexp. Причем логика разнесения этого регулярно отсутствует (нет бы засунуть все в lists кроме того, что универсально и просится в erlang), а в именовании функций вряд ли есть такое явление как «консистентность».

чем это лучше Scala ? синтаксис и стд.библиотека - это ж ужасть...

чем это лучше Scala ?

imho подсказывает: Наверное, своей виртуальной машиной?

чем это лучше Scala ?

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

Синтаксис нормальный, пролог как пролог. На любителя, конечно. Я пописал несколько дней на ifene (петуноподобном синтаксисе для Erlang) и вернулся назад.

А Scala делит актеров на два сорта. Руками. И страдает всеми бедами JVM включая мусоросборник «остановите землю.» Хотя, с другой стороны, есть JIT и побогаче система типов.

Общего назначения — надо же было так нагло соврать.

BEAM — далеко не лучшая VM.

См. http://www.unlimitednovelty.com/2011/07/trouble-with-erlang-or-erlang-is-ghet...

Когда уже там неймспейсы будут?

Erlang isn't general purpose

Erlang hates state. It especially hates shared state. The only facility provided by the language for dealing with shared state in Erlang is called «Erlang Term Storage» and provides a Judy array that several Erlang processes can talk to. The semantics of ETS are fairly awkward and using it directly is difficult. Erlang has a baked-in database called Mnesia which is built on ETS. Mnesia's performance characteristics aren't great but it provides a friendlier face for ETS. These are the only solutions to shared state baked into the language.

What should you do if you want to deal with a shared-state concurrency program in Erlang? The general advice is: don't. Erlang isn't designed for solving shared-state concurrency problems. If you encounter a shared state concurrency problem while developing your Erlang program, sorry, you picked the wrong language. Perhaps you should move along... and Clojure offers you some great ways to tackle shared state concurrency problems.

Дальше этот бред читать не стал.

языка программирования общего назначения Erlang/OTP

Erlang - это же встроенный язычок какой-то телекоммуникационной платформы, не?

Дальше этот бред читать не стал.

А что конкретно не так?

языка программирования общего назначения
общего

Уже смешно!

Этот релиз впервые поддерживает 64 битную версию Windows.

о да, это успех

А че Lisp Works делает тут?)))

Замечательный язык!

Уже смешно!

На здоровье!

года четыре в хайлоаде .NET используется

в вашей шараге - это ваше дело

Shared state в эрланге вполне возможен как отдельный процесс, хранящий этот самый state, и раздающий его по запросу.

Два потока отправили потоку, хранящему стейт, запросы на изменение одних и тех же данных. Кто кроме Аллаха знает, в каком порядке они будут обработаны при этой дурацкой асинхронной архитектуре?

Если у тебя возникла такая ситуация, то это значит что не асинхронная архитектура дурацкая, а ты по дурацки спроектировал свое приложение

mutex.lock();
change_state();
mutex.unlock();

в с++ ты точно можешь сказать какой поток отработает здесь первым а какой последним?

От эрланга веет....

Как поэтично сказано, ёб#%$%#$%#^! Прослезился. :)

Звучит как - там нет кнопки «сделать %#$&ато». Подобный функционал зависит от архитектуры распределенного приложения, посему универсальной таблетки не требуется. Тем паче реализовать очередь с заданием последовательности вообще не является проблемой.

а ты по дурацки спроектировал свое приложение

А постоянное переливание байтиков из пустого в порожнее — отличный способ проектирования, ага.

Два потока отправили потоку, хранящему стейт, запросы на изменение одних и тех же данных. Кто кроме Аллаха знает, в каком порядке они будут обработаны при этой дурацкой асинхронной архитектуре?

Внезапно! в порядке очереди.

чем это лучше Scala?

Отсутсвием джавы, наличием препроцессора и нормального синтаксиса.

ананим тут имеет ввиду, что нельзя понять в какой последовательности они попадут в очередь сообщений.

Отсутсвием джавы, наличием препроцессора и нормального синтаксиса.

+1

Еще есть вкусный LFE: https://github.com/rvirding/lfe

ананим тут имеет ввиду, что нельзя понять в какой последовательности они попадут в очередь сообщений.

ананим не знает об Priority Queue?

Внезапно синхронизируй сам, никто тебе не мешает.

https://github.com/trifork/erjang/wiki

ананим не знает об Priority Queue?

ну оное ведь не входит в коробку :). так или иначе, все реализации используют сторонний софт в качестве общей точки, обеспечивающей атомарность операций. эту роль может исполнять любое хранилище. на вскидку - тот же redis умеет, riak вроде тоже.

ну оное ведь не входит в коробку :)

так оно реализовывается с помощью стандартного receive в несколько строк.

https://github.com/trifork/erjang/wiki

только напоигратца

https://github.com/trifork/erjang/wiki

Видел этот проектик когда-то. Но это чистейший just for fun. Там даже тесты есть, которые срывают покровы с сути проекта: если из эрланга выпилить SMP(!!!), то можно получить существенный прирост производительности на статических тестах, заменив BEAM на JVM. А если запустить 500k потоков в jvm, то jvm успешно ляжет с out of memory, а если не ляжет то будет адово тормозить и весь прирост сойдёт на нет.

Сейчас эту нишу занял похапэ.

Erlang - это же встроенный язычок какой-то телекоммуникационной платформы, не?

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

два раза съездишь в Египет

Это у пхпшников хватает денег только на сраный ебипет.

Могу, если упорядочить потоки в пуле.