Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

281–290 of 466 posts

Re: .NET 5.0

#281
post #51

Earlier quoted context omitted.

Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dealing with a UI and make a method async, then suddenly you have a ton more problems to deal with, like what happen if the user changes the state while you are waiting for an async call. That increases a lot the complexity of the code. Which is why I am lukewarm…

Agreed. Async is nice on the server but on the desktop it’s a real problem. For a while they had both sync and async but now it’s often only async. I just finished an app that had to shutdown while some async operations were still not finished. Really hard to manage compared to using threads.

The move to async trades one set of problems for another. Yes, implementing cooperative cancellation is tricky. On the other hand, recovering from corrupted state caused by Thread.Abort is also tricky.

Re: .NET 5.0

#282

> From what we’ve seen and heard so far, .NET 5.0 delivers significant value without much effort to upgrade. From the previous version of .Net Core only. They've done absolutely nothing to make migrating from MVC 5 any easier, while proclaiming that this somehow merges .Net Framework and .Net Core. Going from MVC 5 to .Net 5.0 MVC is a complete re-write of the web layer from an empty project upon up (even according t…

I understand the naming. They want people to switch to the other track (Core). With this naming it’s like the other teach makes a turn and continues in front of the net4X track.

This makes it easier for me to make a case to managers that 4.8->5.0 is an obvious migration to do. Selling 4.8 to core4 would sound scary.

Re: .NET 5.0

#283
post #29

Earlier quoted context omitted.

I found Go to be a really nice replacement for C#. It has the static typing and garbage collection, but you also get a self-contained binary executing without the requirement of an external runtime environment. I also discovered that I don't miss classes at all.

I have migrated from C# to Node.js, my code is now 20x times shorter (from 800 files to 40 files), simpler to read and maintain, there is 100x more packages available on NPM compared to nuget. Performance is stellar, even better than in C# for my use case (Mega tons of concurrent queries executed in 1-5ms avg) And also I don't have to fight against the language to do what I want to do ... No classes, no types, no con…

> my code is now 20x times shorter (from 800 files to 40 files)

Well, do you have all of the bells an whistles that you had with .NET? I mean, you can shrink a .NET API down to pretty much just 1 file if you really want to. The question is if you should.

WebHost.CreateDefaultBuilder().Configure(app => app.Run(c => c.Response.WriteAsync("Hello world!"))).Build().Run();

Re: .NET 5.0

#284
post #258

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time. As a result, I really wanted to adopt .N…

> Azure will win you over from AWS every time.

Going to have to disagree here.

That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again in the future, or work somewhere that uses it.

Take my advice: just don't use it. It's not worth it. Use AWS, use GCP, use Digital Ocean. Use some random cloud provider. Just don't use Azure.

Re: .NET 5.0

#285
post #213

Earlier quoted context omitted.

We started to use F# with Elm and it works very well. Statically typed all the way.

This year I converted a standard F#+Giraffe backend and React+Typescript frontend to use Feliz [0] with Fable.Remoting [1] and it has been a pleasant experience. [0] https://github.com/Zaid-Ajaj/Feliz [1] https://github.com/Zaid-Ajaj/Fable.Remoting

why not go all the way with fable + elmish for the Frontend?

Re: .NET 5.0

#286

Note that .NET 5.0 is not an LTS release: > .NET 5.0 is a current release. That means that it will be supported for three months after .NET 6.0 is released. As a result, we expect to support .NET 5.0 through the middle of February 2022. .NET 6.0 will be an LTS release and will be supported for three years, just like .NET Core 3.1.

I believe Microsoft are still recommending people move to .NET 5 though. Unless you're extremely risk averse it seems like a very simple upgrade from 3.1 to 5 and hopefully 5 to 6 next November (which will be the LTS release) is the same.

I just did a straight up find-replace for `netcoreapp3.1` -> `net5.0` across 66 projects, built and passed tests without a hitch. Zero issues so far outside of the warnings resulting from enhanced nullable reference type smarts .

Re: .NET 5.0

#287

Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction. We are very excited to get our hands dirty with .NET 5 sometime in Q1 next year. We currently run on .NET Core 3.1. I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase. Our migration from 4.7=>2.0 was the most difficult, but…

>I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase

FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!

Re: .NET 5.0

#288
post #203

Earlier quoted context omitted.

> There is no parallel work to be accomplished here. Concurrency is not parallelism [1]. [1]: https://blog.golang.org/waza-talk

Each HTTP request in a Go webserver spawns a goroutine, and there is no need to think about "freeing up threads" since coroutines are not OS threads. There's also no need to leak the word `async` all over your codebase. The problem being solved here with async/await is also being caused by async/await.

Goroutine like .NET IAwaitable/Task both abstract the thread away. No one thinks about threads when programming async/await code despite in any await keyword a thread change can happen.

Both solve the same problem with the same technique (under the hood it is all the same). One language had the benefit of late birth (go), the other suffers with its friends through a library/language migration (C#, C++, Java, JavaScript, Python, ...). async/await is effectively the modernization of structural programming to benefit from modern concurrency.

Re: .NET 5.0

#289
post #258

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time. As a result, I really wanted to adopt .N…

> Azure will win you over from AWS every time. Going to have to disagree here. That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again…

Wow! Hot take. What Azure services were you using?

Re: .NET 5.0

#290

Earlier quoted context omitted.

So you want to pause the thread and keep it from processing other requests for simplicity?

That is literally how php does. Let's fire a thread for every request and block on db reading or any action that require io. And it seems it works (at least for php)

Until you look who is faster and has more througput. The only way how PHP can do (via swoole and friends) is by adopting non-blocking frameworks. And remember througput * duration = Serverlese costs
Post reply on HN