[Semi-OT] Fibers vs. Async / Await

[bauss]

On Wednesday, 11 May 2022 at 13:27:48 UTC, René Zwanenburg wrote:
>
> 3. I don't like the Task\<T> and await noise everywhere. It 
> clutters up the code.
>

You don't have to have a "Task" type that you declare, it could 
simply be T and then the function is just marked async and T 
automatically becomes Task!T.

The reason why C# doesn't do it that way is because they 
envisioned the ability to add your own Task types etc. but that 
has never been implemented or anything, so it's really just 
verbose.

> 4. It's too easy to make a mistake and forget an await 
> somewhere. Yes, an IDE will likely give a warning. No, I still 
> don't like it ;)
>

It's easy to fix, don't allow implicit conversions between Task!T 
and T and thus whenever you attempt to use the result you're 
forced to await it because otherwise you'd get an error from the 
compiler due to mismatching types.

Like the below would definitely fail:

```
async int getNumberAsync();

...

auto number = getNumberAsync();

int otherNumber = 10 * number; // number cannot be used here due 
to it not being implicitly convertible to int. The fix would be 
to await getNumberAsync().
```

> 5. It can put too much pressure on the GC. This won't be a 
> problem when doing an HTTP request or something like that. It 
> is a problem when there's an allocation for reading every 
> single value in a DB query result.
>

It doesn't really put anymore pressure on the GC. The compiler 
converts your code to a state machine and that hardly adds any 
overhead. It makes your functions somewhat linear, that's it. It 
doesn't require many more allocations, at least not more than 
fibers.