5 ms·

> Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions. Aren’t abstractions supposed to make things easier to learn? So

> 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)

curun1r 9y ago
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 9y ago
  So what, if you aren't already an expert then go away you aren't wanted?
tatterdemalion 9y ago
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 9y ago
  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 9y ago
    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.
niftich 9y ago
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 9y ago
  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.
jcrites 9y ago
> 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-heartbleed-bug.html https://www.seancassidy.me/diagnosis-of-the-openssl-heartble...
- kindfellow92 9y ago
  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.
- lurr 9y ago
  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.
  - simplify 9y ago
    I wouldn't say you're "not smart enough", I would say the subject is not yet well-taught.
lossolo 9y ago
Reading rust subreddit it seems like around 90% of opinions about Tokio are negative, that's why they are rewriting it.
Groxx 9y ago
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.

curun1r 9y ago

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 9y ago
So what, if you aren't already an expert then go away you aren't wanted?

tatterdemalion 9y ago

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 9y ago
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 9y ago
  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.

niftich 9y ago

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 9y ago
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.

jcrites 9y ago

> 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-heartbleed-bug.html https://www.seancassidy.me/diagnosis-of-the-openssl-heartble...

kindfellow92 9y ago
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.
lurr 9y ago
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.
- simplify 9y ago
  I wouldn't say you're "not smart enough", I would say the subject is not yet well-taught.

lossolo 9y ago

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

Groxx 9y ago

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.