6 ms·

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 pul

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?

mmis1000 6y ago
For simplicity? Just like how js get async await thing eventually.
- withinboredom 6y ago
  So you want to pause the thread and keep it from processing other requests for simplicity?
  - mmis1000 6y ago
    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)
    - virgilp 6y ago
      .NET is meant for stuff like microservices; you don't see lots of those written in php, right? Also, for high-traffic websites, that's really not a great idea. You might say "but Facebook, PHP" - I'm really certain that their current codebase doesn't have a thread that blocks on DB for each user request.
      - BoorishBears 6y ago
        I don't get why the auth being async is a hang up but at the same time, most projects can handle not scaling to Facebook-scale and the sooner developers accept that, the sooner we can escape a great gnashing of teeth. I'd be willing to bet more projects have been killed by trying to architecture for performance up front than have been killed by being too successful for their own good and keeling over. If Twitter could make it past the Fail Whale days, I think most of us can too.
        virgilp 6y ago
        I'd agree if you talk about "most projects". But here we're talking about a platform - you can't fault Microsoft for caring about performance! .NET is absolutely not meant only for small sites, my current employer is heavily invested in .NET and we'd probably be dead (performance-wise) without async. Definitely couldn't run our services with PHP (not without Facebook-like investments), we already outgrew that kind of traffic.
      - zerkten 6y ago
        > .NET is meant for stuff like microservices; What does this mean? .NET has been around before SOA was a term and microservices is an evolution of that. The concepts are orthogonal and you could write microservices in PHP, if you really wanted. Like Java, the .NET runtime and platform is highly efficient. That's what .NET has historically had over PHP/Python/Ruby, but I don't keep up with the PHP and Ruby platforms these days. I feel like this is another one of those discussions like the "Python GIL problem." Whether it's a really a problem depends on the circumstances, and the circumstances were it is a problem affects fewer people than the HN threads suggest.
        int_19h 6y ago
        I'm not sure where SOA as a specific term showed up, but the very first release of .NET very much emphasized web services in the docs, presentations etc. Back then, this meant SOAP.
    - jhomedall 6y ago
      That's just standard threading, not async/await.
    - oaiey 6y ago
      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
  - CodesInChaos 6y ago
    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 also mess up your stacktraces, which makes debugging production issues harder.
    - manigandham 6y ago
      .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.
    - nullsense 6y ago
      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.
- buraktamturk 6y ago
  async/await is the first class citizen .NET and C#. You just mark your function as async and return Task<OriginalReturnValue> and you can call any async function with await, just like js.
  - hackerfromthefu 6y ago
    That's a factual definition of how to use the first step of async, however it's missing the point. Async makes your code do significantly more complex thnigs, and while the compiler makes the easy stuff easy, the underlaying complexity hasn't gone away it's just been abstracted, and somewhat leakily. You can't do 'just' what you said, you also have to deal with of boundary conditions that don't exist in non-async code, plus if you want to understand what your code is doing you now need to keep two mental models of program execution in your mind. For an introduction to the complexity of async, and practical considerations you need to manage to use it well this official documentation is a place to start - and note the article is pretty long, async does have a lot of additional complexity. https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/october/asynchronous-programming-async-performance-understanding-the-costs-of-async-and-await https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/... Btw I'm not saying don't use Async. Async is an incredibly powerful and valuable tool. But it has costs and those are weighted toward downstream in the software lifecycle and you should be aware of them when deciding which situations that tool is appropriate in. Yes async is a first class citizen in .NET and thats emphasised by the framework libraries using it everywhere. But they are writing a framework to be consumed widely by users of differing requirements so they have real reasons to support the widest possible use with highest possible performance. Most application code doesn't really have those needs. Using async should be considered as a tool to reach for (when appropriate) not a default for every situation because it has significant costs through the lifecycle of the system.
- ClumsyPilot 6y ago
  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?
  - nullsense 6y ago
    >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.
  - Scarbutt 6y ago
    you then have to re-write the code if you want the application to scale. Scaling machines (VMs, containers) is a solved problem and very easy to do today.
jniedrauer 6y ago
> 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.
- asyncawaaait 6y ago
  Awaiting a storage operation (ie. look up user) in C# will allow other calls to proceed until the I/O is available to read. Synchronous code locks you into the model of handling one request per thread. Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.
  - balfirevic 6y ago
    Because async/await infects everything it touches and forces me to spread irrelevant junk words all over the code which have nothing to do with the task I'm trying to accomplish.
  - hackerfromthefu 6y ago
    What about the far worse stack traces and debugging? Whats a way to get the utility of normal debugging while using async?
    - asyncawaaait 6y ago
      Stack traces were massively improved in 2.1. Using a good IDE (Rider or Visual Studio), debugging async/await code works as expected. Are you doing interop or calling unmanaged code?
      - hackerfromthefu 6y ago
        Thanks, I will make sure to check this out. Does anyone have any articles or documentation on this?

mmis1000 6y ago

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

withinboredom 6y ago
So you want to pause the thread and keep it from processing other requests for simplicity?
- mmis1000 6y ago
  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)
  - virgilp 6y ago
    .NET is meant for stuff like microservices; you don't see lots of those written in php, right? Also, for high-traffic websites, that's really not a great idea. You might say "but Facebook, PHP" - I'm really certain that their current codebase doesn't have a thread that blocks on DB for each user request.
    - BoorishBears 6y ago
      I don't get why the auth being async is a hang up but at the same time, most projects can handle not scaling to Facebook-scale and the sooner developers accept that, the sooner we can escape a great gnashing of teeth. I'd be willing to bet more projects have been killed by trying to architecture for performance up front than have been killed by being too successful for their own good and keeling over. If Twitter could make it past the Fail Whale days, I think most of us can too.
      - virgilp 6y ago
        I'd agree if you talk about "most projects". But here we're talking about a platform - you can't fault Microsoft for caring about performance! .NET is absolutely not meant only for small sites, my current employer is heavily invested in .NET and we'd probably be dead (performance-wise) without async. Definitely couldn't run our services with PHP (not without Facebook-like investments), we already outgrew that kind of traffic.
    - zerkten 6y ago
      > .NET is meant for stuff like microservices; What does this mean? .NET has been around before SOA was a term and microservices is an evolution of that. The concepts are orthogonal and you could write microservices in PHP, if you really wanted. Like Java, the .NET runtime and platform is highly efficient. That's what .NET has historically had over PHP/Python/Ruby, but I don't keep up with the PHP and Ruby platforms these days. I feel like this is another one of those discussions like the "Python GIL problem." Whether it's a really a problem depends on the circumstances, and the circumstances were it is a problem affects fewer people than the HN threads suggest.
      - int_19h 6y ago
        I'm not sure where SOA as a specific term showed up, but the very first release of .NET very much emphasized web services in the docs, presentations etc. Back then, this meant SOAP.
  - jhomedall 6y ago
    That's just standard threading, not async/await.
  - oaiey 6y ago
    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
- CodesInChaos 6y ago
  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 also mess up your stacktraces, which makes debugging production issues harder.
  - manigandham 6y ago
    .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.
  - nullsense 6y ago
    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.
buraktamturk 6y ago
async/await is the first class citizen .NET and C#. You just mark your function as async and return Task<OriginalReturnValue> and you can call any async function with await, just like js.
- hackerfromthefu 6y ago
  That's a factual definition of how to use the first step of async, however it's missing the point. Async makes your code do significantly more complex thnigs, and while the compiler makes the easy stuff easy, the underlaying complexity hasn't gone away it's just been abstracted, and somewhat leakily. You can't do 'just' what you said, you also have to deal with of boundary conditions that don't exist in non-async code, plus if you want to understand what your code is doing you now need to keep two mental models of program execution in your mind. For an introduction to the complexity of async, and practical considerations you need to manage to use it well this official documentation is a place to start - and note the article is pretty long, async does have a lot of additional complexity. https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/october/asynchronous-programming-async-performance-understanding-the-costs-of-async-and-await https://docs.microsoft.com/en-us/archive/msdn-magazine/2011/... Btw I'm not saying don't use Async. Async is an incredibly powerful and valuable tool. But it has costs and those are weighted toward downstream in the software lifecycle and you should be aware of them when deciding which situations that tool is appropriate in. Yes async is a first class citizen in .NET and thats emphasised by the framework libraries using it everywhere. But they are writing a framework to be consumed widely by users of differing requirements so they have real reasons to support the widest possible use with highest possible performance. Most application code doesn't really have those needs. Using async should be considered as a tool to reach for (when appropriate) not a default for every situation because it has significant costs through the lifecycle of the system.
ClumsyPilot 6y ago
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?
- nullsense 6y ago
  >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.
- Scarbutt 6y ago
  you then have to re-write the code if you want the application to scale. Scaling machines (VMs, containers) is a solved problem and very easy to do today.

jniedrauer 6y ago

> 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.

asyncawaaait 6y ago
Awaiting a storage operation (ie. look up user) in C# will allow other calls to proceed until the I/O is available to read. Synchronous code locks you into the model of handling one request per thread. Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.
- balfirevic 6y ago
  Because async/await infects everything it touches and forces me to spread irrelevant junk words all over the code which have nothing to do with the task I'm trying to accomplish.
- hackerfromthefu 6y ago
  What about the far worse stack traces and debugging? Whats a way to get the utility of normal debugging while using async?
  - asyncawaaait 6y ago
    Stack traces were massively improved in 2.1. Using a good IDE (Rider or Visual Studio), debugging async/await code works as expected. Are you doing interop or calling unmanaged code?
    - hackerfromthefu 6y ago
      Thanks, I will make sure to check this out. Does anyone have any articles or documentation on this?