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

141–150 of 238 posts

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

#141

Post by hathawsh »

exacube wrote: post #138
hathawsh wrote: post #81

Earlier quoted context omitted.

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.

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

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

#142

Post by littlestymaar »

guntars wrote: post #56
wahern wrote: post #35

Earlier quoted context omitted.

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.

The async-std is taking the “always red” approach that the article mentions and that wasn’t possible until now due to async being hot of the presses. The rest of the arguments in the article are based on the point that “red functions are more clumsy to call” which doesn’t hold for Rust, but holds for JavaScript.

> but holds for JavaScript.

Held, in 2015 but doesn't any longer since js had async/await.

This blog post isn't really interesting anyways, and its popularity mainly comes from the zealotry of gophers.

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

#143

Post by littlestymaar »

jedisct1 wrote: post #45

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.

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.

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

#144

Post by nimish »

dnautics wrote: post #21
bryanlarsen wrote: post #11

Earlier quoted context omitted.

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…

> 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(f…

Elixir Tasks act closer to a very lightweight threadpool dispatch, rather than the coroutine style of async/await in other languages. An Elixir task doesn't, iirc, share memory with other tasks and won't block if you make it spin.

This makes it a hell of a lot easier to reason about.

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

#145

Post by andrewflnr »

hu3 wrote: post #136
hathawsh wrote: post #81

Earlier quoted context omitted.

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.

> often as readable as a scripting language I beg to differ. If anything, Rust is often cited as being hard to read.

Same here. Rust code tends to be dense. It has its moments, but I wouldn't compare it to a scripting language.

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

#146

Post by rebotfc »

rammy1234 wrote: post #58

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

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

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

#147

Post by 2bitencryption »

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…

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.

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

#148

Post by steveklabnik »

andrewflnr wrote: post #145
hu3 wrote: post #136

Earlier quoted context omitted.

> often as readable as a scripting language I beg to differ. If anything, Rust is often cited as being hard to read.

Same here. Rust code tends to be dense. It has its moments, but I wouldn't compare it to a scripting language.

I'm sitting in a Rust talk at a conference right now, and the speaker has slides comparing the syntax to Ruby/TypeScript/Python. "You already basically know Rust"

A lot of the fancier stuff is very different, but there's fairly close parallels to most of the basic syntax.

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

#149

Post by abstractbarista »

zamadatix wrote: post #72
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…

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

This really helped my practical understanding - Thanks!

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

#150

Post by guntars »

littlestymaar wrote: post #142
guntars wrote: post #56

Earlier quoted context omitted.

The async-std is taking the “always red” approach that the article mentions and that wasn’t possible until now due to async being hot of the presses. The rest of the arguments in the article are based on the point that “red functions are more clumsy to call” which doesn’t hold for Rust, but holds for JavaScript.

> but holds for JavaScript. Held, in 2015 but doesn't any longer since js had async/await. This blog post isn't really interesting anyways, and its popularity mainly comes from the zealotry of gophers.

Nope, it still holds. It’s in fact impossible to call an async function from a sync function and return the result. To use await you have to make the function async which means the caller needs to be async-aware and so on, all the way to the top of the stack.

There are hacks like “deasync”, but I personally wouldn’t use it.

https://github.com/abbr/deasync

Rust can block on an individual future so, say, a sync callback can still take advantage of async functions.

Post reply on HN