Hacker News Reader

Comment by tester34 | Hacker News Reader

http://joeduffyblog.com/2015/11/19/asynchronous-everything/

>We were able to share this experience with .NET in time for C#’s await to ship. Sadly, by then, .NET’s Task had already been made a class. Since .NET requires async method return types to be Tasks, they cannot be zero-allocation unless you go out of your way to use clumsy patterns like caching singleton Task objects.

View on HN

.NET Core and later has ValueTask for that usecase.

but shouldnt it be that ValueTask is used everywhere by default and class "exists for some usecase"?

It kind of depends. Class is safer because you can have multiple calls to await and the TPL was designed to be mostly as safe as possible by default....but yeah, it does hurt that its not alloc free.

Should: yes. Can: no. Why: backward compatibility

If you know that an operation will not complete sychronously (e.g. because it requires a network transaction) then normal Task might actually be more efficient, because the heap allocation would be required anyway and you safe the additional branches.

Around 50% of my work .NET coding and I find It's becoming really hard to keep up with this. .NET more and more feels to me like the typical MS approach where they just keep cranking out new stuff without cleaning up existing stuff. Some of the new things are very good, some are half baked, and it's difficult to figure out on what side these new features are.

Just lately I did some Entity Framework coding and noticed that some things are async compatible, but others aren't, so you end up doing a lot of strategizing coding around these omissions and creating questionable workarounds.

I really wish they would go back to the drawing board and simplify things. Same could be said for their various XAML dialects. It's just too damn verbose.

The problem is that .NET has been taken over by web developers, and they expect the kind of breakneck pace of change and half-baked tools that the Javascript ecosystem has become accustomed to.

This is so true. .NET has been steadily going downhill for some time now. The best indicator is the absolutely rotten documentation for the more recent .NET stuff. Compare that to the older .NET Framework and/or Winapi documentation which was excellent.

It is fighting in a space which is very competitive. Java, Go, JavaScript and Python. The later two are being favorite of every university or coding camp graduate. You stay relevant or you die.

Unfortunately, that implies faster dev cycles and areas like docs which are not well served.

How is .NET fighting against JavaScript or Python? Java or Go, I can understand but not JavaScript or Python.

Serverless computing is dominated by node, go, and python. .NET just doesn't startup fast enough.

Good point, I didn't think about that.

.NET is competing against any language which is not exactly driver level (like c/c++/rust). Every other app model they compete. Even OS Scripting they cover with PowerShell (which is not c# but it is .NET).

You're right, I tend to think .NET == C# but it's a whole ecosystem. We have some Powershell at work and it's a nice DSL for scripting. The languages we use outside of .NET are C++ (like you said), JS/TS (I doubt Blazor will replace all usage of JS, and we have a big codebase anyways), and Python for some machine learning stuff.

Agreed about documentation. They produce a lot of it but it’s hard to use and doesn’t really give you the big picture. I know I am old but in the 90s and 2000s the MSDN documentation was fantastic. Sad to see it going downhill that much.

I agree the docs are getting half-baked, they lack context and guidance.

FWIW, github issues for all things .net have been a surprisingly good resource. Especially on the hot new things, microsoft folks are very responsive and helpful. I dare say it's better for many topics than stackoverflow.

ValueTask is also available in Framework via System.Threading.Tasks.Extensions NuGET package.

Reply on news.ycombinator.com