[kindfellow92]

> Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions.

Aren’t abstractions supposed to make things easier to learn? Something about the idea of “complex abstractions” seems wrong.

(Edit: this is not a criticism of Tokio, it’s a criticism of the OP’s characterization of “sophisticated abstractions” which IMO should reduce complexity)

[jcrites]

> Aren’t abstractions supposed to make things easier to learn?

Not always. Some abstractions are designed to make it easier to solve hard problems correctly (than without the abstraction).

For example, consider Rust's memory model. Many people criticize that model as difficult to learn. By comparison, you might argue that C's memory model is simpler to learn. Yet, the C approach to allocating, using, and freeing memory is highly error-prone. C programs historically have frequently had mistakes such as use-after-free errors, or buffer under/overflow/reuse errors. The high-profile OpenSSL Heartbleed vulnerability was an example of a weakness in C's memory model and memory handling abstractions [1].

Rust's memory model may be more difficult to learn than C's, but once learned, they are abstractions that provide an advantage in building correct software, by ruling out certain classes of mistakes. (GC in languages like C# and Java and Go can also prevent these mistakes, but comes with a runtime cost. Rust aims to provide zero-cost abstractions.)

Building correct async IO programs using kernel abstractions is difficult for similar reasons as it's difficult to write correct programs with C's memory model. It's especially difficult if you want the async IO program to be portable across multiple OS/kernels. I have not used Tokio, but I would guess that its Rust-powered abstractions will make it difficult or impossible to leak memory or sockets, or to fail to handle error cases that might arise handling async IO.

[1] https://www.seancassidy.me/diagnosis-of-the-openssl-heartble...

[lurr]

Yeah, but I actually have a reasonable chance of accomplishing what I want in C++.

vs Rust where I bash my head against it for 2 days then give up. I'm not smart enough for Rust, oh well.

[Matthias247]

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.

[hobofan]

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".

[lurr]

No, it's more "I know the lifetimes are right, but I can't figure out how to convince the compiler. I give up, I'm just going to go write it in C++".

I'm not the only one to make such comments. They made sure to try and address this in v2 of the book. It still sucks.

[vvanders]

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++.

[1] https://doc.rust-lang.org/std/cell/index.html

[steveklabnik]

Sorry that you had this experience. If you have the time, any concrete specifics about things would be helpful.

[CJefferson]

On the other hand, a buggy C++ program is still better than no rust program.

[vvanders]

Having had to track down memory data races in a production C++ codebase I'm not sure that I completely agree with your assessment.

[baq]

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.

[drb91]

Trivially false: buggy autopilot software is, many times, worse than no autopilot software if the bug is “blow up immediately”.

Some problems are worth the time to solve them.

[CJefferson]

Ok yes, I wouldnt write an autopilot in C++.

However, for example, on the average desktop or mobile app, it's not clear to me(yet!) it is worth the pain of writing in rust.

[lurr]

but I'm not writing autopilot software and rust isn't going to save you from everything.

[drb91]

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.

[vvanders]

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.

[ocschwar]

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.

[kindfellow92]

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.

[lurr]

> Rust simply makes memory-correctness something the compiler can check

and the latter half of that statement is where things get problematic. Prove it to the compiler has repeatedly been too hard.

[baq]

if it's too hard, drop to unsafe - you have the same guarantees as C++ there.

the real problem is telling when it's impossible, e.g. in recurrent data structures, like linked lists and trees. that takes practice.

[simplify]

I wouldn't say you're "not smart enough", I would say the subject is not yet well-taught.

[xiphias]

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.

[kindfellow92]

I think you’re comparing apples and oranges here.

Writing memory safe code without Rust is harder than using Rust’s abstractions to do the same task. If you agree with that then my comment stands.

[tatterdemalion]

There are various criticisms of tokio, coming from different directions. Some have to do with the fact that some abstractions in the futures ecosystem are leaky today and that makes them less easy to use than they could be (though they won't always be leaky[]). But others have to do with understanding the internal implementation of these abstractions - people who feel they must understand how their library works internally before using it.

Of course, schedulers are just complicated. Most of the time you don't think about how complicated your scheduler is, because its either an OS primitive in the kernel or a language primitive in your language's runtime. But since tokio is a library - and modular - it gets criticism for being complex that in my opinion is unfair.

[] To be more concrete: a future is essentially a state machine representing the stack state at any yield point; it can't (currently) contain lightweight references into itself because they'd be invalidated when the future is move around. This means using borrowing in futures programs is often infeasible today. Solutions are in the works.

[kindfellow92]

My point is that “sophisticated abstractions” should reduce complexity, not increase it.

If Tokio’s abstractions are seemingly increasing complexity, maybe they aren’t sophisticated abstractions.

This is a criticism of the OP, not Tokio.

[tatterdemalion]

I understood your point. As my comment alluded to, the criticisms of tokio this blog post is attempting to address have to do with the implementation complexity - abstractions do not reduce the implementation complexity of themselves.

[curun1r]

It depends on whether an abstraction is intended for novices or, for lack of a better term, power users. Tokio is, IMHO, more of the latter. It's a complex set of concepts that is designed to scale up very well as the complexity of the task increases but doesn't scale down very well for simple tasks* . Learning quite often involves those simple tasks, so Tokio gets a reputation for being hard to learn. But when you take an easy-to-learn abstraction and try to scale it up to handle very complex problems, you often find the abstraction breaks down much more easily than something like Tokio does.

Tokio doesn't subscribe the the Larry Wall philosophy of making the easy things easy and the hard things possible. It seems more focused on making the hard things as easy as possible without much regard for the easy things.

* Before anyone attacks this...yes, you can accomplish simple tasks in Tokio, but it requires learning a lot more concepts than should be necessary to accomplish that simple task.

[lurr]

So what, if you aren't already an expert then go away you aren't wanted?

[Groxx]

I'd argue it should be "abstractions take care of problems you don't care about". What you care about may be different from others, hence the variety of abstractions. Some (many!) favor ease-of-learning for general use, some favor safety at all costs, some favor explicit memory layout, some hardware independence, etc.

[niftich]

I think the author's quote is a bit of an overstatement. Reading the docs on tokio_core seems that knowledge could be readily transferred if you've worked with Node, or browser JS, Java Futures, or a game engine -- this, of course, means you've been exposed to similar abstractions, potentially with different terminology.

I think the quote is to be interpreted in terms of, if you've only ever seen blocking IO, and have never seen async IO or deferred computation, you have to learn some things first, but this isn't unique to Tokio in particular.

[Yoric]

Actually, Tokio's futures are a bit different from the async IO (including most implementations of futures) in ecosystems. Nothing world-breaking, but they have shaped the abstraction a bit differently in order to be more efficient with respect to memory management, so it can be a bit surprising.

[lossolo]

Reading rust subreddit it seems like around 90% of opinions about Tokio are negative, that's why they are rewriting it.