5 ms·

This is a landmark release for .NET. The most important since at least framework 4.0 maybe even 3.0. We are getting: - Span<T>/Memory<T> : A 0-copy, unified

This is a landmark release for .NET. The most important since at least framework 4.0 maybe even 3.0. We are getting: - Span<T>/Memory<T> : A 0-copy, unified way of accessing Managed or Unmanaged memory. - Channel<T> : High performance thread-safe queues (like go channels) - Pipelines : an async, 0-copy version of Stream - In-box support for Array/Buffer pooling (finally!) (MemoryPool, ArrayPool) - Better primitives for pointer manipulation and memory marshaling. (MemoryMarshal) - New primitives for high performance parsers and formatters (System.Buffers.Binary and System.Buffers.Text) - Improved support for SSE/NEON via Vector<T> - Microsoft.Windows.Compatibility : Windows specific APIs on .NET Core (Registry, EventLog, NamedPipes...) - Tiered Compilation - Faster tooling - Wider Platform support If you write code on .NET, you should [Edit] evaluate this release with to see if it fits your business needs [/Edit] Doubly so if you care about runtime performance.

quickthrower2 8y ago
Where can I find out more about Channel<T>? I've been googling but it's hard to find anything (especially as Channel 9, and old WCF channels comes up a lot in the results).
- ihsw2 8y ago
  The closest analogue is probably `ConcurrentQueue<T>`. https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110)....
  - oaiey 8y ago
    Nope. Not the same. System.IO.Pipelines is final name of Channels
    - oaiey 8y ago
      I stand corrected. See other replies.
- oaiey 8y ago
  Channel was an early prototype name of System.IO.Pipelines. see https://github.com/davidfowl/Channels https://github.com/davidfowl/Channels
  - algorithmsRcool 8y ago
    Yes, but the Channel<T> i am referring to is a separate project from Stephen Toub that came from CoreFxLab
    - oaiey 8y ago
      Damn. Naming is hard right :)
- algorithmsRcool 8y ago
  The Docs on Channel<T> are currently lacking :( But it is pretty simple to use. It is in nuget package "System.Threading.Channels". You basically call Channel.CreateBounded<T>(int) to create a channel that will buffer a limited number of T objects. A Channel has a ChannelReader and ChannelWriter which are two ends of the same channel. The reader is the output side, the writer is the input side. Each side exposes methods to synchronously try to Read or Write or asynchronously Read or Write (respectively). It supports "Completion" meaning that the Writer can signal the Reader(s) that it is done writing forever. For example imagine you had a channel that was for Log Messages. A bunch of readers might be listening, but then the App shuts down. The writer can call "Complete()" on the channel and the Readers will get wake up and get a message that there is no more messages and flush themselves and shut down. As a note you will need to run your own processing thread to await messages from the channel. Unlike Dataflow which will span it's own taks to handle messages. I will write up an example Gist and reply to this thread in a little bit. Other notes: - The API is very similar to Dataflow since Stephen Toub wrote them both. - It is extremely fast. I have seen > 1.25M messages per second in my benchmarks. - It is mostly allocation free due to using the new ValueTask<T> which is a struct Futher Reading: https://www.nuget.org/packages/System.Threading.Channels/ https://www.nuget.org/packages/System.Threading.Channels/ https://apisof.net/catalog/System.Threading.Channels https://apisof.net/catalog/System.Threading.Channels
  - algorithmsRcool 8y ago
    Here is the example code. Comments and Questions are welcome. https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e43fe8ffdf89b32c https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e4...
  - dmfowacc 8y ago
    What's the difference between this and the BlockingCollection<T>? Aside from being async-friendly it looks pretty similar. You can have a bounded collection with limited size, and completing the writes looks similar too - collection.GetConsumingEnumerable() responds the same way.
    - 8y ago
- manigandham 8y ago
  There is this readme in the original Channel<T> Stephen Toub's branch: https://github.com/stephentoub/corefxlab/blob/master/src/System.Threading.Tasks.Channels/README.md https://github.com/stephentoub/corefxlab/blob/master/src/Sys...
euroclydon 8y ago
Channel<T>? Where is anything on that please?
- deleted 8y ago
  [deleted]
- algorithmsRcool 8y ago
  I responded elsewhere in this thread. https://news.ycombinator.com/item?id=17190877 https://news.ycombinator.com/item?id=17190877
da_chicken 8y ago
> If you write code on .NET, you should adopt this release ASAP. That really depends what classes you use. There are still a lot of classes that haven't been implemented in .Net Core and many of them supposedly won't be implemented. Others were re-implemented and renamed and might not match features. You'll want to move to .Net Core eventually, but not every .Net release is going to be easy to move. Moving from .Net Framework to .Net Core is like moving from .Net Framework to mono. It's mostly similar, but it's still wholly different and not intended to be a 100% drop in replacement. The Microsoft.Windows.Compatibility namespace isn't new at all. At least that's what the Windows Compatibility Pack for .Net Core [0] used at the end of 2017. It looks like it might just finally be out of the preview stages. [0]: https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/ https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcin...
jadbox 8y ago
is Span<T>/Memory<T> and Channel<T> supported for use in F#?
- algorithmsRcool 8y ago
  Uhh, Span/Memory support is coming soon https://github.com/fsharp/fslang-suggestions/issues/648 https://github.com/fsharp/fslang-suggestions/issues/648 Channel<T> uses ValueTask<T> which is kinda painful in F# for now. https://github.com/fsharp/fslang-suggestions/issues/581 https://github.com/fsharp/fslang-suggestions/issues/581
  - jadbox 8y ago
    It's a little sad to hear that this wasn't considered part of MS core effort for the 2.1 rollout. I think the challenge is C# is viewed as 'good enough' with incremental language improvements, while F# gets dragged behind via support from the community (although dedicated, they are not large). I'm wondering if this situation will ever change. I already know of companies sceptical of adopting F# because of lack of perceived commitment by MS.
    - algorithmsRcool 8y ago
      I feel your pain. F# has effectively been punished for being so innovative. They had tuples, async/await, and match statements a decade ago and every time C# adopts one of their feature they change the implementation and make F# retool. It's kinda awful. At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to.
      - daeken 8y ago
        > At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to. I've been hoping for basically the same thing. That said, putting any new language on top of Roslyn (not just using it for IL generation, but actually making it a proper provider a la C#) is 1) not supported, and 2) not seeming like it's going to be. I have a language on .NET that I would love to build into a first-class Roslyn provider but there just isn't any support for that right now. Maybe F# folks inside MS can work to change that.
pjmlp 8y ago
> If you write code on .NET, you should adopt this release ASAP. Doubly so if you care about runtime performance. I care about performance, but: Still have customers on .NET 4.0. .NET Core 2.1 doesn't do EF6, Forms or WPF, need to wait for 3.0 for that. Not all third party libraries are already on Core. Given all that, Core 2.1 is full of goodies that I will surely play around with.
- algorithmsRcool 8y ago
  Yeah, our clients are on Framework I feel your pain. ...But reading between the lines, you probably still have clients on XP (.NET 4.0). That's gotta sting. We made a fuss about TLS1.2 support being required and forced them to upgrade to Win7/.NET 4.5.2 at least. I have gotten gotten a smallish winforms app to work with the new .csproj format. But it's painful. WPF is probably a nightmare. As an aside if you make it to .NET 4.5+ and get async/await. It works great with winforms and presumably WPF!
  - dm3 8y ago
    You can get async/await on .NET 4.0 using Microsoft.Bcl.Async
    - pjmlp 8y ago
      Kind of, it has some issues if you try to use it with Forms.
  - pjmlp 8y ago
    Yep it was something that started on XP and transitioned to 7. Nope, we cannot make it to .NET 4.5+ due to some third party libraries, which is a bummer, because we are stuck with BackgroundWorker as TPL had some bugs with Forms on 4.0, which were only fixed on 4.5. It is only one project thought, the other issue are the IT upgrade policies regarding developer images.
- zamalek 8y ago
  > Still have customers on .NET 4.0. Note that you don't have to install netcore on machines, you can create self-contained releases[1]. > EF6, Forms or WPF Depending on your architecture you may be able to upgrade to netcore piecewise (i.e., microservices over "dumb" protocols like HTTP or gRPC). We are currently turning our monolith into microservices; porting to netcore where possible (using an anti-corruption layer where not). We've only just started but are already reaping benefits. [1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/#self-contained-deployments-scd https://docs.microsoft.com/en-us/dotnet/core/deploying/#self...
gitgacutils 8y ago
> If you write code on .NET, you should adopt this release ASAP. If you require the new features maybe, but if you are writing enterprise code, you shouldn't rush into things. > Doubly so if you care about runtime performance. Everyone cares about runtime performance, but if your software isn't experiencing performance issues, there is no need to rush into things. Or at the very least, reach out to your clients to get a feel about their schedules and expectations. #1 rule: if it ain't broke, don't fix it.
- jrs95 8y ago
  I don't think he was suggesting anyone rush into anything. At the same time, a lot of "enterprise" software is still running on Java versions from over a decade ago, so perhaps they'd benefit if they had someone rushing them.
- algorithmsRcool 8y ago
  You are very correct, I'll try to temper my enthusiasm.
  - some_account 8y ago
    This is why I can't work in enterprise.
    - oaiey 8y ago
      Smart man. Enterprise Dev/Arch here ;)
- carlhjerpe 8y ago
  This is how legacy code is created isn't it?
  - ozim 8y ago
    What is wrong with legacy code? Isn't every code that is deployed to production legacy? Because you cannot just change it.
megaman22 8y ago
Unfortunately it's still a non-starter, because so many things I need that are also Microsoft SDKs are not ported, nor are they likely to ever be. Also, we need a GUI, of some kind.
- manigandham 8y ago
  Which SDKs? Also there are several cross-platform GUI frameworks for .NET core already, it's really not worth that much to have yet another one. Blazor (.NET webassembly) + Electron is an interesting option though for the future.
  - megaman22 8y ago
    Various enterprisy things that tie in with Office in some way, shape, or fashion. The biggest one being the Skype for Business server SDK, which is some kind of bastard red-haired step-child, receiving only the most token updates since 2010, yet is massively important for doing anything productive that isn't supported out-of-the-box with their enterprise unified communications platform.
    - manigandham 8y ago
      I believe much of that is now deprecated in favor of Office 365 APIs with the Microsoft Teams layer for communications. Are you stuck on Skype for business due to enterprise policy?
      - megaman22 8y ago
        Mostly due to customers that buy our software that are still running EOL versions of these products, or are in industries where running a SAAS version is never going to fly. There is no Teams API to speak of, I'm super confused why Microsoft is pushing it so hard when they are wildly behind on the integrations that were promised already, and the functionality is behind the product that it is supposed to replace.
    - zamalek 8y ago
manigandham 8y ago
Thanks for the gist with the channels implementation. I wish they worked on their release notes with samples for all the smaller features like formatters, pooling and channels. Too much of it is buried in github issues.

quickthrower2 8y ago

Where can I find out more about Channel<T>? I've been googling but it's hard to find anything (especially as Channel 9, and old WCF channels comes up a lot in the results).

ihsw2 8y ago
The closest analogue is probably `ConcurrentQueue<T>`. https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110)....
- oaiey 8y ago
  Nope. Not the same. System.IO.Pipelines is final name of Channels
  - oaiey 8y ago
    I stand corrected. See other replies.
oaiey 8y ago
Channel was an early prototype name of System.IO.Pipelines. see https://github.com/davidfowl/Channels https://github.com/davidfowl/Channels
- algorithmsRcool 8y ago
  Yes, but the Channel<T> i am referring to is a separate project from Stephen Toub that came from CoreFxLab
  - oaiey 8y ago
    Damn. Naming is hard right :)
algorithmsRcool 8y ago
The Docs on Channel<T> are currently lacking :( But it is pretty simple to use. It is in nuget package "System.Threading.Channels". You basically call Channel.CreateBounded<T>(int) to create a channel that will buffer a limited number of T objects. A Channel has a ChannelReader and ChannelWriter which are two ends of the same channel. The reader is the output side, the writer is the input side. Each side exposes methods to synchronously try to Read or Write or asynchronously Read or Write (respectively). It supports "Completion" meaning that the Writer can signal the Reader(s) that it is done writing forever. For example imagine you had a channel that was for Log Messages. A bunch of readers might be listening, but then the App shuts down. The writer can call "Complete()" on the channel and the Readers will get wake up and get a message that there is no more messages and flush themselves and shut down. As a note you will need to run your own processing thread to await messages from the channel. Unlike Dataflow which will span it's own taks to handle messages. I will write up an example Gist and reply to this thread in a little bit. Other notes: - The API is very similar to Dataflow since Stephen Toub wrote them both. - It is extremely fast. I have seen > 1.25M messages per second in my benchmarks. - It is mostly allocation free due to using the new ValueTask<T> which is a struct Futher Reading: https://www.nuget.org/packages/System.Threading.Channels/ https://www.nuget.org/packages/System.Threading.Channels/ https://apisof.net/catalog/System.Threading.Channels https://apisof.net/catalog/System.Threading.Channels
- algorithmsRcool 8y ago
  Here is the example code. Comments and Questions are welcome. https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e43fe8ffdf89b32c https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e4...
- dmfowacc 8y ago
  What's the difference between this and the BlockingCollection<T>? Aside from being async-friendly it looks pretty similar. You can have a bounded collection with limited size, and completing the writes looks similar too - collection.GetConsumingEnumerable() responds the same way.
  - 8y ago
manigandham 8y ago
There is this readme in the original Channel<T> Stephen Toub's branch: https://github.com/stephentoub/corefxlab/blob/master/src/System.Threading.Tasks.Channels/README.md https://github.com/stephentoub/corefxlab/blob/master/src/Sys...

euroclydon 8y ago

Channel<T>? Where is anything on that please?

deleted 8y ago
[deleted]
algorithmsRcool 8y ago
I responded elsewhere in this thread. https://news.ycombinator.com/item?id=17190877 https://news.ycombinator.com/item?id=17190877

da_chicken 8y ago

> If you write code on .NET, you should adopt this release ASAP. That really depends what classes you use. There are still a lot of classes that haven't been implemented in .Net Core and many of them supposedly won't be implemented. Others were re-implemented and renamed and might not match features. You'll want to move to .Net Core eventually, but not every .Net release is going to be easy to move. Moving from .Net Framework to .Net Core is like moving from .Net Framework to mono. It's mostly similar, but it's still wholly different and not intended to be a 100% drop in replacement. The Microsoft.Windows.Compatibility namespace isn't new at all. At least that's what the Windows Compatibility Pack for .Net Core [0] used at the end of 2017. It looks like it might just finally be out of the preview stages. [0]: https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/ https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcin...

jadbox 8y ago

is Span<T>/Memory<T> and Channel<T> supported for use in F#?

algorithmsRcool 8y ago
Uhh, Span/Memory support is coming soon https://github.com/fsharp/fslang-suggestions/issues/648 https://github.com/fsharp/fslang-suggestions/issues/648 Channel<T> uses ValueTask<T> which is kinda painful in F# for now. https://github.com/fsharp/fslang-suggestions/issues/581 https://github.com/fsharp/fslang-suggestions/issues/581
- jadbox 8y ago
  It's a little sad to hear that this wasn't considered part of MS core effort for the 2.1 rollout. I think the challenge is C# is viewed as 'good enough' with incremental language improvements, while F# gets dragged behind via support from the community (although dedicated, they are not large). I'm wondering if this situation will ever change. I already know of companies sceptical of adopting F# because of lack of perceived commitment by MS.
  - algorithmsRcool 8y ago
    I feel your pain. F# has effectively been punished for being so innovative. They had tuples, async/await, and match statements a decade ago and every time C# adopts one of their feature they change the implementation and make F# retool. It's kinda awful. At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to.
    - daeken 8y ago
      > At this point I want F# to do a hard reset, rebuild on top of Roslyn, natively adopt ValueTuple and Task/ValueTask then grow alongside C# like VB tried to. I've been hoping for basically the same thing. That said, putting any new language on top of Roslyn (not just using it for IL generation, but actually making it a proper provider a la C#) is 1) not supported, and 2) not seeming like it's going to be. I have a language on .NET that I would love to build into a first-class Roslyn provider but there just isn't any support for that right now. Maybe F# folks inside MS can work to change that.

pjmlp 8y ago

> If you write code on .NET, you should adopt this release ASAP. Doubly so if you care about runtime performance. I care about performance, but: Still have customers on .NET 4.0. .NET Core 2.1 doesn't do EF6, Forms or WPF, need to wait for 3.0 for that. Not all third party libraries are already on Core. Given all that, Core 2.1 is full of goodies that I will surely play around with.

algorithmsRcool 8y ago
Yeah, our clients are on Framework I feel your pain. ...But reading between the lines, you probably still have clients on XP (.NET 4.0). That's gotta sting. We made a fuss about TLS1.2 support being required and forced them to upgrade to Win7/.NET 4.5.2 at least. I have gotten gotten a smallish winforms app to work with the new .csproj format. But it's painful. WPF is probably a nightmare. As an aside if you make it to .NET 4.5+ and get async/await. It works great with winforms and presumably WPF!
- dm3 8y ago
  You can get async/await on .NET 4.0 using Microsoft.Bcl.Async
  - pjmlp 8y ago
    Kind of, it has some issues if you try to use it with Forms.
- pjmlp 8y ago
  Yep it was something that started on XP and transitioned to 7. Nope, we cannot make it to .NET 4.5+ due to some third party libraries, which is a bummer, because we are stuck with BackgroundWorker as TPL had some bugs with Forms on 4.0, which were only fixed on 4.5. It is only one project thought, the other issue are the IT upgrade policies regarding developer images.
zamalek 8y ago
> Still have customers on .NET 4.0. Note that you don't have to install netcore on machines, you can create self-contained releases[1]. > EF6, Forms or WPF Depending on your architecture you may be able to upgrade to netcore piecewise (i.e., microservices over "dumb" protocols like HTTP or gRPC). We are currently turning our monolith into microservices; porting to netcore where possible (using an anti-corruption layer where not). We've only just started but are already reaping benefits. [1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/#self-contained-deployments-scd https://docs.microsoft.com/en-us/dotnet/core/deploying/#self...

gitgacutils 8y ago

> If you write code on .NET, you should adopt this release ASAP. If you require the new features maybe, but if you are writing enterprise code, you shouldn't rush into things. > Doubly so if you care about runtime performance. Everyone cares about runtime performance, but if your software isn't experiencing performance issues, there is no need to rush into things. Or at the very least, reach out to your clients to get a feel about their schedules and expectations. #1 rule: if it ain't broke, don't fix it.

jrs95 8y ago
I don't think he was suggesting anyone rush into anything. At the same time, a lot of "enterprise" software is still running on Java versions from over a decade ago, so perhaps they'd benefit if they had someone rushing them.
algorithmsRcool 8y ago
You are very correct, I'll try to temper my enthusiasm.
- some_account 8y ago
  This is why I can't work in enterprise.
  - oaiey 8y ago
    Smart man. Enterprise Dev/Arch here ;)
carlhjerpe 8y ago
This is how legacy code is created isn't it?
- ozim 8y ago
  What is wrong with legacy code? Isn't every code that is deployed to production legacy? Because you cannot just change it.

megaman22 8y ago

Unfortunately it's still a non-starter, because so many things I need that are also Microsoft SDKs are not ported, nor are they likely to ever be. Also, we need a GUI, of some kind.

manigandham 8y ago
Which SDKs? Also there are several cross-platform GUI frameworks for .NET core already, it's really not worth that much to have yet another one. Blazor (.NET webassembly) + Electron is an interesting option though for the future.
- megaman22 8y ago
  Various enterprisy things that tie in with Office in some way, shape, or fashion. The biggest one being the Skype for Business server SDK, which is some kind of bastard red-haired step-child, receiving only the most token updates since 2010, yet is massively important for doing anything productive that isn't supported out-of-the-box with their enterprise unified communications platform.
  - manigandham 8y ago
    I believe much of that is now deprecated in favor of Office 365 APIs with the Microsoft Teams layer for communications. Are you stuck on Skype for business due to enterprise policy?
    - megaman22 8y ago
      Mostly due to customers that buy our software that are still running EOL versions of these products, or are in industries where running a SAAS version is never going to fly. There is no Teams API to speak of, I'm super confused why Microsoft is pushing it so hard when they are wildly behind on the integrations that were promised already, and the functionality is behind the product that it is supposed to replace.
  - zamalek 8y ago

manigandham 8y ago

Thanks for the gist with the channels implementation. I wish they worked on their release notes with samples for all the smaller features like formatters, pooling and channels. Too much of it is buried in github issues.