Developer on gRPC for .NET here.

gRPC client requires HTTP/2, and HttpClient (the .NET library for making HTTP requests) didn't previously support HTTP/2. The gRPC client actually supports netstandard2.1. Any .NET implementation that supports HTTP/2 should support running the gRPC client.

Kestrel (the .NET web server) already supported HTTP/2 but it required some new features in .NET 3.0 to fully support hosting gRPC services.

I expect that it uses Pipelines ( * ) which is a new high-performance design using Span<T> and related classes inside, and these are new, are not in netstandard2.0.

Moving data onto and off the network efficiently is (one of) the things that Span<T> was created for.

*) https://devblogs.microsoft.com/dotnet/system-io-pipelines-hi...

Pipelines can also be used with much older frameworks: https://www.nuget.org/packages/System.IO.Pipelines/

it can, but then it uses the less-performant shims of Span<T> and company in https://www.nuget.org/packages/System.Memory/

Maybe new C# stuff like default interfaces and some new async crap?

If you're doing networking, there is very useful new stuff in the latest version of C# and .NET,. but it's Spans and Pipelines more than default interfaces.

Async is not new at all, but classes that really leverage it well might be (pipelines again).

> Async is not new at all

I believe GP is referring to async streams[0]. Notwithstanding the colourful language GP used, I think the new async streams are pretty cool.

[0] https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/gen...

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.

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.