Одно из знаковых новшеств не упомянул - мультиплексирование данных (фрагментация)

Оно было в списке внизу :) поднял повыше

видимо я застал одну из ранних редакций твоего поста (из 10), где список фич состоял из 4 пунктов и упоминания оного не было :)

а ведь именно эта фича при высокой сетевой активности с большими блобами дает невероятный прирост.

http://blog.erlang.org/OTP-22-Highlights/

---

If we run the code below that does small rpc calls every 100ms millisecond and concurrently sends many 1/2 GB terms.Using two of our test machines I get a max latency of about 0.4 seconds on OTP 22, whereas on OTP 21 the max latency is around 50 seconds. So with the network at our test site the max latency is decreased by roughly 99%, which is a nice improvement.

Согласен, и все же регулярно посылать данные по 0.5Gb в одном сообщении скорее всего редкость - иначе давно бы уже сделали.

это corner case для демонстрации. вполне рядовой кейс - 2-ух/3-ёх мегабайтный терм. пока он будет пересылаться куча мелких сообщений будет стоять в очереди на отправку.

Что за «мягкое реальное время» и чем оно отличается от твёрдого?

Что за «мягкое реальное время» и чем оно отличается от твёрдого?

Как стул человека, обычно твёрдый случается регулярно и почти в одно и тоже время дня, а мягкий нет.

Правильно я понимаю, что вся производительность канала узел-узел, определяется единственным tcp/ip соединением? Т.е. организовать параллельную обработку большого трафика не получится?

Что за «мягкое реальное время» и чем оно отличается от твёрдого?

От жёсткого, если уж быть точным.

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

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

а вот каким боком эрланг к системам мягкого реального времени - я даже не знаю.

Интересно, а JIT сложно будет вкорячить в эту виртуальную машину? И создать свой node.js со шлюхами.

Как стул человека, обычно твёрдый случается регулярно и почти в одно и тоже время дня, а мягкий нет.

о ты как Erlang дриснёй обозвал

Да, там одно tcp соединение

Кто реально пишет на ерланге ?

Я.

Господа, как вы считаете, стоит ли изучить сей дивный язык программирования для общего развития и личных нужд?

Господа, как вы считаете, стоит ли изучить сей дивный язык программирования для общего развития и личных нужд?

Слово дивный - это еще мягко сказано
Ерланг резко выделяется из майнстрима, как в свое время форт
И выделяется он тем. что нужно ломать мозг, заточенный под стандартные синтаксические конструкции

Вот ответ на этот самый вопрос от создателя Эрланга: http://erlang.org/pipermail/erlang-questions/2017-October/093931.html

TLDR:

Hard real time: All requests MUST be satisfied within a specified time. Note this does not mean fast

Soft real time: Some requests might miss the deadlines

This is what Erlang was designed for - hundreds of thousands of processes that are largely inactive - then they wake up and request a small amount of computation. The odd process might request a large amount of processing but this should not block the other processes.

Погугли по тегам BEAMJIT его пилили, и вроде до сих пор пилят.

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

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

Правильно я понимаю, что вся производительность канала узел-узел, определяется единственным tcp/ip соединением? Т.е. организовать параллельную обработку большого трафика не получится?

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

Вот чуть подробнее: https://learnyousomeerlang.com/distribunomicon

If, for some reason, you need to be sending large messages, be extremely careful. The way Erlang distribution and communication works over many nodes is especially sensitive to large messages. If two nodes are connected together, all their communications will tend to happen over a single TCP connection. Because we generally want to maintain message ordering between two processes (even across the network), messages will be sent sequentially over the connection. That means that if you have one very large message, you might be blocking the channel for all the other messages.

Прологовская семантика вас не так смущает

В Эрланге как раз только синтаксис прологовский, а семантика чисто ФПшная, а-ля хаскель.

Это вопрос в плане компаний или индивидуумов? :)

стоит ли изучить сей дивный язык программирования для общего развития и личных нужд?

Абсолютно, в целом эрланг простой как пробка, пара структур данных, вызовы функций и посылка сообщений - вот и весь язык. Для практических нужд надо подучить OTP - набор стандартных практик для организации структуры приложения (имеется ввиду структура процессов а не директорий :)). И дальше остаются библиотеки по необходимости и наработка опыта.

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

семантика чисто ФПшная, а-ля хаскель

Я не настоящий эрлангист, но паттерн-матчинг и бэктрекинг там же чисто прологовские? А системы типов нет.

В эрланге нет «поиска решений» поэтому нет и бэктрекинга, то есть если в (псевдо)прологе написать

f() -> 
  foo(X),
  bar(X).

У тебя вначале X заматчится на одно из возможных значений в foo то потом если нет подходящих значений для X в bar то бэктрекинг пойдет пробовать следующее значение удовлетворяющее foo.

В эрланге это обычные вызовы функций (в первую очередь оно не скомпилится потому что X не определен) и если bar «не поддерживает» X как аргумент - просто вывалится ошибка.

В плане паттерн-матчинга это чисто как хаскель:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

На эрланге будет:

sign(X) when X > 0 -> 1;
sign(X) when X == 0 -> 0;
sign(X) when X < 0 -> -1.

То есть правила применяются по порядку сверху вниз, но так же нет никакого бэктрекинга а падает с ошибкой если не найдено подходящее тело.

Про систему типов - да, типы есть, а системы нет :)

Я писал четыре года назад, пока не ушёл из той конторы.

Ок, спасибо. Видимо я неправильно представлял, надо бы добраться до сабжа все-таки.

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

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

но для телекома под который делался эрланг параллелизм тоже имеет смысл и реальное время там тоже присутствует: вся голосовая связь в реальном времени и звонки проходят параллельно, да. просто обычно это значит, что за 10мс реального времени система должна обработать 10мс голосового трафика на всех соединениях, а если начинаются тормоза, то это всё барахло наверное должно масштабироваться.

т.е. эрланг наверное хорошо масштабируется и таким образом становится «языком для систем мягкого реального времени», да? корутины в нём тоже из коробки, да?

т.е. эрланг наверное хорошо масштабируется

Довольно хорошо :)

корутины в нём тоже из коробки, да?

В эрланге не корутины, в эрланге полноценные вытесняющие процессы, свой планировщик раскидывает их на доступные ядра через процессы ОС.

Добавлен новый (экспериментальный) модуль socket, предоставляющий низкоуровневый доступ к сокетам ОС. Это не замена gen_tcp и другим

А как по сравнению с procket?

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

Мой мозг, искалеченный POSIX shell'ом уже ничто не повредит.

Спасибо за ответ, а не подскажите что-нибудь на русском языке по Erlang'у. С чего начать, так сказать.

поня, а почему ты сменил аватарку?

// изучай эрланг во имя добра. Книг не так уж и много, лол.

Стоит ли учить его или лучше сразу Elixir?

поня, а почему ты сменил аватарку?

Меня притесняли по поводу нездоровой любви к пони.

изучай эрланг во имя добра. Книг не так уж и много, лол.

Ну из тех, которые есть.

Есть перевод книги автора эрланга, https://github.com/dyp2000/Russian-Armstrong-Erlang - это классический мануал по языку, все довольно подробно и с примерами.

Люди советуют learn you some erlang - как гайд, менее подробно и можно быстрее начать играться, есть неполный перевод на русский тут: https://github.com/mpyrozhok/learnyousomeerlang_ru

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

Спасибо!

«изучай эрланг во имя добра» это книга так называется.

Есть еще «Программирование в Erlang», Чезарини и Томпсона, тоже неплохая, но вышла в 2012, так что описания относительно новых фич там не жди (тех же map).

Если хочется просто глянуть на Эрланг, то в каком-то номере «Функционального программирования» было введение в него.

Еще порекомендовать могу книгу Джо Армстронга (из Вышел Erlang/OTP 22 (комментарий)).

за 10мс реального времени система должна обработать 10мс голосового трафика на всех соединениях

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

Интересно, а на чем написаны разные сормы. Там же тоже хайлоад.

в эрланге полноценные вытесняющие процессы

Правда? Если будет запущен ffi:call с длительной функцией, разве не подвесит все процессы на этом же ядре?

Кода семпл добавьте штоли? Ну так, посмотреть. Вот например посмотрел на синтаксис Rust`а и фсе понел, сразу))

Подвесит, это надо учитывать при написании ffi и в длительных функциях надо либо возвращать частичный результат если имеет смысл, либо вставлять передачу управления вручную. Именно второе было сделано в изменении поведения нативной функции `length/1` на больших списках: https://github.com/erlang/otp/pull/2053/files

ffi:call

что это такое? для enif есть dirty schedulers, гоняет в отдельном треде

Что за «мягкое реальное время» и чем оно отличается от твёрдого?

Когда перепьешь, бывает мягкий, но красивая девушка легко его сделает твёрдым...