Have you ever seen that video where an otter muck-sprays the water and all the fishes go crazy eating it?

Statements like “async is a language design dead-end” is the confidently correct misinfo that I’m talking about. You can’t expect anyone to take you seriously if you authoritatively present your opinions as gospel.

Should I instead have interpreted it as “async is a language design dead-end, and by dead-end I mean overfitted standard for the problem space?” Because I really have to be charitable and put words in your mouth to paint your argument in a good light.

Jfc that’s a bit of a stretch. You basically just said “you are wrong to use those features, and if you don’t use those features then my solution is great”. Like yeah, no shit, if I wanted a toy language I’d go back to using Logo.

“no visibility modifier” should probably mean “public”

For-fucking-real?

instead put different targets into different folders: much easier, works better

Ahh, yes, file-based programming, the most usable and ergonomic pattern for cross-cutting concerns. /s

async should not exist at all

The most I’ll give you there is that it’s used more frequently than it should. But it is far and away the best abstraction for bare-metal concurrency without a runtime. Your “dead end” comment reeks of writing off an entire language feature because you don’t understand it or why it solves problems no other language feature solves as well.

Normally I’m open to discussing the merits and comparing drawbacks to certain approaches, but of course I’m going to be cross if you dump a bunch of confident horseshit on me. Like, wtf man??

Hmm, I mean I totally understand the overlap in functionality. Especially when you get into the Java Lombok situation where annotations are as structural as the modifiers themselves. But there are clear cases in things like Python and Rust where the modifiers are a clear meta-programming that are mostly outside the scope of the language itself.

Granted, Rust is a weird example where annotations tend to “graduate” to the language itself, like in the form of #[async], but that clear delineation of what’s in the language itself and what’s defined as post-processing still leaves it more readable than if we heaped a chunk of similar-looking-but-willdy-different-effect-wise tokens on top of our function/type definition. E.g.,

#[cfg(target_os = "windows")]
#[pub] #[async] fn some_func() {
    #[mut] let my_var = 3u2;
    // ...

Vs.

#[cfg(target_os = "windows")]
pub async fn some_func() {
    let mut my_var = 3u2;
    // ...

Like, I do get the similarity in function, but it’s almost like why we have capitalization in our natural languages. Making language-defined features “louder” and more ingrained in the language itself makes sense, even if the border is fuzzy.

Edit: even going the other direction, and we do:

pub cfg(target_os = "windows") async fn some_func() {
    let mut my_var = 3u2;
    // ...

That homogenization is still a bit of a bitch to read