2 ms·

> if you don't need the result of the promise in the caller function you don't need to await and to make it a async function Why call it at all, then? In Rust,

> if you don't need the result of the promise in the caller function you don't need to await and to make it a async function Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stack

littlestymaar 2y ago
> Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. Rust is a bit special as the futures are lazy and you need to call your future with `task::spawn` if you want this to work, but it still does. And in other languages it's going to work directly without doing anything in addition to calling the async function. > In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stackm It really is use-case dependent but I don't think it's more common than letting the request run in the background without waiting for its result. In fact your log example is a funny one because as soon as you use remote logging you're going to let the request run in the background and never await it (otherwise you'd get tons of gratuitous latency).