Joseph N. Musser IIJoseph N. Musser II

My feedback

  1. 148 votes
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)

      We’ll send you updates on this idea

      6 comments  ·  Visual Studio Team Services » CI (Build)  ·  Flag idea as inappropriate…  ·  Admin →
      Joseph N. Musser IIJoseph N. Musser II supported this idea  · 
    • 209 votes
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)

        We’ll send you updates on this idea

        Joseph N. Musser IIJoseph N. Musser II supported this idea  · 
        Joseph N. Musser IIJoseph N. Musser II commented  · 

        This is critical because of the ultimatum that switching to VSTS becomes. We need to know there is a way out back to on-prem, even if we never use it.

        Git repository backups are much less important than project setup, work items, builds and anything else needed to continue if, say, we switched back to on-prem.

      • 6 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          2 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
          Joseph N. Musser IIJoseph N. Musser II commented  · 

          Apparently the search terms become the title, and there is no way to edit the title once posted. Apologies for the lowercase.

          Joseph N. Musser IIJoseph N. Musser II shared this idea  · 
        • 60 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            1 comment  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
            Joseph N. Musser IIJoseph N. Musser II supported this idea  · 
          • 113 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              I agree to the terms of service
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              24 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
              Joseph N. Musser IIJoseph N. Musser II commented  · 

              For one thing, I don't think it really is an infestation. I've been in a good variety of codebases that use it and it has rarely been laborious. But I know what you're referring to, so let's just go with that. How would you remove it? You would have to go either 100% sync or 100% async or invent a way that the same code could run both ways. You can't run synchronous methods asynchronously without losing all benefits of async and you can't run asynchronous methods synchronously without losing all benefits of sync.

              Each scenario is specialized. Say you're reading from I/O. If the code runs synchronously, you make the system call to read. If it runs asynchronously, you make a system call to be notified when the system is done reading and then call back to a thread pool thread or to a UI message pump. Those two are nothing like each other but each has distinct benefits that we need to keep around. You have to keep two distinct methods around for this because sometimes you need one and sometimes the other. Does that make sense?

              Async is inherently expensive just because it's the ideal solution to an inherently expensive problem. You want to make it very clear when you are and aren't using it. Moving to a world where it's all the same method and same return type for extremely different processes would be frustrating.

              Joseph N. Musser IIJoseph N. Musser II commented  · 

              I'm not really sure this is actionable or even desirable. The "zombie" infection and having *Async versions of methods and async void are actually the *ideal* outcome as far as I can tell. There is no helpful way to generalize async and non-async code that I have been able to find. Without async void, how would you be able to write async event handlers in any practical way? I could go on.

              Unless you have some ground-breaking theory proposals to point to, it sounds like you're mostly complaining about the fundamental nature of async programming rather than complaining about C#'s solution in particular. C#'s async/await is quite the state of the art right now when it comes to solving the callback **** problem, so perfectly executed that other languages are copying it.

              On the cutting edge there are exciting improvements like custom builders for custom Task-like types, but for the most part the dichotomy between synchronous and asynchronous (callback-driven) code is a practical and useful one. Certainly, I may stand corrected on this and that would be exciting, but we'll need to be pointed to some heavy-duty research rather than complaints. No offense!

            Feedback and Knowledge Base