61–70 of 238 posts
Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?
Features like Haskell—destructuring bind, useful type system.
Performance like C, including no GC.
Earlier quoted context omitted.
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.
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.
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…
> 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…
Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?
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…
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?
Earlier quoted context omitted.
> 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.
Spawning a new thread for an operation is not async in the sense people typically mean. For an async IO library, you would expect it to be using async IO primitives like epoll, not just wrapping blocking operations in a thread.
Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?
Earlier quoted context omitted.
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.
Cooperative multitasking, like it's 1995 again? No thanks.
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.
Arguing that the problem doesn't exist if you only stick to functions of a single color isn't a rebuttal, it's an admission! But the fact of the matter is async functions have real limitations and costs, which is why they're not the default in Rust, which in turn is why any Rust program will always have some mix of differently colored functions. But, yeah, the fewer of one color and the more of the other color, the better. That's the point.
Earlier quoted context omitted.
io_uring grew support for buffered IO in recent kernels, so we should have widespread support for this in userspace circa 2025
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.