Информация об изменениях

Сообщение Re[64]: Можно ли избавиться от async|await? от 13.01.2026 13:30

Изменено 13.01.2026 13:50 ·

Re[64]: Можно ли избавиться от async|await?
Здравствуйте, Serginio1, Вы писали:

S>>>По Task я вижу, что метод асинхронный и могу использовать либо параллельно, либо последовательно через await.

S>·>А с виртуальными тредами ты видишь любой метод и можешь использовать либо параллельно, либо последовательно без всякого await-шлака.
S>Ты не понял. Есть IO методы или методы получающие результат по событию (та же асинхронная очередь). Они не напрягают CPU поэтому видя такой метод я предпочту параллельное выполнение.
Ты не понял. Виртуальные треды получают результат синхронно (та же синхронная очередь), блокируясь на IO в любом месте и не напрягают CPU, выполняясь параллельно.

S> await ничем не хуже

Он хуже в случае последовательного выполнения, т.к. приходится ставить везде await/async. САБЖ! И ты ещё CancellationToken забыл.

S>И вот сравни такой подход c StructuredTaskScope

Внутри coreApi никакого StructuredTaskScope, ничего не будет ВООБЩЕ. Простой линейный код. Сравни:

Product coreApi(long id) {
  var d1 = readFromFile(id);
  var d2 = queryDb(id, d1 + 42);
  synchronized(lock) {
    var d3 = downloadFromRestApi(id, d2, d1);
    return new Product(d3, d1);
  }
}

async Product coreApi(long id,  CancellationToken token = default) {
  var d1 = await readFromFile(id, token);
  var d2 = await queryDb(id, d1 + 42, token);  // используем резульат d1.
  using (await _lock.LockAsync(token))
  {
    var d3 = await downloadFromRestApi(id, d2, d1, token);
    return new Product(d3, await d1);
  }
}

И вот этот async/await надо ставить везде на всю глубину вызовов, пока не дойдём до каких-нибудь низкоуровненвых IO API. САБЖ!!!!

S>На самом деле Task были придуманы еще в 12 году. В Яве виртуальные потоки появились значительно позже, а StructuredTaskScope так вообще еще превью.

ДЕСЯТЫЙ РАЗ ПОВТОРЯЮ! Task — это аналог CompletableFuture. И появилось оно в 13 году что-ли. Заметь в моём коде вообще нигде Task/CompletableFuture нет. Они просто не нужны.

S>Виртуальные потоки однозначно хороши для синхронного кода. Но что касается асинхронного, то тут нет однозначности.

Они делают асинхронный код ненужным.

S>Я предпочитаю Task. Task async await показывают как я использую метод как задачу или результат задачи.

Сабж прочитай.
Re[64]: Можно ли избавиться от async|await?
Здравствуйте, Serginio1, Вы писали:

S>>>По Task я вижу, что метод асинхронный и могу использовать либо параллельно, либо последовательно через await.

S>·>А с виртуальными тредами ты видишь любой метод и можешь использовать либо параллельно, либо последовательно без всякого await-шлака.
S>Ты не понял. Есть IO методы или методы получающие результат по событию (та же асинхронная очередь). Они не напрягают CPU поэтому видя такой метод я предпочту параллельное выполнение.
Ты не понял. Виртуальные треды получают результат синхронно (та же синхронная очередь), блокируясь на IO в любом месте и не напрягают CPU, выполняясь параллельно.

S> await ничем не хуже

Он хуже в случае последовательного выполнения, т.к. приходится ставить везде await/async. САБЖ! И ты ещё CancellationToken забыл.

S>И вот сравни такой подход c StructuredTaskScope

Внутри coreApi никакого StructuredTaskScope, ничего не будет ВООБЩЕ. Простой линейный код. Сравни:

Product coreApi(long id) {
  var d1 = readFromFile(id);
  var d2 = queryDb(id, d1 + 42);
  synchronized(lock) {
    var d3 = downloadFromRestApi(id, d2, d1);
    return new Product(d3, d1);
  }
}

async Product coreApi(long id,  CancellationToken token = default) {
  var d1 = await readFromFile(id, token);
  var d2 = await queryDb(id, d1 + 42, token);  // используем резульат d1.
  using (await _lock.LockAsync(token))
  {
    var d3 = await downloadFromRestApi(id, d2, d1, token);
    return new Product(d3, await d1);
  }
}

И вот этот async/await надо ставить везде на всю глубину вызовов, пока не дойдём до каких-нибудь низкоуровненвых IO API. САБЖ!!!!

ИЧСХ, вот такой простой линейный код составляет 99% типичного приложения. Параллелизация обычно где-то на уровне фреймворка (ну там входящие HTTP-запросы какие-нибудь).

S>На самом деле Task были придуманы еще в 12 году. В Яве виртуальные потоки появились значительно позже, а StructuredTaskScope так вообще еще превью.

ДЕСЯТЫЙ РАЗ ПОВТОРЯЮ! Task — это аналог CompletableFuture. И появилось оно в 13 году что-ли. Заметь в моём коде вообще нигде Task/CompletableFuture нет. Они просто не нужны.

S>Виртуальные потоки однозначно хороши для синхронного кода. Но что касается асинхронного, то тут нет однозначности.

Они делают асинхронный код ненужным.

S>Я предпочитаю Task. Task async await показывают как я использую метод как задачу или результат задачи.

Сабж прочитай.