←back to thread

452 points birdculture | 1 comments | | HN request time: 0.206s | source
Show context
Havoc ◴[] No.43979116[source]
I thought it was quite manageable at beginner level…though I haven’t dived into async which I gather is a whole different level of pain
replies(1): >>43979133 #
echelon ◴[] No.43979133[source]
Async and the "function color" "problem" fall away if your entire app is in an async runtime.

Almost 90% of the Rust I write these days is async. I avoid non-async / blocking libraries where possible.

I think this whole issue is overblown.

replies(6): >>43979257 #>>43979273 #>>43979433 #>>43979524 #>>43981881 #>>43986031 #
lucasyvas ◴[] No.43979524[source]
It’s completely overblown. Almost every language with async has the same “problem”.

I’m not calling this the pinnacle of async design, but it’s extremely familiar and is pretty good now. I also prefer to write as much async as possible.

replies(1): >>43979663 #
echelon ◴[] No.43979663[source]
The "function color is a problem" people invented a construct that amplifies the seriousness. It's not really a big deal.
replies(1): >>43983621 #
Measter ◴[] No.43983621[source]
My biggest issue with the whole "function colour" thing is that many functions have different colours. Like, these two:

    fn foo() -> String
    fn bar() -> Result<String, Error>
I can't just treat `bar` the same as `foo` because it doesn't give me a String, it might have failed to give me a String. So I need to give it special handling to get a String.

    async fn qux() -> String
This also doesn't give me a String. It gives me a thing that can give me a String (an `impl Future<Output=String>`, to be more specific), and I need to give it special handling to get a String.

All of these function have different colours, and I don't really see why it's suddenly a big issue for `qux` when it wasn't for `bar`.

replies(1): >>43984091 #
1. echelon ◴[] No.43984091[source]
Excellent retort!