Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

async.rs

Post reply on HN
Print view View original

181–190 of 238 posts

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

#181

Post by [deleted] »

hathawsh wrote: post #141
exacube wrote: post #138

Earlier quoted context omitted.

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

I agree that libraries have a major impact on the perceived readability of a programming language. As an example, it used to be quite messy to issue HTTP requests from Python, but then the Requests library appeared, and suddenly it became much easier to write readable client libraries. Rust code will become more readable as its libraries mature.

[deleted]

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

#182

Post by z3t4 »

cheez wrote: post #109
2bitencryption wrote: post #46

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…

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 com…

    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.

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

#183

Post by MrBuddyCasino »

noncoml wrote: post #124
nullwasamistake wrote: post #102

Earlier quoted context omitted.

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,0…

Why only 1000 threads? Why not 10k or 100k? With 8k stack for each, you can easy have 10k-100k threads in a low-end system

Let's be real here, its not just the memory requirements, because context switching and the associated nuking of cpu caches are not free. You can go very far with it nowadays, but you can go much farther with async code, if you really need to.

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

#184

Post by MrBuddyCasino »

Jayschwa wrote: post #14
Un1corn wrote: post #5

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

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

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?

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

#185

Post by topspin »

rammy1234 wrote: post #58

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

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

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

#186

Post by MusharibSajid »

2bitencryption wrote: post #46

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…

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.

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

#187

Post by bpye »

Argorak wrote: post #178
bpye wrote: post #154

Earlier quoted context omitted.

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 t…

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.

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.

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

#188

Post by pjmlp »

lenkite wrote: post #169
2bitencryption wrote: post #147

Earlier quoted context omitted.

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.

Yes, the idea is that the thread that is executing this piece of code can "steal" other work when it is awaiting on either of those methods. Frankly, in the case of sequential flow like the above, I would rather write result = server.getStuff() second = server.getMoreStuff(result+1) print(result) and have the runtime automatically perform work-stealing for me. No need for awaits. They just litter the code. This is wh…

Thus the FFI impact on Go when going over language boundary and workarounds like runtime.LockThread().

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

#189

Post by pjmlp »

rubber_duck wrote: post #79
jeremyjh wrote: post #51

Earlier quoted context omitted.

> 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 m…

Green threads have no place in a low level systems language like Rust whose design goals are zero cost abstraction and trivial C interop. D made a similar mistake by requiring GC/runtime from start and now even though they added ways to avoid it the ecosystem and the language design are "poisoned" by it an itmakeas it a very hard sell in some places where it could be sold as a C++ successor. Because rust made the rig…

Many systems have been developed in systems enabled GC languages.

C++11 introduced a GC API in the standard library, and one of the biggest C++ game engine does use GC in their engine objects, Unreal.

C++ on Windows makes heavy use of reference counting (which is a GC algorithm from CS point of view), via COM/UWP.

The biggest problem to overcome is religious, not technical.

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

#190

Post by pjmlp »

hathawsh wrote: post #81
rammy1234 wrote: post #58

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

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.

Unfortunately Ada isn't as trendy.

So we need Rust for younger generations.

Post reply on HN