The inlining and escape analysis changes are fairly big from a performance perspective.

Also, C# doesn't need nearly as many massive changes like project Valhalla because they got a lot of those design choices right from day 1 (mostly by looking at what Java did that was dumb and avoiding it).

Here `a` and `b` can have different types:

    let! a = fetchA() and! b = fetchB()

Whereas `Promise.all` usually requires all promises to have the same type (returning a `List<T>` or even a `List<obj>`) .

See https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs...

Actually, TypeScript's `Promise.all` can handle different types too.

    const [a, b] = await Promise.all([fetchA(), fetchB()]); // => a: A, b: B

I am talking about C# / F# context where the lists must have homogeneous types.

That TypeScript supports this is yet more complexity introduced to cover usages of an API not designed around types.

The code snippet is in F#. And F# has so called "computation expressions".

Java has had CompletableFuture::allOf for a long time. The new structured concurrency api also has the same capabilities of waiting for futures.

As others point out, that's F#, but yes C# has `async`/`await`, and has all the `Promise` methods, just under the `Task` class instead (and with slightly different names/calling conventions through out).

I think thats F# not C#