Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@AvatarOfKaine I think it's a useful simplification. It makes lexical scoping work in a sensible way with sorta-but-not-quite monadic Promises
-
@lorentz it's the necessity to wrap await in async all the time
-
@AvatarOfKaine That serves to indicate in the function head that this isn't a real function, and you need to read the body carefully because the associated stack frame may spontaneously be moved to the heap on any line.
By the way, Rust has an interesting approach;
- await can apply to blocks, not just functions
- blocks in Rust have a value. Await blocks wrap their value in a Future.
- if your function is async, you use the eventual return type as the return type. If the function isn't async but just contains an async block, you have to wrap the return type in Future. Async functions always return a future anyways so explicitly specifying it just hurts readability. -
@lorentz all I'm saying is if the internals fuck up like you say in said gibberish in java SCRIPT because every function calling AWAIT has to be marked ASYNC it's a shitty implementation
What if I want a synchronous function that awaits an async function to force it to be synchronous with the calling thread ?
Yes you can redesign code but why have to deal with that paradigm shift when you can use the one people commonly use ? -
@lorentz btw what you just described is an anonymous function
-
@AvatarOfKaine In JS there's only one thread, and the only way promises can resolve is through events dispatched on that one thread. If you want a part of your function to execute after a promise has resolved, you will by logical necessity need to make your function async because you need to relinquish control in order for whatever code resolves the promise to ever acquire it. That's why you can only await in an async function.
-
@AvatarOfKaine I didn't realize that this can be represented as an IIFE, but I'm not surprised; Rust's expression-based syntax can be emulated in most languages, you just need extra unnecessary round trips.
-
I finally got it working! Now I have a foundation for a kernel and an uefi bootloader written in pure Rust
To...
It's nice that more and more languages are introducing async/await syntax, but by the example of Rust in particular I'm starting to wonder why we don't instead introduce this syntax for monads in general?
We could have a keyword (say, `bind`) which unwraps a value from any monad provided that the return value of the function is wrapped in the same monad. The ? operator does something a little similar, and I'll be intrigued whether it can actually be implemented for monads other than Result and Option once GATs are stabilized. In particular in the case of Rust, it would be possible to create a reference counting monad for heap-bound management of objects derived from references.
rant
await
rust
monads