6 ms·

TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that it

TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewrite our emit pipeline, which meant that we needed to keep parity in both output as well as time to emit. The investment has shown, and TypeScript is still extremely fast. We're always willing to think about different approaches, but those are some of the rationales here.

vyrotek 10y ago
As a long-time .NET dev... Thank You for Async/Await in TypeScript.
- mattmanser 10y ago
  async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bottle neck, async/await to the rescue! Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging. But your sewer is now even bigger! Look at how you can throw that hose around! I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds. It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it. async/await in javascript is actually useful.
  - taspeotis 10y ago
    I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. That's not unique to the task-based asynchronous pattern, but it's far fewer lines of code to write than BeginExecuteReader/EndExecuteReader etc. so my appetite for doing it is much higher. And I believe asynchronous streaming (à la DbDataReader.ReadAsync) has no non-TAP equivalent. Two steps forward, one step back. (You're right about debugging.)
    - egeozcan 10y ago
      I heard from a colleague that in VS2017, the debugging is much better for async stacks. Did anyone here try it?
    - mattmanser 10y ago
      Why is it tautological? There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself.
      - taspeotis 10y ago
        > There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download). Look at the wall clock - it's up to twice as fast. Look ma, no threads or synchronization primitives! > And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself. Blocking operations ... block. Now your thread is doing nothing while your database churns/disk writes/network packet streams. As I understand it, using async/await with the SynchronizationContext in ASP.NET will yield the thread to another request. You get more requests per thread, which mitigates the problems with thread-per-request as described here [1]. Instead it's a combination of thread-based and event-driven models. [1] http://berb.github.io/diploma-thesis/original/042_serverarch.html#scalemt http://berb.github.io/diploma-thesis/original/042_serverarch...
zdragnar 10y ago
Did you mean to reply to my comment? If so, to help clarify, I wasn't critiquing the long delay of those features; I merely was amused that they've gotten so much more attention than the far more novel features that were also released.

vyrotek 10y ago

As a long-time .NET dev... Thank You for Async/Await in TypeScript.

mattmanser 10y ago
async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bottle neck, async/await to the rescue! Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging. But your sewer is now even bigger! Look at how you can throw that hose around! I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds. It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it. async/await in javascript is actually useful.
- taspeotis 10y ago
  I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. That's not unique to the task-based asynchronous pattern, but it's far fewer lines of code to write than BeginExecuteReader/EndExecuteReader etc. so my appetite for doing it is much higher. And I believe asynchronous streaming (à la DbDataReader.ReadAsync) has no non-TAP equivalent. Two steps forward, one step back. (You're right about debugging.)
  - egeozcan 10y ago
    I heard from a colleague that in VS2017, the debugging is much better for async stacks. Did anyone here try it?
  - mattmanser 10y ago
    Why is it tautological? There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself.
    - taspeotis 10y ago
      > There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download). Look at the wall clock - it's up to twice as fast. Look ma, no threads or synchronization primitives! > And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by itself. Blocking operations ... block. Now your thread is doing nothing while your database churns/disk writes/network packet streams. As I understand it, using async/await with the SynchronizationContext in ASP.NET will yield the thread to another request. You get more requests per thread, which mitigates the problems with thread-per-request as described here [1]. Instead it's a combination of thread-based and event-driven models. [1] http://berb.github.io/diploma-thesis/original/042_serverarch.html#scalemt http://berb.github.io/diploma-thesis/original/042_serverarch...

zdragnar 10y ago

Did you mean to reply to my comment? If so, to help clarify, I wasn't critiquing the long delay of those features; I merely was amused that they've gotten so much more attention than the far more novel features that were also released.