4 ms·

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify whe

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior within a request because it's easier to read, write, understand, and reason about and concurrent progress across requests. The places where I can overlap I/O within a request can be manually specified. I guess this is kind of how Go works (although that's parallelism and concurrency).

deleted 4y ago
[deleted]
davidmurdoch 4y ago
I like this idea!
chmod775 4y ago
You might be interested in these linter rules: https://typescript-eslint.io/rules/no-misused-promises/ https://typescript-eslint.io/rules/no-misused-promises/ https://typescript-eslint.io/rules/no-floating-promises/ https://typescript-eslint.io/rules/no-floating-promises/ They can catch some common mistakes. Of course these checks can only work reliably when you're using a typed language. I'm still looking for one that forces me to put an await in front of every function call that returns a promise, unless I opt out.
audunw 4y ago
You may want to check out Zig's async/await. Seems to be closer to what you're suggesting. It's one of the few implementations where functions don't have an "async"/"no-async" color, and where you use the same IO functions regardless of whether you want to use them asynchronously or synchronously (if I remember correctly).
oaiey 4y ago
I actually start to appreciate function coloring in C# to never forget that I am operating on asynchronous code. In .NET the compiler also throws warnings if you do not await or pickup the task/promise. I also believe that you should see where asynchronous behavior can happen in your code. So from that angle i also appreciate the keyword and the coloring. Hidden resource access is pure evil.
trog 4y ago
Heh I suggested this once on HN and got modded down to hell. I completely agree. I think any performance advantages of the async model are lost because it adds so much complexity to just reading and following code. The amount of effort JS programmers have to go to in order to write synchronous code that is legible, works and easy to understand is enormous. I am a Bad Programmer so accept that some of it is just my lack of willingness to spend the time to get over that hump but I find it almost impossible to believe the gains are worth the costs.
zorr 4y ago
Kotlin coroutines do something like this. Any calls to a suspend function from inside another suspend function will be a suspension point and does not need additional syntax. And typically, if you are writing Kotlin using a JetBrains IDE the IDE will have a little indicator in the gutter to show all the suspend function calls. To me personally it is much more readable with the gutter indicators instead of additional await keywords inside the actual code but it has a drawback: you need an IDE that supports it. When reviewing code on gitlab/github there won't be any indicator.

deleted 4y ago

[deleted]

davidmurdoch 4y ago

I like this idea!

chmod775 4y ago

You might be interested in these linter rules: https://typescript-eslint.io/rules/no-misused-promises/ https://typescript-eslint.io/rules/no-misused-promises/ https://typescript-eslint.io/rules/no-floating-promises/ https://typescript-eslint.io/rules/no-floating-promises/ They can catch some common mistakes. Of course these checks can only work reliably when you're using a typed language. I'm still looking for one that forces me to put an await in front of every function call that returns a promise, unless I opt out.

audunw 4y ago

You may want to check out Zig's async/await. Seems to be closer to what you're suggesting. It's one of the few implementations where functions don't have an "async"/"no-async" color, and where you use the same IO functions regardless of whether you want to use them asynchronously or synchronously (if I remember correctly).

oaiey 4y ago

I actually start to appreciate function coloring in C# to never forget that I am operating on asynchronous code. In .NET the compiler also throws warnings if you do not await or pickup the task/promise. I also believe that you should see where asynchronous behavior can happen in your code. So from that angle i also appreciate the keyword and the coloring. Hidden resource access is pure evil.

trog 4y ago

Heh I suggested this once on HN and got modded down to hell. I completely agree. I think any performance advantages of the async model are lost because it adds so much complexity to just reading and following code. The amount of effort JS programmers have to go to in order to write synchronous code that is legible, works and easy to understand is enormous. I am a Bad Programmer so accept that some of it is just my lack of willingness to spend the time to get over that hump but I find it almost impossible to believe the gains are worth the costs.

zorr 4y ago

Kotlin coroutines do something like this. Any calls to a suspend function from inside another suspend function will be a suspension point and does not need additional syntax. And typically, if you are writing Kotlin using a JetBrains IDE the IDE will have a little indicator in the gutter to show all the suspend function calls. To me personally it is much more readable with the gutter indicators instead of additional await keywords inside the actual code but it has a drawback: you need an IDE that supports it. When reviewing code on gitlab/github there won't be any indicator.