.NET has channels as part of the standard library.

In C# you must write explicit async/await keywords whereas in Go it is implicit, but the code reads almost the same.

I would argue against using implementation inheritance generally and interfaces sparingly in C# anyways.

Being not super familiar with Go, I think C#'s async/await is similar, isn't it? If you want more complex operations, you might want to look into System.IO.Pipelines.

Nah, totally different than channels. And Goroutines are proper managed threads with their own stacks.

As an aside pipelines are terriblely unergonomic. The public APIs are not fully developed and something simple, like IDK creating an actual processing pipeline, is funky as all hell. Creating a pipe wrapper feels dirty.

The buffer management is cool though and sequence seems like it should have just been made a first class slice type..

.NET’s Pipeline type is not intended for processing-pipelines (surely that would be Windows Workflow Foundation and SSIS?) - it’s meant to be an alternative (and performance-optimised) API for reading and writing to IO streams without faffing around with the differences between MemoryStream, FileStream, and NetworkStream - like if you’re implementing your own network protocol server and client.

See https://learn.microsoft.com/en-us/dotnet/standard/io/pipelin...

The main problem it seems to solve is processing a text or byte range from a stream (be it an endless SSE/WebSocket stream of messages, or just from a huge (multigigabyte+) file on disk - in a non-blocking/async manner.

C# has channels as a library and not a language construct, it lives in System.Threading.Channels namespace.

They do have channels but they don't supply a select equivalent.

Go literally has a Channel class with the same functionality. The major difference is async/await syntax vs goroutine syntax, no?