Вышел Erlang/OTP 22

no types. the first encountered refactoring kills any wishes to use it in production.

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

Заметно по точке в конце :)

Тем не менее статическая проверка типов есть, просто она не встроена в компилятор: http://erlang.org/doc/man/dialyzer.html

Твердое - когда нельзя профакапить ни один выделенный квант. Пример - ЭБУ двигателя. Когда пропущенный такт приведет к остановке двигателя на трассе, дальше блокировка ведущих колес, занос, встречка, гроб, кладбище, гомосексуалист.

Мягкое - когда иногда профилонить можно. Пример - видеоигорь, когда в целом 4к60фпс желательно, но фпс может дропнуться до 20 и никаких последствий кроме дискомфорта, батхерта и гневных постов в стиме играющего не будет.

Это как soft porn и hard porn

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

Императивная лапша там если с хаскелем сравнивать

А тебе это нравится?

Подвесит, это надо учитывать

Тогда многозадачность всё-таки кооперативная, а не вытесняющая. Такая же как в Racket'овских thread, например. В Go это же называется корутины.

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

Если говнокодить для говновеба, но чувствовать себя элитой - то Elixir. Зачем учить сам Erlang - вообще не знаю, ради 0,0001% вакансий - глупо, лучше уж обмазаться JavaScript'ом.

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

На плюсах. Я этот код сам ковырял, так что инфа 146%

Стоит. Хотя бы как средство посмотреть на мир по другому.

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

Не знаю про ракету но в го у тебя точно переключение происходит только на определенных вызовах и простой цикл вешает все во-первых, во-вторых разве го использует все ядра процессора сразу?

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

Разве? А если ерланговский тред повис на системном вызове (open по NFS, например)?

Не знаю про ракету

Там в конце каждой функции управление передаётся планировщику. Соответственно, если функция завершается, то всё хорошо. А если функция заблокировалась, то ждут все «потоки».

в го у тебя точно переключение происходит только на определенных вызовах

Что-то странное пишешь. В описании указано, что

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

Разве? А если ерланговский тред повис на системном вызове (open по NFS, например)?

Системный вызов считается нативным кодом, конечно же.

Там в конце каждой функции управление передаётся планировщику

В эрланге каждая элементарная операция может передавать управление планировщику.

Что-то странное пишешь.

что позволяет выполняющейся go-процедуре покидать поток с заблокированной go-процедурой (ждущей, например, отправки или приема сообщения из канала) и продолжать работу далее

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

В эрланге каждая элементарная операция может передавать управление планировщику.

В го и ракете также.

если у тебя цикл считает фибоначчи то он, вроде, уравление не передаст.

Там проблема только с пустыми циклами. Сборщик мусора хочет регулярно прерывать поток, а в пустом цикле нет безопасной точки для этого.

В го и ракете также.

Ты же только что сказал что в ракете в конце функции передается управление, а в го только на блокирующих процедурах?

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

В чем опасность? В эрланге, насколько я знаю, нет таких ограничений.

в ракете в конце функции передается управление

«каждая элементарная операция» и «функция» в рамках Racket одно и то же.

в го только на блокирующих процедурах

В го на блокирующих корутина может на другое ядро перепрыгнуть (в отличие от Erlang).

В чем опасность? В эрланге, насколько я знаю, нет таких ограничений.

В ерланге в момент системного вызова будет останов процесса, в го в это время может быть вызван сборщик мусора из соседнего потока. Но го отмечает периоды, когда можно вызывать сборщик мусора (фактически после каждого действия). Но если действий нет вообще, то сборщик мусора начинает бесконечно ждать. Хотя может уже и починили.

Кстати, «каждая элементарная операция» в функции X() -> X(). присутствует? Или вызов такой функции повесит ерланг?

В ерланге в момент системного вызова будет останов процесса

Нашел обсуждение этого, в теории останов процесса может случится, но на практике этого не происходит:

Generally, no. The most expensive system calls (usually IO) will use kqueue, epoll, or select (the first two if you use the «+K true» flag on the command line). Other calls may use async threads so that they do not block the scheduler.

В го на блокирующих корутина может на другое ядро перепрыгнуть (в отличие от Erlang).

Откуда инфа что в эрланге не может?

Кстати, «каждая элементарная операция» в функции X() -> X(). присутствует? Или вызов такой функции повесит ерланг?

Не повесил (на 8 ядрах):

2> F = fun F() -> F() end.
#Fun<erl_eval.44.99386804>
3> 
3> 
3> Pids = [spawn(F) || _ <- lists:seq(1, 20)].
[<0.69.0>,<0.70.0>,<0.71.0>,<0.72.0>,<0.73.0>,<0.74.0>,
 <0.75.0>,<0.76.0>,<0.77.0>,<0.78.0>,<0.79.0>,<0.80.0>,
 <0.81.0>,<0.82.0>,<0.83.0>,<0.84.0>,<0.85.0>,<0.86.0>,
 <0.87.0>,<0.88.0>]
4> [erlang:process_info(P, status) || P <- Pids].
[{status,runnable},
 {status,running},
 {status,runnable},
 {status,running},
 {status,runnable},
 {status,runnable},
 {status,garbage_collecting},
 {status,runnable},
 {status,running},
 {status,runnable},
 {status,running},
 {status,runnable},
 {status,runnable},
 {status,runnable},
 {status,runnable},
 {status,running},
 {status,runnable},
 {status,runnable},
 {status,running},
 {status,running}]

I used it once. It couldn't even recognize just an uninitialized record field. garbage.

В эрланге нет понятия неинициализированный, `undefined` это обычное значение.

Откуда инфа что в эрланге не может?

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

Go runtime scheduler gives a goroutine which blocks in a syscall or a cgo calls about 20 us (as of Go 1.9) to complete, and if it doesn't, the scheduler parks the goroutine and may spawn another OS thread if there are runnable goroutines — to keep up with its promise to have runtime.GOMAXPROCS goroutines running.

Я.
anonymous

Почему-то показалось забавным.

В чем опасность? В эрланге, насколько я знаю, нет таких ограничений.

Потому что там нет циклов.

Снаружи нет, но хвостовая рекурсия и LC вполне могут быть сахаром над циклами (я точно не знаю как оно в beam интерпретируется).

Проверяй версию диалайзера своего, наверное

-module(test).

-compile([debug_info]).

-export([test/0]).

-record(rec, {id :: integer()}).

test() ->
  #rec{}.

src/test.erl
  10: Record construction #rec{id::'undefined'} violates the declared type of field id::integer()

Снаружи нет, но хвостовая рекурсия и LC вполне могут быть сахаром над циклами (я точно не знаю как оно в beam интерпретируется).

Работает так, что каждый вызов функции может является точкой останова и вытеснения потока.

лучше уж обмазаться JavaScript'ом.

Почему?

Если говнокодить для говновеба, но чувствовать себя элитой - то Elixir.

Ты так говоришь как будто элитой себя считаешь. А что кроме веба есть то для зарабатывания денег? Что есть для тебя не гавно? Ты просто неосилятор веба. Поэтому у тебя пукан горит.

А что кроме веба есть то для зарабатывания денег?

Много чего, есть разработка под iOS/Android, например. А насчёт неосилятора, видишь ли, какая ситуация. Например, человек «осиливший» PHP или JS по большей части специалист не в программировании, а профессиональный избегатель недостатков и уродских особенностей этих язычков. Гордится, что ты научился использовать говноязык, не натыкаясь на сотни его дебильных недостатков - ну как бы такое себе достижение. Поэтому «осилить веб» - это что, знать весь бардак и помойку в нём происходящую? Ну тогда да, я неосилятор.

Если ты себя считаешь элитой? То нет плохого языка ты же об этом знаешь, если ты адекватный человек? Есть только неосиляторы или нытики. Твои слова «говноязык», «дебильные недостатки» лишь показывает твою некомпетентность и незнание о предмете. Порядочные люди не разбрасываются пустыми словами «то язык говно, то ещё чё, то ему ещё че подавай...». Каждая технология/язык достоин своего внимания. Это огромные труды человечества. Даже если они написаны плохо, ситуация постепенно придет к улучшению и нормализации. Так строится мир. Нельзя просто так взять и построить с пол пинка что-то правильное и достойное. И вообще правильность вещь очень относительная.

Твои слова «говноязык», «дебильные недостатки» лишь показывает твою некомпетентность и незнание о предмете. Порядочные люди не разбрасываются пустыми словами «то язык говно, то ещё чё, то ему ещё че подавай...». Каждая технология/язык достоин своего внимания. Это огромные труды человечества.

Боже мой, какой ты умный и правильный. Ну ок, остановимся на том, что я дурак, а JavaScript - говно и дебильный язык, мне пофиг.

хехей, анон ждал этого с 1992 года! Такими темпами скоро хаскель догоним и перегоним! Ура товарищи

Нельзя просто так взять и построить что-то правильное и достойное.

боромир.jpg

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

У меня проект без проблем проверялся на 20.0 например в 21.0 оказалось имел десяток (незначительных) ошибок типов.