3 ms·

That sounds like a few different languages. And I think it’s fine to want a language like Rust that allows you to be less explicit about things. Based on what I

by skavi 2y ago

That sounds like a few different languages. And I think it’s fine to want a language like Rust that allows you to be less explicit about things. Based on what I’ve heard, you might just be looking for Gleam. But I don’t think it would be the right move to make Rust something that it’s not, just so people don’t have to think about what a Future is or isn’t.

adastra22 2y ago
You never tried to await from within a synchronous function? There's stuff that you just can't do with Rust's approach to concurrency, that would be trivial if we allowed some limited cost abstractions (e.g. thunking the future in this case). Or just make all functions asynchronous but eliminate the state machine if it contains no yields. The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff. Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that.
- skavi 2y ago
  > You never tried to await from within a synchronous function? Whenever necessary I have been able to do this easily. Calling async code from a synchronous context is not an example of something which can’t be done in Rust today. > Or just make all functions asynchronous but eliminate the state machine if it contains no yields. The optimizer generally already cleans this up. > The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff. The borrow checker is not “limited cost”. It is zero cost. > Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that. There is no zero cost way of doing this.
  - gmueckl 2y ago
    The borrow checker is not "zero cost". That is a myth. It forces the use of non-zero overhead escape hatches (RefCell/Rc) almost every time when the code tries to do something nontrivial, that is, something actually worth doing.
    - skavi 2y ago
      The guarantees given to you by the borrow checker are zero cost. Once you’ve exceeded its capabilities, you have the choice to either pay a runtime cost (use RefCell and friends) or deal with maintaining and validating unsafe code.

by skavi 2y ago

adastra22 2y ago

You never tried to await from within a synchronous function? There's stuff that you just can't do with Rust's approach to concurrency, that would be trivial if we allowed some limited cost abstractions (e.g. thunking the future in this case). Or just make all functions asynchronous but eliminate the state machine if it contains no yields. The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff. Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that.

skavi 2y ago
> You never tried to await from within a synchronous function? Whenever necessary I have been able to do this easily. Calling async code from a synchronous context is not an example of something which can’t be done in Rust today. > Or just make all functions asynchronous but eliminate the state machine if it contains no yields. The optimizer generally already cleans this up. > The whole point of higher level abstractions is making it so that developers don't have to think about stuff. It's what I love about Rust: with the borrow checker, I know that if it compiles then I am not going to be accessing mutable or already freed state. The language and the compiler get more complicated so that I don't have to think about stuff. The borrow checker is not “limited cost”. It is zero cost. > Rust didn't go that way with concurrency. They instead opted to push that complexity (thinking about what a Future is or isn't) onto the developer. YOU have to think about "should this API call be async?" instead of letting the downstream user decide that. There is no zero cost way of doing this.
- gmueckl 2y ago
  The borrow checker is not "zero cost". That is a myth. It forces the use of non-zero overhead escape hatches (RefCell/Rc) almost every time when the code tries to do something nontrivial, that is, something actually worth doing.
  - skavi 2y ago
    The guarantees given to you by the borrow checker are zero cost. Once you’ve exceeded its capabilities, you have the choice to either pay a runtime cost (use RefCell and friends) or deal with maintaining and validating unsafe code.