Сообщение Re[51]: Можно ли избавиться от async|await? от 12.01.2026 13:43
Изменено 12.01.2026 14:08 Serginio1
Re[51]: Можно ли избавиться от async|await?
Здравствуйте, ·, Вы писали:
S>>·>Допустим. Вопрос-то в чём? Что тебе надо отличать и с какой целью?
S>>Вопрос в том как отличить дожидаться задачи или не надо?
·>Это вопрос бизнес-требований. Но, как правило, дожидаться надо всегда.
·>Напомню. Мы сравниваем вот такой код: var res = await task; // или в синхронном варианте int res = task.Result;
·>В обоих случаях код дожидается завершения задачи.
Я не знаю, что ты там сравниваешь, я просто привел пример использования Task для асинхронного и синхронного кода
S>>>>>> В той же Java используются FutureTask. Callable и Future
S>>>>>>Казалось бы зачем?
S>>>>·>Не обязательно. В моём примере выше — не используются. Ещё раз: Это ортогональные понятия.
S>>>> Тогда зачем они нужны?
S>>·>Кому нужны? Для чего нужны? Ещё раз: в моём примере параллельного кода они не нужны (но можно, если очень хочется).
S>> Раз они есть значит нужны.
·>Нет, не значит. Future появилось в java версии 1.5 (это 2004 год). А виртуальные потоки в версии 21 (это 2023 год).
Ну то есть зоопарк.
S>> В примере FutureTask. Callable и Future выполняются паралельно с текущим кодом и затем дожидаются результата.
·>И?
S>>·>Ты опять послал ссылку, однако, статью прочитать не смог.
S>> То есть ты утверждаещшь, что в Ява нет зоопарка и проблем со API structured concurrenc
·>Единственная проблема на сегодняшний день — оно preview. Но это не мешает писать простой синхронный код.
Ну вот оказывается еще и preview. При этом никакого преимущества перед async/await практически нет.
async/await более универсальный вариант с использованием Task.WhenAny, Task.WhenAll, TaskCompletionSource, CancellationToken.
При этом давно уже не Preview, а совершенствуется скорость и используемая память.
Если виртуальные потоки хороши для синхронного кода, то на C# его уже не используют для асинхронных методов
Была проблема с поддержкой Windows XP. Там нужен был четвертый фреймворк.
S>>·>Допустим. Вопрос-то в чём? Что тебе надо отличать и с какой целью?
S>>Вопрос в том как отличить дожидаться задачи или не надо?
·>Это вопрос бизнес-требований. Но, как правило, дожидаться надо всегда.
·>Напомню. Мы сравниваем вот такой код: var res = await task; // или в синхронном варианте int res = task.Result;
·>В обоих случаях код дожидается завершения задачи.
Я не знаю, что ты там сравниваешь, я просто привел пример использования Task для асинхронного и синхронного кода
S>>>>>> В той же Java используются FutureTask. Callable и Future
S>>>>>>Казалось бы зачем?
S>>>>·>Не обязательно. В моём примере выше — не используются. Ещё раз: Это ортогональные понятия.
S>>>> Тогда зачем они нужны?
S>>·>Кому нужны? Для чего нужны? Ещё раз: в моём примере параллельного кода они не нужны (но можно, если очень хочется).
S>> Раз они есть значит нужны.
·>Нет, не значит. Future появилось в java версии 1.5 (это 2004 год). А виртуальные потоки в версии 21 (это 2023 год).
Ну то есть зоопарк.
S>> В примере FutureTask. Callable и Future выполняются паралельно с текущим кодом и затем дожидаются результата.
·>И?
S>>·>Ты опять послал ссылку, однако, статью прочитать не смог.
S>> То есть ты утверждаещшь, что в Ява нет зоопарка и проблем со API structured concurrenc
·>Единственная проблема на сегодняшний день — оно preview. Но это не мешает писать простой синхронный код.
Ну вот оказывается еще и preview. При этом никакого преимущества перед async/await практически нет.
async/await более универсальный вариант с использованием Task.WhenAny, Task.WhenAll, TaskCompletionSource, CancellationToken.
При этом давно уже не Preview, а совершенствуется скорость и используемая память.
Если виртуальные потоки хороши для синхронного кода, то на C# его уже не используют для асинхронных методов
В 2012 году с выходом C# 5.0 в языке программирования C# появились ключевые слова async и await для асинхронного программирования.
Была проблема с поддержкой Windows XP. Там нужен был четвертый фреймворк.
Re[51]: Можно ли избавиться от async|await?
Здравствуйте, ·, Вы писали:
S>>·>Допустим. Вопрос-то в чём? Что тебе надо отличать и с какой целью?
S>>Вопрос в том как отличить дожидаться задачи или не надо?
·>Это вопрос бизнес-требований. Но, как правило, дожидаться надо всегда.
·>Напомню. Мы сравниваем вот такой код: var res = await task; // или в синхронном варианте int res = task.Result;
·>В обоих случаях код дожидается завершения задачи.
Я не знаю, что ты там сравниваешь, я просто привел пример использования Task для асинхронного и синхронного кода
S>>>>>> В той же Java используются FutureTask. Callable и Future
S>>>>>>Казалось бы зачем?
S>>>>·>Не обязательно. В моём примере выше — не используются. Ещё раз: Это ортогональные понятия.
S>>>> Тогда зачем они нужны?
S>>·>Кому нужны? Для чего нужны? Ещё раз: в моём примере параллельного кода они не нужны (но можно, если очень хочется).
S>> Раз они есть значит нужны.
·>Нет, не значит. Future появилось в java версии 1.5 (это 2004 год). А виртуальные потоки в версии 21 (это 2023 год).
Ну то есть зоопарк.
S>> В примере FutureTask. Callable и Future выполняются паралельно с текущим кодом и затем дожидаются результата.
·>И?
S>>·>Ты опять послал ссылку, однако, статью прочитать не смог.
S>> То есть ты утверждаещшь, что в Ява нет зоопарка и проблем со API structured concurrenc
·>Единственная проблема на сегодняшний день — оно preview. Но это не мешает писать простой синхронный код.
Ну вот оказывается еще и preview. При этом никакого преимущества перед async/await практически нет.
async/await более универсальный вариант с использованием Task.WhenAny, Task.WhenAll, TaskCompletionSource, CancellationToken.
При этом давно уже не Preview, а совершенствуется скорость и используемая память.
Если виртуальные потоки хороши для синхронного кода, то на C# его уже не используют для асинхронных методов
Была проблема с поддержкой Windows XP. Там нужен был четвертый фреймворк.
Кстати уже с существующем ИИ помошниками, можно легко отрефакторить через Roslyn старый код для использования async/await если у метода есть двойник с суффиксом Async
S>>·>Допустим. Вопрос-то в чём? Что тебе надо отличать и с какой целью?
S>>Вопрос в том как отличить дожидаться задачи или не надо?
·>Это вопрос бизнес-требований. Но, как правило, дожидаться надо всегда.
·>Напомню. Мы сравниваем вот такой код: var res = await task; // или в синхронном варианте int res = task.Result;
·>В обоих случаях код дожидается завершения задачи.
Я не знаю, что ты там сравниваешь, я просто привел пример использования Task для асинхронного и синхронного кода
S>>>>>> В той же Java используются FutureTask. Callable и Future
S>>>>>>Казалось бы зачем?
S>>>>·>Не обязательно. В моём примере выше — не используются. Ещё раз: Это ортогональные понятия.
S>>>> Тогда зачем они нужны?
S>>·>Кому нужны? Для чего нужны? Ещё раз: в моём примере параллельного кода они не нужны (но можно, если очень хочется).
S>> Раз они есть значит нужны.
·>Нет, не значит. Future появилось в java версии 1.5 (это 2004 год). А виртуальные потоки в версии 21 (это 2023 год).
Ну то есть зоопарк.
S>> В примере FutureTask. Callable и Future выполняются паралельно с текущим кодом и затем дожидаются результата.
·>И?
S>>·>Ты опять послал ссылку, однако, статью прочитать не смог.
S>> То есть ты утверждаещшь, что в Ява нет зоопарка и проблем со API structured concurrenc
·>Единственная проблема на сегодняшний день — оно preview. Но это не мешает писать простой синхронный код.
Ну вот оказывается еще и preview. При этом никакого преимущества перед async/await практически нет.
async/await более универсальный вариант с использованием Task.WhenAny, Task.WhenAll, TaskCompletionSource, CancellationToken.
При этом давно уже не Preview, а совершенствуется скорость и используемая память.
Если виртуальные потоки хороши для синхронного кода, то на C# его уже не используют для асинхронных методов
В 2012 году с выходом C# 5.0 в языке программирования C# появились ключевые слова async и await для асинхронного программирования.
Была проблема с поддержкой Windows XP. Там нужен был четвертый фреймворк.
Кстати уже с существующем ИИ помошниками, можно легко отрефакторить через Roslyn старый код для использования async/await если у метода есть двойник с суффиксом Async