Async-std: an async port of the Rust standard library

https://async.rs/blog/announcing-async-std/#

by JoshTriplett • 7 years ago

349 234 7 years ago

There is further discussion about this library on the rust subreddit: https://www.reddit.com/r/rust/comments/cr85pp/announcing_asy...

evmar• 7 years ago

In case anyone else was curious how you create nonblocking file I/O, it appears to use threads.

I am curious if the number of threads is unbounded, or if they have a bounded set but accept deadlocks, or if there is a third option other than those two that I am unaware of.

slovenlyrobot3• 7 years ago

io_uring grew support for buffered IO in recent kernels, so we should have widespread support for this in userspace circa 2025

monocasa4• 7 years ago

Or just detect it and swap out the implementation. Less than a year until an Ubuntu LTS that has it.

dmytroi3• 7 years ago

Except that io_uring is threads running in kernel.

There is no true async I/O on most (if not all) current platforms - it's all threads, either in user space or in kernel space. Sometimes even deliberately, for example polling disk will give better latency compared to waiting for IRQ.

layoutIfNeeded• 7 years ago

Non-blocking I/O via threads? That’s what we used to call blocking I/O :D

rmgraham2• 7 years ago

Are those really the only options? I'm trying to wrap my head around how using a fixed size thread pool for I/O automatically implies deadlocks but I just can't. Unless the threads block on completion until their results are consumed instead of just notifying and then taking the next task..

I can definitely imagine blocking happening while waiting for a worker to be available, though. Did you mean simply blocking instead of deadlock?

spullara2• 7 years ago

N threads, with N readers waiting for a message that will only come if the N+1 reader (still in the queue) gets a message first.

Argorak20• 7 years ago

Note that the implementation of the runtime itself is subject to change. It's currently an unbounded threadpool.

https://github.com/async-rs/async-std/pulls?utf8=%E2%9C%93&q...

davidhyde2• 7 years ago

Great library, well done. In case anyone was wondering this is not a [no_std] crate even though it can be used as a replacement for std library calls. I guess it (obviously) can't be since it interfaces with the operating system so much.

Argorak20• 7 years ago

Project member here.

It exports stdlib types (like io::Error) where appropriate so that libraries working with these can stay compatible, so `no_std` is not really an option.

The underlying library (async-task) is essentially core + liballoc, just no one made the effort to spell that out, yet.

davidhyde2• 7 years ago

It exports stdlib types (like io::Error)

Excellent, good to know!

thethirdone• 7 years ago

Would there be any benefit to making a `no_std` option? I can't think of a situation you would want async std and have including std be a problem.

bpye2• 7 years ago

I really wish we could work out a better way to make no_std easier. I know why io::Error requires std for example, but it makes things difficult.

It would be nice if you could provide your own sys crate so you could even use some of std on an embedded device. If you had say an RTC you could make time related calls work, maybe you'd wire networking to smoltcp etc. Currently you could do that - maybe - but you'd have to modify the Rust standard library.

Argorak20• 7 years ago

The stdlib is already just a facade. There's plans to make that more explicit, maybe opening up the way to things like that.

But that plan is severely understaffed, we go so much else to do.

Un1corn• 7 years ago

This remind me of the blog post "What Color is Your Function?"[0], they had to create a different library that is the same as the standard library but with async functions.

I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead.

[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

pohl• 7 years ago

The caller of the function knows nothing about what happens within the body of the function. (Is it just doing computation, or is it doing I/O?). The async keyword is how the author of the function makes it explicit that caller should choose when to await the result.

Isn't the alternative WCiYF is proposing to allow the caller to treat any function asynchronously, while having no way to discern whether doing so might be counterproductive?

Argorak20• 7 years ago

Rust async functions are also different here. They don't run the code, they create a Future structure in it's initial state. Contrary to e.g. JavaScript, it doesn't start to run until you end up putting it on an executor. So the actual function call does something very different from what happens in other languages.

It's sometimes called "cold futures".

bryanlarsen2• 7 years ago

None of the 5 points in that article about callbacks in 2015 node.js apply to async in Rust. The Rust people spent years agonizing over their version of async and applied a lot of lessons learned from implementations in other languages.

https://news.ycombinator.com/item?id=20676641

It's trivial to turn async into sync in Rust. You can use ".poll", "executor::block_on", et cetera.

Turning sync into async is harder in any language. Even Go with it's easy threading. That's a good argument to make async the default in libraries in Rust, but since async isn't stable yet, that would have been hard to do 5 years ago.

merb• 7 years ago

Turning sync into async is harder in any language.

well in most languages you can wrap sync into async. so it's not "hard". it's just harder to have NON blocking code. i.e. in c# there is a difference between:

`await Task.Run(() => Thread.Sleep(5000));`

and

`await Task.Delay(5000);`

both will wait for 5 seconds but one will waste cpu cycles while the other won't.

dnautics4• 7 years ago

Turning sync into async is harder in any language.

Elixir's Task module (in the stdlib):

    future = Task.async(fn ->
      do_something_here
    end)
    
    ...do_other_things...

    result = Task.await(future, timeout)

Mixing it with the Enum library makes concurrency dead-simple (got I a junior dev dispatching concurrent tasks in scripts with confidence), at the expense of an ugly nested double lambda.

    some_list_of_values
    |> Enum.map(fn value -> 
      Task(fn -> do_something_with(value) end) 
    end)
    |> Enum.map(&Task.await(&1, timeout))

vbezhenar• 7 years ago

It's trivial to turn async into sync in Rust. You can use ".poll", "executor::block_on", et cetera.

Is it 0-cost abstraction? I mean, is `sync_read` will compile to the same code like `async_read.poll`? Because turning sync into async is kind of trivial as well: just spawn new thread for that sync block.

wahern3• 7 years ago

Literally none of your rebuttals actual rebut the claims. The very fact that async-std exists is absolute proof that the issue remains--if there wasn't a "color" problem there wouldn't be any need for a "port" of the standard library.

Rust had legitimate reasons for taking the approach that they did. One can agree that they made the correct decision without excusing and obscuring the consequential costs.

jeremyjh6• 7 years ago

that would have been hard to do 5 years ago.

Five years ago Rust still had green threads. Literally every standard library I/O function was async, and the awaits were always written for you with no effort.

Its literally taken five years to get back to an alpha thats not as good, and we'll still have to wait for a new ecosystem to built on top of it. I know not everyone writes socket servers and so forcing the old model on everyone probably doesn't make sense long-term, but I still have to shake my head at comments like this.

https://github.com/rust-lang/rfcs/pull/230

Jayschwa• 7 years ago

As an aside, Zig[0] recently merged a change to try and tackle the use case of [a]sync-agnostic functions: https://github.com/ziglang/zig/issues/1778. The "What Color is Your Function" blog post appears to have been one of the inspirations behind the change. Some of Andy's (the language creator) recent videos go over it in detail: https://www.youtube.com/channel/UCUICU6mgcyGy61pojwuWyHA

[0] https://ziglang.org

MrBuddyCasino4• 7 years ago

That looks quite interesting!

The idea is that you can set the global "io_mode" mode to blocking, mixed or evented and I/O functions will switch their implementation accordingly. The type of the function will then, if I got that right, propagate up the call stack and turn functions that touch it transparently into either normal or async/awaitable funtions.

Nice way to avoid a bifurcation of the ecosystem into red/green functions. Its a bit magical maybe, any other trade-offs?

zzzcpan7• 7 years ago

The point of asynchronous programming is to know exactly where concurrency happens in your code. This both eliminates concurrency bugs and gives you predictability for high performance.

otabdeveloper22• 7 years ago

Cooperative multitasking, like it's 1995 again?

No thanks.

lmm• 7 years ago

The right way to handle this stuff is polymorphism. But with Rust lacking higher-kinded types I guess that's not possible. A decent test of whether their "associated type constructors" actually solve the same problems, as sometimes claimed, would be whether you can write this kind of async-polymorphic code with them.

pcwalton13• 7 years ago

I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead.

In fact, Rust does have a great solution for nonblocking code: just use threads! Threads work great, they are very fast on Linux, and solutions such as goroutines are just implementations of threads in userland anyway. (The "what color is your function?" post fails to acknowledge that goroutines are just threads, which is one of my major issues with it.) People tell me that Rust services scale up to thousands of requests per second on Linux by just using 1:1 threads.

Async is there for those who want better performance than what threads/goroutines/etc. can provide. If you don't want to deal with two "colors" of functions, you don't have to! Just use threads.

temac• 7 years ago

The "what color is your function?" post fails to acknowledge that goroutines are just threads, which is one of my major issues with it.

"""Three more languages that don’t have this problem: Go, Lua, and Ruby.

Any guess what they have in common?

Threads. Or, more precisely: multiple independent callstacks that can be switched between. It isn’t strictly necessary for them to be operating system threads. Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate."""

What more do you need?

nullwasamistake4• 7 years ago

Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency.

Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,000 threads. The OS isn't going to like that.

With async you can run a single thread per core, with no concurrency limits. So you get your 500k requests without overhead. With fibers you just run 20k fibers which is a little bit of overhead but easy to do.

This is the core reason everyone is pushing async and fibers in fast languages. When you can push a ton of requests/second but each one has latency you can't control, regular threads will kneecap performance.

In "slow" languages like Python, Ruby, etc, async/fibers don't really matter because you can't handle enough requests to saturate a huge thread pool anyways.

dom96• 7 years ago

There are ways to get around this, the way that I have done it in Nim is via a `multisync` macro:

    proc readLine(s: Socket | AsyncSocket): Future[string] {.multisync.} =
      while true:
        let c = await s.recv(1)
        case c
        of '\n':
          return
        else:
          result.add(c)

This is equivalent to defining two `readLine` procedures, one performing synchronous IO and accepting a `Socket` and another performing asynchronous IO and accepting an `AsyncSocket`. It works very well in practice.

epage• 7 years ago

This is why I'm curious about algebraic effects which was recently discussed on /r/rust [0]

The main challenges I see are around usability within the language design on how best to propagate and compose them.

[0] https://www.reddit.com/r/rust/comments/cjcwmu/is_there_inter...

grayrest• 7 years ago

I found out about algebraic effects a year or two ago when I ran across the efforts to bring them to OCaml. Async/await was a preliminary thing so I though algebraic effects would be a more complete solution and more in line with the Rust ethos. After asking around in some NYC meetups and on Reddit , my impression is that there isn't a lot of appetite to break additional new ground in terms of bringing fringe language features (I'm unaware of a non-academic language that features them in a production release, OCaml is closest AFAIK) into a language that already has a fairly high barrier to entry.

otabdeveloper22• 7 years ago

I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead.

'async' exists because Python has that GIL bullshit and so Python programmers had to invent that fifth wheel of 'async programming'.

Programmers in other languages then got jealous because they, too, wanted a complex, unnecessary framework that pollutes the whole runtime and serves to differentiate regular programmers from 'rockstar' programmers.

And so async got fashionable and barely-literate coders now think async is magic performance dust that will automatically make your program run 1000% faster.

TL;DR - it's just fashion, give it five years and we'll be reading posts about how async sucks and that it's stupid legacy tech invented by bonehead dinosaurs.

atombender2• 7 years ago

Pretty sure the async/await support in C# predates Python.

C# introduced it in 5.0, which came out in August 2012. The Python proposal (PEP 3156) for an async library was posted in 2012, the proposal (PEP 492) for async/await syntax in 2015, and implemented in Python 3.4 and 3.5 respectively, I believe. So C# predates Python by about 3 years.

From what I can gather, Python was influenced by C#. But C# doesn't have a global lock, and that's not why it has async/await.

Edit: Added PEP reference.

jedisct13• 7 years ago

How does it balance tasks across CPU cores?

The thing I like in Go is that I don’t have to worry about that, it’s all automatic.

pythonist• 7 years ago

I am wondering that also, scheduler is of most importance.

Go is such a joy to work with.

Argorak20• 7 years ago

It does the scheduling for you. That's why all Futures put onto task through `async_std::task` must be `Send`. That's Rust parlance for "can be safely migrated between threads".

It's not Go, but we know what people like about Go. <3

pcwalton13• 7 years ago

In Rust you use async/await with a scheduler like mio that will automatically do that for you as well.

littlestymaar5• 7 years ago

Has preemptive scheduling landed in Go ? Because last time I worked with it (Go 1.10) it was still cooperative and you had to worry about it otherwise you could get bitten badly.

2bitencryption2• 7 years ago

I must be dumb, because every time I dive into async/await, I feel like I reach an epiphany about how it works, and how to use it. Then a week later I read about it again and totally lost all understanding.

What do I gain if I have code like this [0], which has a bunch of `.await?` in sequence?

I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are `.await`-ing to complete?

I know this allows the executor to go poll other futures. But if we haven't explicitly spawned more futures concurrently, via something like task::spawn() or thread::spawn(), then there's nothing else the cpu can possible do in our process?

[0] https://github.com/async-rs/async-std/blob/master/examples/t...

Argorak20• 7 years ago

In small examples like this, you don't gain anything. For the sake of the example, we just run one task. But you _could_ run 100 with them. And at each of those `awaits`, they could schedule differently.

For a more complex networked application, we have the tutorial here: https://github.com/async-rs/a-chat

pvorb• 7 years ago

Wouldn't it make more sense to show an example that actually takes advantage of async/await? I don't get why they are using examples that need a disclaimer like you can run 100 jobs for this to make sense. So it should include that in the example (and it should probably do something that makes sense if it's run a hundred times).

weavie• 7 years ago

Yeah if there are no other futures spawned, then the await is going to cause the app to just sit there until the future completes. It's got nothing better to do.

If there was another future spawned then the await would cause the runtime to sit there until either of the futures completed. The code would attend to the first future that completes intil that hits an await.

marshray• 7 years ago

And where it all comes together is when async lets us write concurrent functions that compose together well in a way that functions that can block on IO and lock acquision do not.

esotericn3• 7 years ago

Right, that specific instance is essentially a single-threaded* application.

Now imagine that you spawned a few hundred of them with JoinAll. Each would run, multiplexed within a single thread, with execution being passed at the await points.

* anyone know the correct nomenclature for this? Single-coroutine?

fzzzy• 7 years ago

Cooperative threads are still threads, they just aren't preemptive.

staticassertion2• 7 years ago

Serial?

zamadatix• 7 years ago

A good example is say you want to handle 100k TCP sessions concurrently. You probably don't want to launch 100k threads considering the overhead in doing so and constantly switching between them. You also don't want to do things synchronously as you'll constantly be waiting on pauses instead of doing work on the 100k sessions. So you launch 100k instances of it as an async function and they all stay in a single thread (or couple of threads if you want to utilize multiple cores for the work) and instead of constantly waiting on pauses it simply works on the log of queued up events.

Same code flow just it allows you to launch the same thing multiple times without having to wait for the whole thing to finish sequentially or wait on the OS to handle your threads.

Thaxll• 7 years ago

This is missing a crutial explanation that the underlying OS API are asynchronous.

abstractbarista• 7 years ago

This really helped my practical understanding - Thanks!

jensneuse• 7 years ago

Does this mean that rust async is using poll/epoll/kqueue under the hood?

MaxBarraclough3• 7 years ago

I must be dumb

Nope, async really isn't trivial.

I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are `.await`-ing to complete?

It doesn't, that's the charm of it.

It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts.

I realise we're not talking C#/.Net, but that's what I know: in .Net, your function might do slow IO (network activity, say) then process the result to produce an int. Your function will have a return-type of `Task<int>`. Your function will quickly return a non-completed Task object, which will enter a completed state only once the network activity has concluded and processing has occurred to give the final `int` value.

The caller of your function can use the `Task#ContinueWith` method, which enqueues work to occur if/when the Task completes, using the result value from the Task. (We'll ignore exceptions here.)

Internal to your function, the network activity itself will also have taken the form of a standard-library Task, and our function will have made use of its `ContinueWith` method. Things can compose nicely in this way; `Task#ContinueWith` returns another Task.

(We needn't think about the particulars of threads too much here, but some thread clearly eventually marks that Task object as completed, so clearly some thread will be in a good position to 'notice' that it's time to act on that `ContinueWith` now. The continuation generally isn't guaranteed to run on the same thread as where we started. That's generally fine, with some notable exceptions.)

You might think that chain-invoking `ContinueWith` would get tedious, as you'd have to write a new function for each step of the way if we make use of several async operations - each continuation means writing another function to pass to `ContinueWith`, after all. Perhaps it would be more natural to just write one big function and have compiler handle the `ContinueWith` calls.

You'd be right. That's why they invented the `await` keyword, which is essentially just syntactic sugar around .Net's `ContinueWith` method. It also correctly handles exceptions, which would otherwise be error-prone, so it's generally best to avoid writing continuations manually.

There's more machinery at play here of course, but that seems like a good starting point.

Assorted related topics:

* If you use `ContinueWith` on a Task which is already completed, it can just stay on the same thread 'here and now' to run your code

* It's possible to produce already-completed Task objects. Rarely useful, but permitted.

* There's plenty going on with thread-pools and .Net 'contexts'

* The often-overlooked possibility of deadlocking if you aren't careful [0]

* None of this would make sense if we had to keep lots of background threads around to fire our continuations, but we don't [1]

* Going async is not the same thing as parallelising, but Tasks are great for managing parallelism too

* This stuff doesn't improve 'straight-line' performance, but it can greatly improve our scalability by avoiding blocking threads to wait on IO. (That is to say, we can better handle a high rate of requests, but our speed at handling a lone request on a quiet day, will be no better.)

I found this overview to be fairly digestible [2]

[0] https://blog.stephencleary.com/2012/07/dont-block-on-async-c...

[1] https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...

[2] https://stackoverflow.com/a/39796872/

https://docs.microsoft.com/en-us/dotnet/api/system.threading...

Argorak20• 7 years ago

It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts.

Slight word of warning: `async/await` is more than just sugar in Rust, it also enables borrowing over awaits, which was previously not possible.

cheez• 7 years ago

async/await are coroutines and continuations (bear with me).

Here is synchronous code:

    result = server.getStuff()
    print(result)

Here is synchronous code, that tries to be asynchronous:

    server.getStuff(lambda result: print(result))

Once server.getStuff returns, the callback passed to it is called with the result.

Here is the same code with async/await:

    result = await server.getStuff()
    print(result)

Internally, the compiler rewrites it to (roughly) the second form. That's called a continuation.

That's pretty much it.

A more involved example.

Synchronous code:

    result = server.getStuff()
    second = server.getMoreStuff(result+1)
    print(result)

Synchronous code that tries to be asynchronous:

    server.getStuff(
        lambda result: server.getMoreStuff(
          result+1, 
          lambda result2: print(result2)
    ))

A lot of JS code used to look like this hideous monstrosity.

Async/await version:

    result = await server.getStuff()
    second = await server.getMoreStuff(result+1)
    print(result)

Remember again, that it is basically transformed by the compiler into the second form.

arcticbull• 7 years ago

This is an incredibly helpful explanation. I went from not really knowing what all this mumbo jumbo was about to a useful mental model. Cheers!

2bitencryption2• 7 years ago

Thanks. Helpful. My question is, in this example:

    result = await server.getStuff()
    second = await server.getMoreStuff(result+1)
    print(result)

`await getStuff()` MUST terminate before `await getMoreStuff() ` begins. So this chunk alone is analagous to synchronous code, unless we're in the middle of a spawned task, and there are other spawned tasks in the executor that can be picked up.

jnbiche2• 7 years ago

I don't understand your examples of "Synchronous code that tries to be asynchronous". In fact, the examples you provided are of asynchronous code being...asynchronous. Callbacks are asynchronous (or to be fully correct, I should say that they allow one to program asynchronously, which is exactly what async/await does).

Indeed, since you mention continuations, I'm sure you realize that they're more or less callbacks.

z3t4• 7 years ago

    server.getStuff(gotStuff)
    server.getMoreStuff(gotMoreStuff)

Just using functions is more simple and also more powerful. A function being async usually means stuff will happen, things can go wrong, and you might want to do different things depending on the response or whether it failed.

Where await is useful though is in serial execution of async functions that really should be sync, but them being async is an optimization in order to not block the thread.

It is really unfortunately that so much extra crud had to be introduced to JS (corutines, async, promises) in order to be able to await. Reading complex Promise based code is very unplesent, with async functions pretending to be pure, without any error handling, full of side effects, and omitted returns.

With callbacks we had inexperienced programmers writing pyramids of callbacks and if logic. But it was not that bad, as the complexity was in your face, and not hidden under layers of leaky abstraction.

ijidak• 7 years ago

So, the power of async await is no greater than the thread pool manager sitting under it.

You are correct. In edge cases where there is only 1 await in the queue for 1 process with 1 thread you gain nothing.

But you're accurately describing an edge case where await has limited value.

Await's true power shows up when you anticipate having multiple in-flight operations that all will, at overlapping points, be waiting on something.

Rather than consume the current thread while waiting, you're telling the run-time, go ahead and resume another task that has reached the end of its await.

This was possible before using various asynchronous design patterns, but all of them were clunky, in that they required boilerplate code to do what the compiler should be able to figure out on its own:

"Hey, runtime. This is an asynchronous call. Go do something useful with this thread and get back to me."

Second, await is MUCH EASIER for future developers to process because it looks exactly like any other method call and makes it easy to reason about the logic flow of the code.

Rather than chasing down async callbacks and other boilerplate concepts to manually handle asynchronous requests, the code reads like its synchronous twin.

int a = await EasyToFollowAsyncIntent();

This makes the code much easier to reason about.

To me those are the 2 biggest gains from async.

1. Less boilerplate code for asynchronous calls.

2. Code remains linearly readable despite being highly asynchronous.

nurettin• 7 years ago

Say you want to listen to a socket and also receive input from the keyboard at the same time.

If you have an async method that can wait for input on both devices, you can await the results of both of them, and they won't block eachother.

justicezyx• 7 years ago

User space threads and corouting is pretty much the right abstraction for application code.

Async can be useful when more control over the details of execution is needed.

twblalock• 7 years ago

Async/await and futures/promises (and before that, stuff like Java's Executor abstraction) are being added to a lot of languages because it is very difficult for even experienced developers to manage threads in a bug-free way.

I've seen a lot of people try to manage complex programs by working with threads directly. Whatever they come up with is very unlikely to be as correct and reliable as the abstractions provided by the language. Even when they get it right, programs written with those techniques are difficult to modify without introducing new bugs.

Manual management of threads is becoming like manual management of memory -- it is discouraged by newer language features and you should only do if you really need to.

MusharibSajid• 7 years ago

Async is a hard concept but what can be revealing is going through the three steps:

1. Get used to callbacks in NodeJS, for example write some code using fs that reads the content of a file, then provide a callback to print that content.

2. Get used to promises in NodeJS, for example turn the code in #1 into a promise by creating a function with that calls the success/reject handler as appropriate on the callback from opening that file. Then use the promise to open the file and use .then(...) to handle the action.

3. Now do it in async. You have the promise, so you just need to await it and you can inline it.

By doing it in the 3 steps I find it is more clear what is really happening with async/await.

cryptonector• 7 years ago

async/await is all about letting you write serial looking code with the smallest memory footprint short of writing hand-coded continuation passing style (CPS) code.

rammy1234• 7 years ago

Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?

brians• 7 years ago

A possibility to displace C and Java.

Features like Haskell—destructuring bind, useful type system.

Performance like C, including no GC.

monocasa4• 7 years ago

Deterministic memory and object deallocation combined with memory safety, and a vibrant open ecosystem.

pradn• 7 years ago

1) It's built in large part by Mozilla, which enjoys special love as an OSS company. 2) Rust provides tangible benefits (memory/concurrency safety) over existing languages in an important niche (performance-sensitive programs). 3) The community is nice and talented so it's fun to see what they're up to.

ggregoire• 7 years ago

Strong static typing with types inference. Memory allocation manually handled, no garbage collector. C-like performances.

Makes it a good option when reliability and performance matter (think web browser, database or anything at the OS level).

hathawsh5• 7 years ago

Rust is very ambitious and unusually successful at reaching its ambitions. It's efficient like C/C++, but safer. It's modern like Go, but more expressive and open to metaprogramming. It's often as readable as a scripting language, but doesn't depend on garbage collection. It's a young rising star originating from a great company.

hu32• 7 years ago

often as readable as a scripting language

I beg to differ. If anything, Rust is often cited as being hard to read.

exacube• 7 years ago

It's often as readable as a scripting language IMO only if you're using doing simple things the standard library provides utilities for. i haven't found it to be very readable once code grows in complexity, but i'm also not very experienced.

pjmlp5• 7 years ago

Unfortunately Ada isn't as trendy.

So we need Rust for younger generations.

enlyth• 7 years ago

often as readable as a scripting language

Rust code is littered with things like |_|, (|&(&x, _), &mut, &'a and Result<(), Box<dyn std::error::Error + Send + Sync>>.

It's anything but easily readable.

rebotfc• 7 years ago

It can be as fast as C++ whilst at the same time suffering from none of these bugs:

https://www.youtube.com/watch?v=lkgszkPnV8g

jnbiche2• 7 years ago

Rust is the first language basically ever that has a serious chance at displacing C and C++. Combined with a type system that eliminates multiple error classes, and some functional aspects, it's a very interesting language.

topspin• 7 years ago

Anything Rust gets the post to number 1 spot

This is bunk. Simply run this search[1] and behold the stream of Rust related submissions that get no play at all; zero comments and no more than one or two up votes. These instances of highly ranked rust stories are actually the exception; no more than one or two a week typically. The rest of the Rust stuff is seen by almost no one.

[1] https://hn.algolia.com/?query=rust&sort=byDate&prefix&page=1...

jedisct13• 7 years ago

The documentation is great, and the API documentation includes examples for many functions. This is really appreciable. Thank you for that!

Argorak20• 7 years ago

Thank you! :)

mintplant• 7 years ago

How does this relate to Tokio [0]? Why should I choose this new library instead?

[0] https://github.com/tokio-rs/tokio

Arnavion3• 7 years ago

If all you needed from tokio was tokio::net, then async-std could work as a replacement for raw TCP stuff. If you needed the higher-level stuff from tokio like codecs then you'd not have those.

Also, anything from the tokio ecosystem like hyper would not work with async-std.

Edit: I originally had a first paragraph which was wrong. I mistakenly thought std::net::TcpListener is supposed to impl Read / Write.

Argorak20• 7 years ago

async-std has the equivalent of std::net::TcpListener, however it does not appear to actually impl AsyncRead / AsyncWrite. So as of now you can't do anything with it. TcpStream does impl them, at least.

It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc)

The problem is that tokio has their _own_ versions of the AsyncRead and Write traits.

Hyper can best be used with `async_std` through `surf`: https://github.com/rustasync/surf

jedisct13• 7 years ago

Here's an extension trait to convert rust-std streams to tokio streams, so that they work with Hyper https://github.com/jedisct1/rust-async-std-tokio-compat

bfrog• 7 years ago

very cool! Now we need a dpdk equivalent to really blow away expectations people have of what is fast

limsup• 7 years ago

It looks great.

But it's odd that they do not cite Tokio. I know this isn't an academic paper, but come on have some professional curtesy and discuss the contributions made in prior art.

ShinTakuya• 7 years ago

Apologies if I'm misunderstanding things here, I'm just now getting back into Rust after a couple of years of not using it. Did Tokio really inspire this library that much?

rough-sea• 7 years ago

Absolutely. The whole std::future interface has been borne out of years of careful attempts to actually make these abstractions work in real life. async-std didn’t come from a vacuum. It’s a incremental improvement on tokio that benefits from being able to greenfield on top of the newly changed and standardized future trait.

Carl Lerche and the rest of the Tokio contributors deserve a citation.

Async-std: an async port of the Rust standard library

Related Stories