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

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

У меня есть небольшая статейка: https://github.com/kobezzza/Collecti...%B2-Collection

Да, только одну тему прочитать успел, а уже достал :stop: За тем какая java "хорошая", не видно что ты хочешь сказать. Основные аргументы "как в java" и "правильно".

Так что я бы не отказался поподробнее узнать, чем плохи promise'ы или как их "правильно" реализовать. И по поводу потоков, нужны именно потоки, или worker'ы тоже подойдут? А я пока присоединюсь к melky, будем тихонько ненавидеть java :)

По поводу стандартной библиотеки, я бы конечно соврал, если бы не заметил аргумент "хочется большей стабильности", но чем больше стабильность, тем меньше развитие (как считают к слову некоторые иностранные коллеги). Я лично за эволюцию ;)

P.S. Если же положение дел так сильно не нравится, всегда можно fork'нуть репозиторий и сделать что-нибудь. Ну или на java перейти, если не вариант ;)

Асинхронный код, неудобная обработка ошибок. Эти проблемы решают async / await, которые по сути являются сахаром над Promise и хорошо зарекомендовали себя в других языках. В ES7 ожидается поддержка, но с Babel можно юзать уже сейчас.

async function foo() {
    try {
      const data = await getData();
      const more = await [getMoreData(), getMoreData()];
    
    } catch (err) {
      ...
    }
}

Я был бы рад и воркерам.

Ну вообще я надеялся на какое-то более подробное описание/сравнение. Пока разбирался, вот что нашел, с интересными ссылками.

Итого, вариант c помощью babel:

require('babel/register');

function getData() {
  return new Promise(function(resolve, reject) {
    resolve('getData');
  })
}

function getMoreData() {
  return new Promise(function(resolve, reject) {
    resolve('getMoreData');
  })
}

async function foo() {
    try {
      const data = await getData();
      const more = await* [getMoreData(), getMoreData()];
      console.log(data);
      console.log(more);
    } catch (err) {
      console.log('error');
    }
}

foo();

Который запускается так:


И вот вариант без него:

function getData() {
  return new Promise(function(resolve, reject) {
    resolve('getData');
  })
}

function getMoreData() {
  return new Promise(function(resolve, reject) {
    resolve('getMoreData');
  })
}

function foo() {
    getData().then(function(value) {
        this.data = value;
        return Promise.all([getMoreData(), getMoreData()]);
    }).then(function(value) {
        console.log(this.data);
        console.log(value);
    }).catch(function() {
        console.log('error');
    });
}

foo();

Так?

P.S. И там что-то было про домены какие-то, можно ссылку? А то не гуглится.

И про X server, хотя это к melky. Что с ним не так?

https://nodejs.org/api/domain.html. Это костыль для обработки ошибок в асинхронном коде, сейчас, с появлением generator expressions, становится deprecated.

Забыл про очень классные стрелочные функции:

function getData() {
  return new Promise((resolve, reject) => {
    resolve('getData');
  });
}

а почему костыль обоснуешь? и как это связано с generator expressions?

Вообще да, честно говоря я сначала думал, что за проблемы с читабельностью при использовании promise'ов? А потом посмотрел на то, что получилось в предыдущем сообщении... Хотя с другой стороны, вот вы тут жалуетесь, а на другой стороне планеты бородатые мужики на c херачат, а некоторые вообще на assembler, и ничё ;)

Но это так, отступление. Собственно, почему все так прицепились к этим промисам? Придумали проблему и мужественно ее решаем? Звучит умно? Я как-то давно тут на форуме предлагал такую штуку как AsyncChain. Правда там не было аналога Promise.all, но в чем дело давайте придумаем:

function foo() {
    var onError = function() {
        console.log('error');
    };
    new AsyncChain({onError: onError})
        .add(function(NEXT1) {
            this.data = 'getData';
            return NEXT();
        })
        .add(function(NEXT1) {
            var this1 = this;
            new AsyncAllChain({onError: onError})
                .add(function(NEXT2) {
                    this.var1 = 'getData';
                    return NEXT2();
                });
                .add(function(NEXT2) {
                    this.var2 = 'getData';
                    return NEXT2();
                })
                .add(function() {
                    this1.more = [this.var1, this.var2];
                })
                .go();
            return NEXT1();
        })
        .add(function() {
            console.log(this.data);
            console.log(this.more);
        })
        .go();
}

foo();

Вроде бы ничего не забыл. Ну это не то чтобы окончательный вариант, критика приветствуется, давайте придумаем как сделать так, чтоб всем было хорошо :) Ну или почти всем, потому что если всем, то тогда promise'ам альтернатив нету, думаю.

И по поводу интересных ссылок, альтернативный вариант.

Что там дальше? Потоки? Я собственно почему веб воркеры вспомнил? В свое время дедушка Douglas Наше Все Crockford рассказывал, чем так хорош nodejs (можно смотреть с начала, там все интересно) и в чем самая большая ошибка java (the biggest design mistake in java, на 8-ой минуте, 08:40). Понятно, что это для вас не авторитет. Да и я не то чтобы с ним во всем согласен. Но он один из двух людей, которых интересно слушать :) И, кстати, его речь проще всего понимать.

Опять я отвлекся, в общем он там говорит, что потоки — это сложно. Event loop наше все. И веб воркеры один из вариантов решения проблемы долгих вычислений. В чем разница? В том что веб воркеры не шарят состояние с основным потоком. Не нужны блокировки и прочая муть. Что говорит google? Что потоки уже есть в nodejs (безопасные, без sharing state). Что можно форкать процессы. И что есть даже модуль cluster, который решает смежную проблему. Так чего же вам не хватает, м? :)

Ну, вроде все проблемы решил, или не? :)

P.S. Приведите какой-нибудь use case для Promise.all(), плз?

x-yuri,
Например, нам нужно одновременно загрузить несколько ресурсов из сети и только после этого запустить функцию обработчик.

каких ресурсов?

x-yuri,
нужных ресурсов. Неужели сложно представить? Например, куча картинок.

Если бы не было, я бы не спрашивал. На данный момент мы имеем `async await * [getPicture(), getPicture()]`, но непонятно, что это за приложение. Это сайт? И зачем ему скачивать картинки? Т.е. меня интересует не содержимое функции foo(), а то что за ее пределами, контекст. Если это распространенная операция, то привести пример не должно составлять проблемы. Можно даже несколько ;) Спасибо.