On: Maybe Rust isn’t a good tool for massively concurr...

[brigadier132]

> Without function coloring there's no distinction that you need to know of

Why do you think you don't need to know of it? I want to know if the function I'm calling is going to make a network request. Just because I can have a programming language that hides that distinction from me doesn't mean I want that.

Ideally I want to have the fundamental behavior of any function I call encoded in the function signature. So if it's async, I know it's going to reach out to some external system for some period of time.

[dgb23 → brigadier132]

> I want to know if the function I'm calling is going to make a network request.

That has nothing to do with function coloring.

> Ideally I want to have the fundamental behavior of any function I call encoded in the function signature.

There is no distinction of async functions if you don't have function coloring that you can encode in type signatures.

[brigadier132 → dgb23]

> That has nothing to do with function coloring.

Sure, in the same way that types have nothing to do with enforcing logical correctness of software.

> There is no distinction of async functions if you don't have function coloring that you can encode in type signatures.

What are you trying to say with this statement?

[kprotty → brigadier132]

getaddrinfo() is a synchronous function that can do network requests to resolve DNS. The network property isn't reflected in its function signature becoming async. You can have an async_getaddrinfo() which does, but the former is just a practical example of network calls in particular being unrelated to function coloring.