Hacker News Reader

Comment by SideburnsOfDoom | Hacker News Reader

Is async streams and "await foreach" just syntactic sugar for things that could still be done beforehand, albeit with more code?

I mean, "slightly more code" - you can say the same about "async ... await" in general, but then it's "insanely more code" and huge potential for error.

It looks that way to me.

View on HN

Not quite. F# and a few other languages have had this capability for a few years now. Its effectively making the MoveNext() function on the enumerator object an async operation instead of a blocking one. This allows a foreach loop for example to wait until the next object comes without tying up the thread. Useful for things like pulling off a remote message queue, messages off a network, etc where the waiting for the next item in your "foreach" loop involves async/task based operations and you don't want to block the current thread.

nope async streams weren't really possible before without an unnecessary allocation.

i.e. a List<Task<T>> is not the same as an AsyncEnumerable<T>. List<Func<Task<T>>> would be more equivalent, but you needed to have a List<T> which you need to fill beforehand.

>nope async streams weren't really possible before without an unnecessary allocation.

You would have to define a few custom types. I have written code that looks something like

  while (! ctx.IsCancellationRequested)
  {
    var data = await source.GetData();  
    await Process(data);  
  }

Where source is an interface that we have defined. This is not much more complex than an async enumerable.

It's definitely possible, and if you save an allocation then that's a step up, but not a game changer for most business process.

Reply on news.ycombinator.com