Сообщение 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, ничего не будет ВООБЩЕ. Простой линейный код. Сравни:
И вот этот async/await надо ставить везде на всю глубину вызовов, пока не дойдём до каких-нибудь низкоуровненвых IO API. САБЖ!!!!
S>На самом деле Task были придуманы еще в 12 году. В Яве виртуальные потоки появились значительно позже, а StructuredTaskScope так вообще еще превью.
ДЕСЯТЫЙ РАЗ ПОВТОРЯЮ! Task — это аналог CompletableFuture. И появилось оно в 13 году что-ли. Заметь в моём коде вообще нигде Task/CompletableFuture нет. Они просто не нужны.
S>Виртуальные потоки однозначно хороши для синхронного кода. Но что касается асинхронного, то тут нет однозначности.
Они делают асинхронный код ненужным.
S>Я предпочитаю Task. Task async await показывают как я использую метод как задачу или результат задачи.
Сабж прочитай.
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, ничего не будет ВООБЩЕ. Простой линейный код. Сравни:
И вот этот async/await надо ставить везде на всю глубину вызовов, пока не дойдём до каких-нибудь низкоуровненвых IO API. САБЖ!!!!
ИЧСХ, вот такой простой линейный код составляет 99% типичного приложения. Параллелизация обычно где-то на уровне фреймворка (ну там входящие HTTP-запросы какие-нибудь).
S>На самом деле Task были придуманы еще в 12 году. В Яве виртуальные потоки появились значительно позже, а StructuredTaskScope так вообще еще превью.
ДЕСЯТЫЙ РАЗ ПОВТОРЯЮ! Task — это аналог CompletableFuture. И появилось оно в 13 году что-ли. Заметь в моём коде вообще нигде Task/CompletableFuture нет. Они просто не нужны.
S>Виртуальные потоки однозначно хороши для синхронного кода. Но что касается асинхронного, то тут нет однозначности.
Они делают асинхронный код ненужным.
S>Я предпочитаю Task. Task async await показывают как я использую метод как задачу или результат задачи.
Сабж прочитай.
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 показывают как я использую метод как задачу или результат задачи.
Сабж прочитай.