This is mostly focused on the user-facing API. Less so for the implementers. E.g. needing to remember the difference between `.read()`, and `.poll_read()` is not great. Node worked around this by providing `.read()` and `.readSync()`, which is similar.
-
Show this thread
-
I recently watched a C++ talk where they briefly mentioned* having "multiple methods sharing the same name, but having different signatures", and from in a way that would be fantastic! `read()` and `async read()` could then just work! * note: They felt negatively about it tho.
3 replies 0 retweets 2 likesShow this thread -
I think the main point I'm trying to make here is: I wish the distance to switch between sync and async rust would be smaller. Instead of requiring both a keyword, and a method name change, it'd be nice if only the keyword was needed. Fewer things to remember.
1 reply 0 retweets 3 likesShow this thread -
Replying to @yoshuawuyts
not sure how you would cleanly overload between sync and async: both sync and async functions can be used in sync and async contexts so if tere's no await you won't know which one to pick
2 replies 0 retweets 1 like -
Replying to @ManishEarth
Intuitively I was thinking the async keyword could be the differentiating factor. But maybe that's naive?
2 replies 0 retweets 0 likes -
-
Replying to @yoshuawuyts
right! you don't have to use await, there's a use case for directly calling them as well
1 reply 0 retweets 0 likes -
Replying to @ManishEarth
Oh yeah, good point! That would def complicate things more. But still think it's useful to think about! Rust seems to use type annotations/ascription in case of ambiguity. I wonder if something similar could be applied here as well.
1 reply 0 retweets 1 like -
-
Replying to @ManishEarth
Could you elaborate? I think my underlying assumption here is that using async code without the async keyword will be quite uncommon eventually. But maybe that's wrong? Also trying to consider compat for new async traits with existing core traits, not prioritizing either.
1 reply 0 retweets 0 likes
Actually, reading this back. I think my main issue is that sync IO code seems easier to write than async alternatives. Mostly because std blessed it. Maybe its something that can be solved at the stdlib level (eventually), than at the language level. Ah well.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.