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

Re:Async-std: an async port of the Rust standard library by davidhyde on Friday August 16, 2019 @04:35PM (#20719455)

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.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Friday August 16, 2019 @05:24PM (#20719858)

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.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by thethirdone on Friday August 16, 2019 @06:03PM (#20720149)

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.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Friday August 16, 2019 @06:31PM (#20720336)

I'm pretty sure that once you don't want `std`, you also want to pick your own scheduler. In this case, you can use the base library (`async-task`) and get started.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by jeremyjh on Friday August 16, 2019 @06:11PM (#20720207)

The benefit would be you would be making it impossible to wreck your scheduler by calling sync I/O functions in an async task.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Friday August 16, 2019 @06:30PM (#20720328)

I wouldn't rely on that. Next step, someone binds to a blocking database driver and you are back at square 1 again. This is definitely not rigorous.

I would love to see a lint for known-blocking constructs in async contexts, though: https://github.com/rust-lang/rust-clippy/issues/4377

Also, having explicit imports and types that name collide helps there for once.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by jeremyjh on Friday August 16, 2019 @06:45PM (#20720440)

How would you have a blocking database library that doesn't use the standard library?

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Friday August 16, 2019 @07:51PM (#20720805)

Any code in Rust is free to bind to FFI and sockets can be gained through `libc`.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by jeremyjh on Friday August 16, 2019 @08:02PM (#20720861)

I didn't literally mean "How is that possible?"

I meant: is that a real thing? Is there a database binding out on crates.io that uses no_std ?

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by pcwalton on Saturday August 17, 2019 @12:07AM (#20721959)

SQLite is C code and any Rust usage of it will not play nicely with M:N. This is just off the top of my head. I'm sure there are plenty of other examples.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Saturday August 17, 2019 @02:09AM (#20722443)

Yes. E.g. some databases highly recommend using their C library, as they don't consider their protocol specified.

That gap might close, but it will stay with us for years.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by khuey on Friday August 16, 2019 @07:57PM (#20720835)

unsafe

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by davidhyde on Friday August 16, 2019 @05:54PM (#20720089)

> It exports stdlib types (like io::Error)

Excellent, good to know!

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by bpye on Friday August 16, 2019 @11:03PM (#20721706)

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.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by Argorak on Saturday August 17, 2019 @02:11AM (#20722457)

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.

[ Parent | on HN ]

Re:Async-std: an async port of the Rust standard library by bpye on Saturday August 17, 2019 @04:54AM (#20722949)

I certainly understand, and alloc for example is great progress. I'll be very happy when we can provide all of std (or I suppose sys isn't it?) by external crates.

[ Parent | on HN ]