Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

201–210 of 466 posts

Re: .NET 5.0

#201

So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…

> [Async has] Huge disadvantages with absolutely zero performance gains for 95% of programmers.

One curious thing is that Java has elected to use lightweight threads instead of async methods: https://www.javacodegeeks.com/2019/12/project-loom.html

Their arguments are compelling:

- Works with existing debuggers and debugging techniques.

- Stack traces aren't polluted with irrelevant garbage.

- Doesn't create method apartheid, where async and non-async can't "mix".

- Doesn't force library authors to "buy into" the async model.

Re: .NET 5.0

#202
post #110
post #41

Earlier quoted context omitted.

I use Rider now, VS got to the point of being so slow that frequently I'd have to wait 0.5 seconds for each character I was typing to appear. The performance is utterly, utterly terrible. Yet, all I see from the VS team on Twitter is "look at this new useless feature we've added", when all I needed was for the code I'm typing to appear. God help you if you ever wanted to rename a symbol, it was Schrodinger's rename,…

Actually Visual Studio is quite fast again. It's just that Resharper does its very best to slow it down. I don't believe this will ever change. Well except maybe Microsoft will fully deprecate COM-based in-process extensions.

JetBrains is working hard to fix it: https://blog.jetbrains.com/dotnet/2020/02/24/update-running-...

Re: .NET 5.0

#203

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.

> There is no parallel work to be accomplished here.

Concurrency is not parallelism [1].

[1]: https://blog.golang.org/waza-talk

Re: .NET 5.0

#204
post #44
post #18

As someone who uses .NET daily, but loves Clojure and other functional programming paradigms - Records seem like a very compelling feature. Immutable data structures without any hassle to set up. Simply write “record” where you would normally write “class” and boom, you are working with immutable objects. This is one step closer to one the best features of Clojure IMO -everything is immutable. Additionally, there see…

You probably know, but F# exists if you want a functional language in the .NET ecosystem. Granted, you end up dealing with a bunch of OOP libraries still since .NET is very C#-centered, but the language is pretty good and the integration is painless.

Yes, I’d love to use F#, but not a lot of opportunities out there.

And .NET, like you mentioned, is very C# focused which would become frustrating at times.

Re: .NET 5.0

#205

Does Asp.NET identity still use a Guid for primary key? I remember it being hell trying to convert to int a few years ago which left a sour taste.

Why would you want to.

Re: .NET 5.0

#206
post #41

> It’s already in active use by teams at Microsoft and other companies... This means nothing anymore. MSFT says that about everything they release and users are still often left with the feeling that they are guinea pigs testing a very unfinished product. > For Visual Studio users, you need Visual Studio 16.8 or later to use .NET 5.0 on Windows and the latest version of Visual Studio for Mac) on macOS. The C# extensi…

I use Rider now, VS got to the point of being so slow that frequently I'd have to wait 0.5 seconds for each character I was typing to appear. The performance is utterly, utterly terrible. Yet, all I see from the VS team on Twitter is "look at this new useless feature we've added", when all I needed was for the code I'm typing to appear. God help you if you ever wanted to rename a symbol, it was Schrodinger's rename,…

I've been using Visual Studio 2010, and then 2017 and 2019, with a pretty big solution loaded, and never ran into issues like you mentioned. For me it was always pretty snappy, including refactoring actions.

OTOH I've hardly ever used or installed Resharper (or Rider). When I did try Resharper, I found Visual Studio was dog slow, very much like what you described, and it provided me with very little benefit compared to what I already had in VS.

Re: .NET 5.0

#207
post #184

Earlier quoted context omitted.

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?

The other comment alluded to this, but the crux of the problem is that you can schedule a task to run and wait on the completion of that task, but the only available thread for it to run is the one currently waiting for it to complete. The writeup here isn't bad: https://devblogs.microsoft.com/pfxteam/await-and-ui-and-dead...

Re: .NET 5.0

#208

So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…

I'm so glad I'm not alone. I adore C# and the .NET runtime is so convenient.

But the ASP.NET part feels bloated.

Is there a simpler .NET framework?

Re: .NET 5.0

#209

Earlier quoted context omitted.

> 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 f…

> It helps keep the app responsive while using less resources and avoiding lockups and crashes.

it actually uses more resources. async has a cost, but it is really low.

Re: .NET 5.0

#210

So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…

> [Async has] Huge disadvantages with absolutely zero performance gains for 95% of programmers. One curious thing is that Java has elected to use lightweight threads instead of async methods: https://www.javacodegeeks.com/2019/12/project-loom.html Their arguments are compelling: - Works with existing debuggers and debugging techniques. - Stack traces aren't polluted with irrelevant garbage. - Doesn't create method ap…

- Cannot interop with other languages/VMs that do async differently.

The nice thing about promise-based async is that it's very easy to map to straight C ABI callbacks, which means that it can be fully cross-language. Green threads are runtime-specific.

Post reply on HN