I can totally understand that opinion, but let me give a further view on that:
I implemented in the last years dozens of async/event-driven networking libraries, and wanted to do the same in Rust about 4 years ago. I guess I even started to work on the first async IO libraries for it (https://github.com/Matthias247/revbio). However I also got frustrated quite quickly with it, since the ownership model makes the typical solutions for asynchronous programming super hard (e.g. callbacks or callback interfaces). Therefore I also gave up on that (and also temporarily on the language).
However some years and evolution of Rust later my viewpoint on this changed a bit:
- Asynchronous I/O is generally messy and leaves a lot of room for errors. E.g. each callback that is involved might cause reentrancy problems or invalidations, object lifetimes might not be well-defined or matching expectations, etc. While most languages still allow it, it's hard to get fully right. Especially when manual memory management is involved. Async I/O plus multithreading is mostly a recipe for disaster.
- Rust just puts these facts directly in our face, and wants to you to go the extra route to provide that things are working directly. It's far from easy to figure out how to do this in a sane way. I think the tokio authors did an awesome job on finding some primitive abstractions with the poll model that allows for async I/O and uses Rusts type system for safety guarantees. It's a little bit akward to use without syntactic sugar like async/await or coroutines, but I think that is in the nature of the problem.
- Trying to do async IO probably shows off the domain which is the most inconvenient in Rust (besides similar problems like object-oriented and callback-driven UI frameworks). Therefore it shouldn't be used as a general point of measurement how easy or complex Rust is to use.
I am not trying to personally attack you here, but most times when people say something like this, what they are actually saying is: "I think I am accomplishing the same thing in C++, but by not facing (and solving) the problems, I am actually creating a program with nasty hidden bugs, that might or might not blow up in my face later".
In that case RefCell[1] is the right approach. I use it a ton with C callbacks where like you said you can't get the compiler to understand lifetimes. You get the added bonus of Rust validating the lifetime at runtime and catching any regressions.
In the rare case where the lifetime check is too expensive you're free to turn the types into pointers and use an unsafe block, which gives you the exact same constraints as you have in C++.
I've once spent quite a few hours debugging a dangling pointer that wasn't zeroed after delete and was written to which might or might not have corrupted a piece of lua interpreter's state.
fixing that felt good. the preceding 24 hours, not so much.
Rust really doesn’t require much intelligence per se; it’s just a different set of patterns to learn.
I find myself thinking more about data ownership, allocations, and type structure. C++ is more about testing correctness about memory ownership and trying to break existing assumptions as I code. Different skillsets entirely!
You may be able to produce C++ faster, but i’d choose maintaining a rust codebase any day. Memory models require a lot of energy to maintain correctly, and rust does the heavy lifting for you.
Yup, I'd even go further to say that if you don't need the memory or performance advantages that come with native languages it's probably a better idea to reach for your favorite flavor of GC'd language instead.
That said, when you need it Rust does the right thing both in keeping you from blowing off your foot and making cross-platform development a breeze.
I can tell you from experience that if you persistently ask newbie questions on the Rust help channels, they'll get enough information out of you that they can say "oh, just put X, Y and Z on line 22 of your code" and it will work, even if you don't understand it.
An argument could be made around you not being smart enough for C++ either if you are truly unable to write the equivalent program in Rust.
Rust simply makes memory-correctness something the compiler can check. Correct C++ programs are the same as correct Rust programs, the compiler simply isn’t enforcing it.
You don't have to, as Tokio is just a building block for people who're implementing protocols. But those implementations will have great safe, zero-copying characteristics.
vs Rust where I bash my head against it for 2 days then give up. I'm not smart enough for Rust, oh well.