[insanitybit]

> The vast majority chooses a dialect of async Rust which involves arcs, mutices, boxing etc everywhere

And?

> not to mention the giant dep tree of crates to do even menial things.

Again, And?

I don't really care about having to pull in crates. That has always been how Rust does things - it prefers many small crates over fewer large crates. Async is no different.

And I don't care about Arc either. Writing `let x = blah()` is not much better than `let x = Arc::new(blah())`.

If you're talking about something else, like idk, maintaining mutability across multiple threads, yeah that's going to be more painful. It's also painful in most other languages and is generally avoided for that reason.

> The ones who try to use proper lifetimes etc are haunted by the compiler and give up after enough suffering.

You say "proper lifetimes" as if lifetimes are desirable. In async code they are not - your lifetime is often "arbitrary" and that's what an Arc gives you. The solution is, as mentioned, using an Arc or Box or Mutex.

> Async was an extremely impressive demo that got partially accepted before knowing the implications.

I think this is a totally ignorant characterization of async, which was years in the making, took lessons learned from decades of async in other languages, and was frankly led by some of the most knowledgeable people in regards to these sorts of systems.

> (If you disagree, try to explain pin projection in simple terms.)

The vast majority of people will never have to know what a pin projection is, let alone how it works. It rarely comes up, and virtually only if you're writing libraries. I could explain it but I see no reason to do so here (it is not complicated at all, `Pin` is probably the harder one to explain).

> The damage to the ecosystem from fragmentation is massive.

It's not even noticeable lol like, what? What fragmentation? I've never run into an issue of fragmentation and I've written 100s of thousands of lines of Rust.

> It would have been better to

How nice to sit on the sidelines and throw out a paragraph sized proposal. Everything looks great when you hand wave away the complexity of the problem space.

Async Rust isn't perfect (I frankly don't think there is a "perfect" solution, that should not be contentious I hope) and I welcome criticism, but your post is totally unconstructive and unsubstantial.

[atoav]

I am of the same impression — Rust as a language forces you to come at terms with your own ideas of how code should look.

That being said I still have a deep dislike of having to read through nested Arc Mutexes or whatever to figure out what the code does in principle before I figure out what is going on in detail with the ownership.

I know there are no perfect solutions and there are trade-offs to be made, but I wish there was a way to have it more readable.

So instead of this:

    let s = Arc::new(Mutex::new(Something::new("foo")));

something a bit like this:

    let s = Something::new("bar").arc()
                                 .mutex();

[insanitybit]

FWIW Arc implements From<T> so you can do `let foo = blah().into()` and if `foo` is passed to something expecting Arc it'll be an Arc. This probably works for Arc<Mutex<T>> as well so you'd be able to do `.into().into()` but I'm not sure.

[bobbylarrybobby]

Iirc you can't chain .into() because the compiler can't be sure whether the first is meant to do the whole conversion and the second is the identity (impl From<T> for T), or if the first does one step and the second the next or if the first is the identity and the second does the whole conversion. (In fact I think the existence of the first and third options alone is enough to preclude chained .into() from working due to the ambiguity.)

[insanitybit]

You're right.

[mborch]

Looks like you're asking for syntax sugaring for T::new wrapping, e.g. `"bar" |> Something |> Arc |> Mutex`.