ermouth: (Default)
ermouth ([personal profile] ermouth) wrote2015-04-22 03:55 am
Entry tags:

Многопоточность грядёт

Наткнулся только что в кейноте по новым предложениям для javascript.

Снимок экрана 2015-04-22 в 3.10.50

Это значит, что мы можем расшаривать данные между workers, со всеми плюшками. То-есть теперь в js есть threads, ну, или совсем скоро будут.

Многопоточность в C++ понимании в JS-мире нужна очень редко (да и в остальных мирах, по-хорошему, тоже) – но зато когда она нужна, без неё туго.

Это, например, вещание потоковых стримов из воркера нескольким (торрент)-слушателям через WebRTC или аналогичные применения. Это разделяемые мемкэши в веб-серверах. Это навороченные игры.

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

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

---

Вот хорошо бы ещё пионэры JS-комьюнити смотрели и в сторону Erlang, а не только Emscripten/C++.

[identity profile] morfizm.livejournal.com 2015-04-25 11:11 pm (UTC)(link)
Хм. Твой вариант очень хорошо читается.

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

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

[identity profile] ermouth.livejournal.com 2015-04-26 11:28 am (UTC)(link)
Код, который сразу писали в таком стиле и на правильном языке, как правило всё-же хорошо читается.

Код, который писали, натягивая за уши функциональный стиль, да на неприспособленном языке – читается как говно. Два прекрасных примера – php и java. Там да, код в таком стиле – просто кровавое месиво.

Насчёт коллбэков: коллбэки как конструкции – вообще обычно зло. Сравни:

var f = function (arg, callback) { ...; callback (result)};
f(123, function(res){...});

против
 var f = Promisify(function(arg) { return result});
var cb = Promisify(function (res){...}), 
    cb1 = Promisify(function (res){...})
f(123)
.then(cb)
.then(cb1)
.fail( function(err){...});


Во втором случае аж два «коллбэка» плюс обработка ошибок decoupled от самих функций.

Промисы проще читаются, в них проще обрабатывать ошибки и обычно понятно, что куда передаётся. Они, правда, довольно дорогие.

Не понял насчёт создания лямбд не инлайном – лямбда же просто стрелка, как её можно не инлайном? Её ж именовать придётся.