All streams
Search
Write a publication
Pull to refresh
39
0.3
Константин @Cerberuser

Разработчик, экспериментатор

Send message
Правда в последних официальных версиях этот замок убрали.

Можно уточнить, о каких версиях речь? Complete Edition — всё на месте.
Ну почему же «не так»? Вы просто работаете с ним как опытный пользователь, которому не нужно ничего делать с железом, чтобы всё работало, а достаточно грамотно оперировать софтом.

Да, проблема именно в том, что функция inner сама асинхронная. Изначально она имела примерно такой вид:


async inner(callback) {
    const result = await asyncWork();
    callback(result);
    await moreAsyncWork();
}

Т.е. требовалось передать наружу данные из первого асинхронного процесса и запустить ещё один асинхронный процесс, результат которого здесь уже никого не интересует (этот результат попадёт в БД и будет обработан позже в другом месте). Ждать завершения второго процесса мы не можем, он может оказаться долгим, а вот ждать завершения первого — наоборот, обязаны. Ну и плюс к тому хотелось сохранить это всё одной функцией (потому что логически это единая операция, у которой используется и окончательный результат, и промежуточный) — так-то, конечно, можно было в месте вызова просто сказать const result = await asyncWork(), а moreAsyncWork() вызвать отдельно.

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

async/await любит подсовывать гадости там, где их, на первый взгляд, быть не должно. Пример из практики: есть функция inner, которая асинхронно выполняет операцию, дёргает колбэк и асинхронно выполняет следующую операцию. Нужно в другой асинхронной функции получить результат, проброшенный в колбэк. Кажется, это должно быть просто?
try {
  const result = await new Promise(ok => inner(ok));
} catch {
...
}

Стандартный шаблон promisify, что может пойти не так? А вот что. Функция inner может кинуть исключение. Так как на ней самой await не стоит — исключение кидается асинхронно, и блоком try/catch во внешней функции не ловится. Итог — Unhandled promise rejection и досрочное завершение без обработки ошибки.
Поставим внутри await inner — может, поможет? Нет, потому что тогда мы ждём окончания внутренней функции, а не вызова колбэка.
В итоге пришлось переписать внутреннюю функцию таким образом:
const result = await asyncWork();
moreAsyncWork().catch(...) // без await
return result

Что уже выглядит как не очень красивый хак, как по мне.
Вы про хаб «Я пиарюсь» или корпоративные блоги?
А если «на каждой из заранее неизвестного множества машин» (упомянутый выше в комментах случай «зайти от друга»)?

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

Интересно, если наш проект webpack в watch-режиме каждый раз пересобирает минимум секунд пять, а если добавился новый импорт — то и все двадцать, сколько там rollup провозится...

Вы с ума сошли, открыто говорить о [НЕЗАКОННЫЙ КОНТЕНТ УДАЛЁН]? [НЕЗАКОННЫЙ КОНТЕНТ УДАЛЁН] следит, они ж всему Хабру [НЕЗАКОННЫЙ КОНТЕНТ УДАЛЁН] пропишут!
(последнее — не мат, если что)

Мне в связи с этим интересно, "патриоты", которые видят во всём этом оскорбление (а не неудачную пасхалку, например), — они вообще в большинстве, или просто орут больше всех? И если второе — то должно ли государство, представляющее мнение народного большинства, прислушиваться к мнению орущего меньшинства или, наоборот, аккуратно их приструнить, чтоб не перегибали?

Минусами обозначается комментарий в целом, к сожалению. Если, конечно, не было этого самого «пишут ответы».
Вы исходите из того, что большинство людей в состоянии самостоятельно понять, какие сказанные ими слова были оскорбительны для других, а какие — выглядели в глазах других нелогичными, верно?
А по IP не забанят?
Логичнее, наверное, требовать, чтобы для стоящих рядом выполнялась принадлежность отношению, иначе, к примеру, в Вашем случае список (a, c, a) и даже (c, a, c) будет отсортирован, что довольно странно (почему бы одному и тому же ключу стоять и до, и после другого, если у нас есть хоть какое-то разумное понимание порядка?) Другой вопрос, что тогда будут существовать несортируемые списки (как раз два приведённых мной примера), но это, имхо, меньшее зло, если уж мы берём в качестве «порядка» отношение, которое порядком не является.
Количество пар элементов, стоящих в неправильном порядке (неважно, подряд или нет), уменьшается с каждой заменой на единицу (все остальные элементы относительно двух заменённых как стояли, так и стоят, а эти два встали правильно). Пока хотя бы два стоят неправильно — замены будут происходить, потому что будет хотя бы два стоящих неправильно рядом (в силу того, что ключи должны образовывать линейный порядок — иначе о сортировке вообще говорить странно). Это будет считаться достаточным доказательством (для собеседования, конечно, не для экзамена)?
Храните конфиги в репозитории и делайте `revert` при удалении программы, породившей их?
И чем это будет отличаться от того, что есть сейчас — с официально нестрогим парсером?

Information

Rating
2,302-nd
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer
Senior