Hacker News Reader

Comment by bsaul | Hacker News Reader

I think it's to enable safe concurrency. The problem is they decided to let others build the primitives for concurrency, on top of the stdlib. Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc..

View on HN

Problem?

The goal of Rust is to be a general system programing language.

In fact, Rust in the past had a runtime that included green threads a primitives; that ended up being a problem. The runtime and stdlib was only usable in some system programing task (defeating the whole goal).

If I remember right, Rusts approach for their stdlib is that the bare minimum is actually in there and everything else is to be supplied by libraries, like the getopts crate that was split from the stdlib AFAIK.

Generally speaking, yes. This is driven by three things, largely: Rust has a very wide variety of use-cases, we don't want to stabilize a poor API forever, and Cargo exists and works well.

> Which means the language didn't decide between actor vs futures vs coroutine vs event loop, etc..

Having the language decide on one method of concurrency would make it useless for lots of people's purposes (including ours).

On the other hand, since these methods are not compatible it will create certain split in the ecosystem.

Those splits are inevitable. There is no One Size Fits All concurrency primitive. Embedded devs and web devs have vastly different requirements.

Either the split is "every use-case finds the primitive that works best for it" (Rust), or the split is "here's the blessed primitive, other use-cases can pound sand" (Go)

Must it? In fact, I'd expect the reverse -- choosing a model for the language will make the ecosystem tied to that model

For example, while tokio is being integrated with hyper, it does not affect the "usual" users of hyper at all, both in terms of API and in terms of what's going on under the hood, cost-wise.

Having a blessed solution for async like tokio that is not in the stdlib seems to encourage folks to integrate with it, but not in an irrevocable manner; the core library stays intact and able to support potential other models in the future.

Sure, I do hope we can focus on one concurrency primitive, but the possibility that we may have async/await and coroutine at the same time seems kind of unfortunate to me.

AFAICT async/await the way Rust intends to have it (plans are rough right now) basically coroutines with extra sugar to specialize it with futures. The core language won't know about event loops, it will just know about futures, and you wire up your async/await or whatever to the event loop yourself. As both in the context of concurrency will involve futures they will probably work well together.

I'd love to see this goes well with highest performance.

AFAICT It's all going to be a generator-like abstraction which is pretty zero-cost.

The real world is always more complicated, since cps carries stack in its arguments.

Hmm. I guess the community will eventually decide on one particular primitive, hopefully soon.

I don't think it's a good idea for Rust to choose a particular kind of concurrency primitive. Rust is pretty broad in its use cases, and choosing a primitive may end up restricting other fields. Remember that Rust used to have a libuv based green threading model, and it was removed for precisely this reason -- it affected some use cases in major ways.

Rather, it is important for subcommunities to rally around particular sets of libraries. E.g. the web and I/O related libraries seem to all be going in the direction of integrating with tokio. This means a web programmer can use tokio and it will work smoothly. OTOH, a different subcommunity that uses a different set of libs may use stuff built on rayon and crossbeam.

That's fair; it allows for lots of flexibility.

I hope the same, but i don't have great hopes. For a community to adopt a library as fundamental as this one would be, it would need to be of such a high level that i think only the language designer can create it ( or other really big names in the field).

If you think of something like OTP, i don't see any equivalent anywhere else. Even akka isn't unanimously used as the foundation for server side dev on the jvm.

Two of the three Tokio core team members are on the core team of Rust, and one of them is on the language design team.

EDIT: to be clear, that means one is on both. The third member is very well-known as well; having built the async primitives that this is built on, as well as initially implementing Cargo. Bona fides aren't an issue here.

Didn't know that. That's clearly a good thing.

> Hmm. I guess the community will eventually decide on one particular primitive, hopefully soon.

Ultimately you'll get libraries or frameworks that are not compatible with each other because they use different concurrency models. That's a mistake Rust will pay in the future.

You get that anyways. The question is how popular something like tokio will get. Since its blessed by the core team and the language designers, I think it will get popular, and therefore many will use it. But there will inevitably be someone who doesn't like it, or for whom it doesn't fit, and they will use something else. But that happens no matter if tokio is in the stdlib or not.

That's obviously a threat. But so far this is not what's happening: since tokio and future-rs were announced we've seen most library authors ditching their old stuff to use tokio instead.

Not really. People in the Rust community have shown a great deal of willingness to standardize on a handful of traits, so things tend to be intercompatible. That might change, I guess. In any case, there's no point in using an async I/O model for the majority of use cases many of the people using Rust are interested in, so people standardizing on something else for those usecases isn't a problem.

Reply on news.ycombinator.com