hirrolot

Rust do still has exceptions, they're just called "results". You can't really have values as exceptions unless you plug a lot of ad-hoc constructs into your language so that they eventually become similar to exceptions [1]:

Add syntactic sugar for working with the Result type which models common exception handling constructs.

The whole error handling story with Rust can be summarized as "we have results but want to have exceptions".

[1] https://rust-lang.github.io/rfcs/0243-trait-based-exception-...

Certainly any language that differentiates between async code and non-async code has the async code be a pain.

Function colouring is not the only problem with async code. The difference is that concurrency in other high-level languages usually don't break down polymorphism and other language features. Also, they don't push you to deal with lifetimes, which is a serious issue in Rusty async.

Writing async code in C# is a lot easier to me than in Rust. Unfortunately, I didn't have a chance to write async in functional languages, such as Haskell or F#, because they are well-known for elegant concurrency.

without touching async

The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all.

However, when you write networking code, you typically use async. The worst role is being an async library author (me).