Hacker News Reader

> 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/announcin...

> 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.

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.

You are very correct, I'll try to temper my enthusiasm.

This is why I can't work in enterprise.

Smart man. Enterprise Dev/Arch here ;)

This is how legacy code is created isn't it?

What is wrong with legacy code? Isn't every code that is deployed to production legacy? Because you cannot just change it.

There are lots of ways you can end up with legacy code.

I've seen legacy code get created by people postponing platform updates for so long that the upgrade pathways stop being supported, that's one way.

I've also seen legacy code get created by people adopting the platform of the future super-early, and then being left high and dry when the rest of the world decided that platform wasn't actually the future after all, leaving them as the sole maintainers of the entire platform as well as their dependent code.

If your code currently works on standard .net, there's no reason to be in a massive hurry to move to .net core. There's not necessarily any reason to delay, either. It all depends on your business requirements and the investment required. If it's easy for you to move to .net core then by all means do it. If it's gonna be a massive project, let the smaller groups go first.

> I've seen legacy code get created by people postponing platform updates for so long that the upgrade pathways stop being supported, that's one way.

This is something i've seen many times, when you don't update in long enough entire API's might've changed or been replaced and there's no documentation or anyone even remembering the stuff available anymore.

I agree though that one doesn't have to rush new releases, i do however think there should be a plan to upgrade done as soon as there's a new stable release.

I've been working with a softphone that's built for .net framework 3.5, if you want any library you can forget nuget, must get source build and modify manually. Which is suboptimal.

Having a proper test suite and updating when the changes are minimal usually leads to better overall product maintenance.

I dont get these claims to not upgrade unless you're also just as worried about changing a line of code and having it all break too? Make the changes, test the changes, and deploy carefully, just as you would for anything else.

> 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.

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!

You can get async/await on .NET 4.0 using Microsoft.Bcl.Async

Kind of, it has some issues if you try to use it with Forms.

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.

> 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...

I am against microservices versus doing modular architectures, once upon a time they were called SUN-RPC, DCOM, CORBA, SOAP, RMI, Remoting, WCF... so I do have quite some experience in "microservices".

For native GUI applications it is nothing than a waste of resources.

Three tier architectures with modular designs across several assemblies are a much better solution, no need to go after what is cool.

The EF6, Forms and WPF support is the major goal of .NET Core 3.0, so why should I ask our customers to waste money with microservices and application rewrites?

The things you are pointing out are orthogonal to the architectural tactic of microservices...

1) RPC and remoting can leverage microservices, but are not required to. There is a very, very, low probability that people doing DCOM or SOAP were doing microservices. Modularity is an essential feature of microservices. Service experience does not necessarily translate to micro-service experience...

2) Is this GUI app service oriented? That is to say: despite its thick client, is it accessing network and shared resources in the networked environment? Because native GUI apps often talk with webservices. Maybe those are monolithic, maybe they're not, but the resource usage will have to do with development and maintenance of those service and its effect on the (fat) client.

3) Traditional three tier architectures struggle in numerous scenarios (particularly those where microservices thrive). Hexagonal architectures/DDD do well in those areas, provide all the same benefits and more, and are really not "cool" anymore. Also, those design styles can use microservices (or not), they're not dictated by them.

4) .Net Core 3 has a bunch of value adds for thick client WPF apps with no services -- side-by-side installations and such.

5) You should not ask your customers to waste money with microservices, nothing about .Net Core 3 would indicate that you should. Same deal for monolithic services... Just because MS launches something good for apples does not mean you should call your customers and tell them their oranges have to be thrown out.

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).

The closest analogue is probably `ConcurrentQueue<T>`.

https://msdn.microsoft.com/en-us/library/dd267265(v=vs.110)....

Nope. Not the same. System.IO.Pipelines is final name of Channels

I stand corrected. See other replies.

Channel was an early prototype name of System.IO.Pipelines. see https://github.com/davidfowl/Channels

Yes, but the Channel<T> i am referring to is a separate project from Stephen Toub that came from CoreFxLab

Damn. Naming is hard right :)

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://apisof.net/catalog/System.Threading.Channels

Here is the example code. Comments and Questions are welcome.

https://gist.github.com/AlgorithmsAreCool/b0960ce8a3400305e4...

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.

Good question. BlockingCollection is actually a wrapper around a ConcurrentQueue. It provides some nice things like....blocking so the queue can be used in a producer/consumer manner.

Channels does this but has 2 advantages.

1. It is built on the most up-to-date threading primatives (ValueTask) which gives it a perf advantage.

2. It's internal design is very simple and lightweight. BlockingCollection was designed to have swappable guts. Channels are single purpose.

The other nice thing is the channels API is really no nonsense super simple to get GREAT performance out of normal async/await. No tuning really needed. I got >300Krps out of a sequence of chained channels with a buffer size of 1.

Thanks.

This sounds very similar to the channels (Chan [1]) in Haskell, which I really loved playing around with.

[1] http://hackage.haskell.org/package/base-4.11.1.0/docs/Contro...

There is this readme in the original Channel<T> Stephen Toub's branch: https://github.com/stephentoub/corefxlab/blob/master/src/Sys...

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.

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.

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.

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?

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.

That's likely COM, meaning tough luck so far as netcore goes AFAIK. What you can do is wrap it in a service over something like HTTP or gRPC (even with a localhost NIC binding). Your codebase doesn't have to be homogeneous.

My understanding is that they will be porting Windows Forms, WPF, and UWP to .NET Core, in a Windows-only fashion.

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...

> Also, we need a GUI, of some kind.

Would be .NET Core 3 you'd be waiting for then:

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...

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.

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

I responded elsewhere in this thread.

https://news.ycombinator.com/item?id=17190877

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

Uhh, Span/Memory support is coming soon 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

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.

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.

> 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.

C# has a large network effect and it also has very few disadvantages, so there is little motivation to switch to F# for C# devs.

C# does keep getting better, and making the delta between what it offers and what F# offers smaller, at least from what I can see. I've really wanted to get on the F# train, but I just haven't been able to get it out of the station yet.

I'm somewhat astounded that VB.Net is still a thing, however.

F# always suffered from lack of VS tooling support, I was always on the edge waiting for it to be supported on GUI designers just like VB.NET and C#.

Using it mostly for scripting like tasks only.

Then it wasn't relevant for .NET Native support, and finally Microsoft keeps ignoring some vocal anti-MS/C# members in the community, which made me loose any remaining interest.

I rather have C# with some FP like features, than a FP language without tooling support and needless forum discussions.

Regarding VB.NET, it is used quite a lot in some enterprise shops.

I have seen many apps that started as office macros and eventually grew up to be VB.NET ones.

Even if VB.NET is more complex than VB was, it still easier than C# for those office employees that know one or two things about coding.