4 ms·

http://joeduffyblog.com/2015/11/19/asynchronous-everything/ http://joeduffyblog.com/2015/11/19/asynchronous-everything/ >We were able to share this experience

http://joeduffyblog.com/2015/11/19/asynchronous-everything/ 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.

kryptiskt 5y ago
.NET Core and later has ValueTask for that usecase.
- tester34 5y ago
  but shouldnt it be that ValueTask is used everywhere by default and class "exists for some usecase"?
  - jayd16 5y ago
    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.
  - oaiey 5y ago
    Should: yes. Can: no. Why: backward compatibility
  - Matthias247 5y ago
    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.
- spaetzleesser 5y ago
  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.
  - thrower123 5y ago
    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.
    - datenarsch 5y ago
      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.
      - oaiey 5y ago
        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.
        Zababa 5y ago
        How is .NET fighting against JavaScript or Python? Java or Go, I can understand but not JavaScript or Python.
- pjmlp 5y ago
  ValueTask is also available in Framework via System.Threading.Tasks.Extensions NuGET package.

kryptiskt 5y ago

.NET Core and later has ValueTask for that usecase.

tester34 5y ago
but shouldnt it be that ValueTask is used everywhere by default and class "exists for some usecase"?
- jayd16 5y ago
  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.
- oaiey 5y ago
  Should: yes. Can: no. Why: backward compatibility
- Matthias247 5y ago
  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.
spaetzleesser 5y ago
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.
- thrower123 5y ago
  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.
  - datenarsch 5y ago
    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.
    - oaiey 5y ago
      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.
      - Zababa 5y ago
        How is .NET fighting against JavaScript or Python? Java or Go, I can understand but not JavaScript or Python.
pjmlp 5y ago
ValueTask is also available in Framework via System.Threading.Tasks.Extensions NuGET package.