Смысл в Node.js

А потом выясняется, что широкий круг задач, включая SQL хранилища, совершенно синхронны, а с асинхронной частью справляется nginx.

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

Единственная юникодопроблема -сообщения ошибок заэнквоченные

Spring-быдлокодеры начали тонуть в тоннах созданного им говна? Устали, бедненькие. Нужно на новой полянке из Go новые тонны говна создавать.

Это как-то так работает на сегодняшний день.

Проблема не в драйвере же, а в логике задач.

Проблема именно в синхронном API. Нет таких задач, логика которых не может выполняться асинхронно. Более того, любой объём работы со величине и видам можно поместить в event loop и освободить поток, который её туда поместил, для других задач.

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

Если не согласен, то приведи пример задачи, которая не может выполняться в event loop (отдельными этапами).

Наверное, похоже на правду.

Еще и gil забыл :)

Тогда уж лучше на асеблере, хули :-)

а в чем проблема?

let olo = yield [db.query('omg'), db.query('wtf')];

let olo = await Promise.all([db.query('omg'), db.query('wtf')]);

выполняться в event loop

Конечно может. Только вместо:

задание1 -> задание2 -> задание3

задание1
вотчер на задание1 готово -> задание2
вотчер на задание2 готово -> задание3

И да, пусть даже асинхронный join трёх таблиц, например, часто может оптимизироваться СУБД гораздо хуже, чем два последовательных. А где последовательные обращения к СУБД, там асинхронщина пропадает и становится оверхедом.

Ну ты же знаешь, что есть несколько способов обхода gil, когда он мешает, вплоть до «питон тут не нужен». В остальных случаях питон нужен.

удобно ведь, когда один язык

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

Ну так это реализовано в других языках тредами, например.

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

Зачем?
И на каком ядре?
И, опять, возвращаемся к ngix, а остальное - почти не нужно.

Зачем?

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

nginx — замечательно, но он же не один (ну, если нагрузка детская — одного хватит, да) и он не работает с БД напрямую обычно.

Я и не говорил, что он не нужен :) Мне нравится питон, мне не нравится поддерживать тонны легаси говна на питоне :)

задание1 вотчер на задание1 готово -> задание2 вотчер на задание2 готово -> задание3

Есть же RxJS/RxJava, даже что-то там из RxJS в стандарт должно войти.

Если забыть, что есть Rust и Pure C.

При всей моей любви к сишке, в ней из коробки нет корутин.

Да хватает их: https://github.com/MagicStack/asyncpg на базе python3.6, второй на scala: https://github.com/mauricio/postgresql-async

Всё это было и с коллбэками. Только гемор с объединением параллельных данных очевиднее (т.е. меньше шансов написать совсем уж нечитабельный код), насколько могу судить.

Асинхронными должны быть не джойны, а ожидание result set и вычитка из него записей. А сама база может работать как угодно.

Т.е. SQL не меняется в угоду асинхронщины, меняется API для вычитки данных из базы с resultSet = query(sql); resultSet.next()/resultSet.next()/resultSet.next() на query(sql, resultSetRecordCallback).

Когда появится что-то для языков, с которыми я работаю, то посмотрю подробнее.

Но, в общем, молодцы, если создают. Единственное что, вот это точно говно:

values = await conn.fetch('''SELECT * FROM mytable''')

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

В этом и смысл. Чтобы код был простой и понятный.

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

Если не согласен, то приведи пример задачи, которая не может выполняться в event loop (отдельными этапами).

Любые тяжелые вычисления. Особенно когда из-за них кончаются ресурсы ядра.

Ну дык поищи интерфейс курсоров в драйвере. Возможно автор не счел нужным описывать очевидные вещи.

Python не пользую, так что подожду что-нибудь для языков, которые использую.

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

Да и то подобная жизнь, особенно в контексте NoSQL, часто означает выгребать половину базы данных для последующей склейки/обработки.

let [a, b, c] = await Promise.all([
  query_a(),
  query_b(),
  query_c(),
])

Разберись как промисы работают. Ты себе чего-то левого нафантазировал.

IMHO ты на какие-то абстрактные вещи съезжаешь. async/await решают проблему с колбеками. Колбеков нет, логика линейная. То как эту фичу применять или не применять - личное дело каждого.

Для больших выборок из баз делают курсоры и стримы, но это не имеет абсолютно ни какого отношения к async/await.

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

Просто обновляй каждую секунду.

Можно пример, что-то уже всё перепробовал, не работает :(

user threads же!
Но не в 1:1 системе, да.

Я не пишу активно под электрон и не держу в голове что там как. Пойди на крайние меры, загугли примеры и tutorials. Рендереры с DOM там отдельными «окнами», не в главном процессе который запускается.

Жаль, что-то мало инфы в нете.

Тебе то же на wxPython никак не сделать?

C радостью, но мучаю элетрон, но пока кроме трудностей нечего полезного :(

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

Я «нафантазировал» живой код в недалёком прошлом с гроздями зависимых запросов из одной молодой, но перспективной хипстерской NoSQL базы данных. И код там или очень нелинейный и, соответственно, на колбэках или работать будет с кучей вспомогательного бойлерплэйта и с последовательным выпуском новых и новых запросов, соответственно, с большой задержкой и бОльшим потреблением памяти.

Ответь пожалуйста на один простой вопрос. Какое отношение то что ты написал имеет к async/await? Видишь ли, я могу отвечать на конкретные вопросы, если в них разбираюсь. Но не вижу смысла о чем-то спорить или чатиться за жизнь. Не интересно как-то.

хипстерской NoSQL
на колбэках
вспомогательного бойлерплэйта

Это настоящая крутизна, однозначно.

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

Инструменты типа https://www.npmjs.com/package/async (= Promise.all в стороне от await) полезнее, но в общем тоже беда-печаль в живом типичном web-приложении на Node.js + NoSQL. Ибо всё так же не влияют на глубину дерева асинхронных событий и не избавляют от бремени склейки промежуточных результатов.

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

Это же просто больная фантазия автора, заразившая жеесеров мыслью «мы теперь и в бекенд сможем!».

P.S. для всех: Я ничего против качества кода самой ноды не имею, оно вполне работоспособно. Мы тут говорим о целях поделки.

async/await позволяют сохранить бизнес логику ровно в том виде, в котором она есть. Не упарывая ее колбеками.

А о прелестях caolan-овской библиотеки для колбеков ты пытаешься рассказывать тому, кто ее использовал много лет, и потом съехал на промисы с генераторами и впоследствии async/await. Разница в удобстве - огромная. На ветвлениях это сразу заметно. И это реальный опыт, а не заключения из наблюдений за интернетами.

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

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

Ну и проще становится налепить гордую лычку «фуллстек» программист.

Разницы никакой, кроме синтаксической. На всех трёх проектах из трёх, на которых имел дело с Node.js обязательно была минимум одна многочасовая сессия отладки логики ровно в том виде, в котором она выполняется в рантайме.

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

А по теме: от Node.js + NoSQL советую держаться подальше. Ничего из A.C.I.D. (Atomicity, Consistency, Isolation, Durability) как информационная система она не обеспечивает. Зато обеспечивает долгие часы отладки при попытке реализовать хоть сколько-нибудь нетривиальные требования (= отличные от create/update/delete/get_by_id). Adieu.

Разницы никакой, кроме синтаксической.

IMHO это глупость полная, которую на полном серьезе может утверждать только человек с очень небольшим или нулевым опытом использования async/await. Код с ними читать на порядок проще, чем с колбеками. Писать тоже. Я перегонял с колбеков много кода, сначала на генераторы, потом на async/await, разницу представляю очень хорошо.