Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

181–190 of 466 posts

Re: .NET 5.0

#181

Post by ocdtrekkie »

mwcampbell wrote: post #177
ocdtrekkie wrote: post #172

Earlier quoted context omitted.

I recognize this. But so is WinForms and plenty of other Windows-specific APIs. System.Speech, being as you recognize, a crucial accessibility feature, and it should be considered extremely high priority, even if the usage percentage is low. Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users. It'd be nice for a cross-platform local speech library to be available on .…

> System.Speech, being as you recognize, a crucial accessibility feature I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play th…

I mean, nearly all outstanding documentation and tutorials on how to implement speech in Windows is conveyed via those APIs. I know I don't have the skills to replace my System.Speech calls with generic COM interop, I'm willing to bet that would ring true for a lot of .NET developers relying on the .NET Framework today.

At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core. How many businesses are going to do that, versus say, drop that feature, presumably due to "low usage"? Is Microsoft really serving the accessibility community here? Making it harder to add accessibility to software is going to negatively impact accessibility being available in software.

And if it's just a convenience wrapper, it should be trivial for Microsoft to reimplement it: And it'd be far less wasteful for Microsoft to do it for everyone than expect everyone who uses it for accessibility features to reimplement it themselves.

Re: .NET 5.0

#182

Post by francisl »

Since Apple is announcing the new Macs with M1 SoC today, I'm wondering if it will support it from day 1 or we will have to wait?!

edit:

I guess I can't read. `We expect that Apple will announce new Apple Silicon-based Mac computers any day now. We already have early builds of .NET 6.0 for Apple Silicon and have been working with Apple engineers to help optimize .NET for that platform. We’ve also had some early community engagement on Apple Silicon (Credit @snickler).`

Still wondering for .net 5 though

Re: .NET 5.0

#183

Post by nullsense »

ClumsyPilot wrote: post #88
mmis1000 wrote: post #50

Earlier quoted context omitted.

For simplicity? Just like how js get async await thing eventually.

I fail to see how this is sensible in the slightest - you then have to re-write the code if you want the application to scale. Otherwise you are wasting memory, trashing GC, spawning all these extra threads.All awaitable operations like network requests, disk reads, etc, should be async. Why would you write potato code?

>Why would you write potato code?

Side note: this gave me a good laugh. I just pictured it being used as a sign off on PR reviews.

Is it a technical term? If it's not I think it should be, and if it is I want to know what the exact nature of potato code is, so I can call it out when I see it in the wild.

Re: .NET 5.0

#184

Post by lukevp »

spaetzleesser wrote: post #147
cm2187 wrote: 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.

How is Task.WaitAll different from Thread.Joining a bunch of threads? Or if you were cancelling tasks, using cancellation tokens?

Re: .NET 5.0

#185

Post by manigandham »

CodesInChaos wrote: post #78
withinboredom wrote: post #52

Earlier quoted context omitted.

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

Unless you have a lot of concurrent connections (C10k problem), having one thread per active request isn't a big deal. For my web applications, requests spend most of their time waiting on the database, and an open transaction is at least as expensive as a thread in an app server for many databases. So I agree that for most applications async isn't worth the complexity they introduce. In many implementations they als…

.NET has millions of developers. They optimize for the greatest impact and async is necessary for performance. In fact high-performance is an explicit goal of the framework and it ranks at the top of the TechEmpower benchmarks.

Even if you don't need the performance, async code helps keep your app responsive and use less resources on your server. It's far better to have async and not need it then try to refactor your entire ap when it's necessary.

Re: .NET 5.0

#186

Post by doodpants »

mmd45 wrote: post #151
josteink wrote: post #137

Earlier quoted context omitted.

Yeah. I guess it depends on how it gets installed, but there’s absolutely nothing preventing it from running side-by-side. I’ve been hot-swapping 3.1 and 5.0-rc2 for projects, preparing for the final 5.0 release.

so, i see 4 different runtime installs (base/aspnet/aspnet-hosting/desktop) here https://github.com/dotnet/core/blob/master/release-notes/5.0... . where can i find instructions for doing a side by side install? thanks

Every version of .NET Core has always installed side-by-side with previous versions. There's no way to avoid it.

Re: .NET 5.0

#187

Post by manigandham »

jniedrauer wrote: post #140
lwansbrough wrote: post #31

Earlier quoted context omitted.

Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?

> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.

Async means non-blocking, not parallel. It helps keep the app responsive while using less resources and avoiding lockups and crashes.

.NET is used by millions of developers. Strong and scalable foundations matter, and performance is an explicit goal with asp.net being one of the fastest web frameworks. Async is a core part of this.

There's very little - if any - overhead that you need to worry about with async code from the language to Visual Studio.

Re: .NET 5.0

#188

Post by nullsense »

CodesInChaos wrote: post #78
withinboredom wrote: post #52

Earlier quoted context omitted.

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

Unless you have a lot of concurrent connections (C10k problem), having one thread per active request isn't a big deal. For my web applications, requests spend most of their time waiting on the database, and an open transaction is at least as expensive as a thread in an app server for many databases. So I agree that for most applications async isn't worth the complexity they introduce. In many implementations they als…

The web server uses a threadpool anyway. You're not creating threads that don't already exist. You're simply able to use the threads you do have for other tasks while waiting for I/O.

Re: .NET 5.0

#189

Post by mwcampbell »

ocdtrekkie wrote: post #181
mwcampbell wrote: post #177

Earlier quoted context omitted.

> System.Speech, being as you recognize, a crucial accessibility feature I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play th…

I mean, nearly all outstanding documentation and tutorials on how to implement speech in Windows is conveyed via those APIs. I know I don't have the skills to replace my System.Speech calls with generic COM interop, I'm willing to bet that would ring true for a lot of .NET developers relying on the .NET Framework today. At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Fram…

> At minimum, you're adding a "rewrite your accessibility code" cost to anyone moving from .NET Framework to .NET Core.

That would be true if it were common for applications to directly support alternative UI modalities, but that's not how accessibility generally works. An application implements a GUI, including support for the platform accessibility API (hopefully with the help of the GUI framework), and it's up to a separate assistive technology, such as Narrator (for screen reading) or Dragon NaturallySpeaking (for speech input), to use that generic accessibility support to adapt the UI for a specific need.

So if any assistive technologies are using .NET Framework, they might have a bit of difficulty converting to .NET Core. But that's a small number of applications, and in my experience, most Windows ATs use native code anyway. And using SAPI via COM interop isn't hard; you don't have to get down and dirty with P/Invoke or anything similarly low-level.

Re: .NET 5.0

#190

Post by ko27 »

jniedrauer wrote: post #140
lwansbrough wrote: post #31

Earlier quoted context omitted.

Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?

> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.

Async is not used just to enable parallel execution. Using 1 thread per every long running request is a good way to bottleneck your web server.
Post reply on HN