5 ms·

> Knowing ahead of time which functions are async is a feature. "Expensive" is subjective and should be up to the programmer to decide. And, it absolutely sho

> Knowing ahead of time which functions are async is a feature. "Expensive" is subjective and should be up to the programmer to decide. And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. > This is a good thing for programmers to easily see and know at the call site. Yes, and the IDE can show you that information, exactly like it does the types of arguments. We don't redundantly write the types of arguments at the call site because it's a good thing for programmers to see (which it is), we let the IDE do that.

mattigames 2y ago
Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us, why have underscore at the beginning of private variables? We can let the IDE do that, we even have long named functions instead of single letter ones? Most IDEs can read the jsdocs and give us a long description of what every function does, and I could go on and on. At the end it's a balance and subjective preferences of what you want to be immediately visible or something a bit more obscure (e.g. when you move your mouse over a variable)
- throw10920 2y ago
  > Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us Yes, this is a great idea, and people would do it if there was widespread support for a binary structured format. The difference between this incredibly ignorant sarcasm and my point is that IDEs already support the thing that I'm suggesting. You can already hover over a method and it'll give you information about the types of the arguments and return values that are specific to the call site. > At the end it's a balance and subjective preferences ...and you completely missed the main point of my comment, which was not about what information to show, but avoiding duplication due to function coloring: > And, it absolutely should not require creating two identical function definitions to get around the function coloring problem
CGamesPlay 2y ago
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. I'm afraid I don't follow. It's impossible for you to have two identical functions (one sync and one async), since then they would both be sync. What did you mean?
- throw10920 2y ago
  Two functions that are identical up to one of them being async and using "await" to call another function foo_async, and the other that is sync and calling foo_sync (a synchronous version of foo_async) without await?
  - CGamesPlay 2y ago
    I think the only place that happens is in programming languages where you actually can choose to do something using a thread-blocking operation? Specifically, I've only seen it in Python. And yeah, it's not very ideal there. In other languages, it's typically only possible to do the operation in async mode, so you never write a foo_sync function in the first place.
    - throw10920 2y ago
      The "it's typically only possible to do the operation in async mode" is part of the problem. If I'm writing a a batch script that parses a file as part of its operation, I don't want or need the read_file() function to be async! My code should just block until the file opens. Alternately, I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. The main problem is that someone got it in their head that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site.
      - spankalee 2y ago
        > The main problem is that someone got it in their head This unnecessarily trivializes the technical problems at hand. This wasn't just something someone got in their head, especially considering... > that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site. This is exactly what JavaScript did. The program only yields at `await`ed callsites and doesn't yield at all other callsites. `async` only tells the VM to create the state machine necessary to resume the function after `awaited` calls return.
lmm 2y ago
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Oh yes, absolutely. But the solution to that is stop using joke languages that can't do kind polymorphism. > Yes, and the IDE can show you that information, exactly like it does the types of arguments. How can it, if the language doesn't give it that information? Either you have a language that can reliably distinguish between sync and async calls in a standard way - which is to say, it has a type system that distinguishes between sync and async, whether it calls it that or not - or your IDE has an ad-hoc informally specified bug-ridden slow implementation of half of one.
- pjmlp 2y ago
  Good luck with that, when we keep using glue languages for full blown applications, and then shelling out to C extensions, instead of ones that could do the job all by themselves.
spankalee 2y ago
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. This is very rarely necessary in app code. It's usually only a pattern for higher-level utility functions, and even then if you really wanted to you could unify implementations with generators.
wiseowise 2y ago
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Where do you see insanity like this?
- vips7L 2y ago
  Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().
  - lolinder 2y ago
    That sounds more like a legacy problem than a problem with the async/await model in the abstract. If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.
    - vips7L 2y ago
      There’s lot of programming models that don’t require async or it’s complexity. Not everything is a web server that needs to serve 100k requests.
  - neonsunset 2y ago
    Because Read and ReadAsync are usually meaningfully different. There is nothing wrong with that. See https://news.ycombinator.com/item?id=41055328 https://news.ycombinator.com/item?id=41055328 This bifurcation is mostly a concern for the standard library. It’s not something you do this way in your regular application code.
- dragonwriter 2y ago
  Everywhere that hard function coloring exists where the language also supports synchronous calls that do the same thing (JS doesn't support sunchronous calls for lots of things and has only soft function coloring since async is sugar for Promises, so it has two reasons why that doesn't need to happen.)

mattigames 2y ago

Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us, why have underscore at the beginning of private variables? We can let the IDE do that, we even have long named functions instead of single letter ones? Most IDEs can read the jsdocs and give us a long description of what every function does, and I could go on and on. At the end it's a balance and subjective preferences of what you want to be immediately visible or something a bit more obscure (e.g. when you move your mouse over a variable)

throw10920 2y ago
> Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us Yes, this is a great idea, and people would do it if there was widespread support for a binary structured format. The difference between this incredibly ignorant sarcasm and my point is that IDEs already support the thing that I'm suggesting. You can already hover over a method and it'll give you information about the types of the arguments and return values that are specific to the call site. > At the end it's a balance and subjective preferences ...and you completely missed the main point of my comment, which was not about what information to show, but avoiding duplication due to function coloring: > And, it absolutely should not require creating two identical function definitions to get around the function coloring problem

CGamesPlay 2y ago

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. I'm afraid I don't follow. It's impossible for you to have two identical functions (one sync and one async), since then they would both be sync. What did you mean?

throw10920 2y ago
Two functions that are identical up to one of them being async and using "await" to call another function foo_async, and the other that is sync and calling foo_sync (a synchronous version of foo_async) without await?
- CGamesPlay 2y ago
  I think the only place that happens is in programming languages where you actually can choose to do something using a thread-blocking operation? Specifically, I've only seen it in Python. And yeah, it's not very ideal there. In other languages, it's typically only possible to do the operation in async mode, so you never write a foo_sync function in the first place.
  - throw10920 2y ago
    The "it's typically only possible to do the operation in async mode" is part of the problem. If I'm writing a a batch script that parses a file as part of its operation, I don't want or need the read_file() function to be async! My code should just block until the file opens. Alternately, I want to be able to designate a computationally-intense function call (just that call, leaving the other calls alone) as async so that control yields to the event loop. The main problem is that someone got it in their head that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site.
    - spankalee 2y ago
      > The main problem is that someone got it in their head This unnecessarily trivializes the technical problems at hand. This wasn't just something someone got in their head, especially considering... > that the function definition was the right place to designate whether a function was async or not, and it's not. The right place is the call site. This is exactly what JavaScript did. The program only yields at `await`ed callsites and doesn't yield at all other callsites. `async` only tells the VM to create the state machine necessary to resume the function after `awaited` calls return.

lmm 2y ago

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Oh yes, absolutely. But the solution to that is stop using joke languages that can't do kind polymorphism. > Yes, and the IDE can show you that information, exactly like it does the types of arguments. How can it, if the language doesn't give it that information? Either you have a language that can reliably distinguish between sync and async calls in a standard way - which is to say, it has a type system that distinguishes between sync and async, whether it calls it that or not - or your IDE has an ad-hoc informally specified bug-ridden slow implementation of half of one.

pjmlp 2y ago
Good luck with that, when we keep using glue languages for full blown applications, and then shelling out to C extensions, instead of ones that could do the job all by themselves.

spankalee 2y ago

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. This is very rarely necessary in app code. It's usually only a pattern for higher-level utility functions, and even then if you really wanted to you could unify implementations with generators.

wiseowise 2y ago

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Where do you see insanity like this?

vips7L 2y ago
Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().
- lolinder 2y ago
  That sounds more like a legacy problem than a problem with the async/await model in the abstract. If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.
  - vips7L 2y ago
    There’s lot of programming models that don’t require async or it’s complexity. Not everything is a web server that needs to serve 100k requests.
- neonsunset 2y ago
  Because Read and ReadAsync are usually meaningfully different. There is nothing wrong with that. See https://news.ycombinator.com/item?id=41055328 https://news.ycombinator.com/item?id=41055328 This bifurcation is mostly a concern for the standard library. It’s not something you do this way in your regular application code.
dragonwriter 2y ago
Everywhere that hard function coloring exists where the language also supports synchronous calls that do the same thing (JS doesn't support sunchronous calls for lots of things and has only soft function coloring since async is sugar for Promises, so it has two reasons why that doesn't need to happen.)