Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#251

Post by jedisct1 » Wed, Mar 10, 2021, 11:58 AM UTC

If Rust had to be rewritten from scratch today, it would probably be done differently, learning from experience since it was invented.

Cargo, macros, const generics and `#[cfg]` wouldn’t exist any more, replaced with comptime evaluation.

The standard library would be half its current size (considering its redundant functions, deprecated functions, or constructions that Clippy wants to be replaced with other constructions).

IDE integration would be considered immediately.

Per-function allocators wouldn’t be an afterthought (the current proposal is really bad, but it’s too late to do something better).

And async would be part of the language and the standard library, “colorless” and completion-based.

The problem is that it’s too late. The Rust language itself is mature, and cannot afford major breaking changes any more. So, improvements can only be made on top of what’s already there, limiting their integration, and making the whole thing more and more bloated and complicated.

Re: Why asynchronous Rust doesn't work

#252

Post by jevgeni » Wed, Mar 10, 2021, 11:58 AM UTC

roca wrote: post #224

sai_c wrote: post #148

Earlier quoted context omitted.

Disclaimer: I've only dabbled in Rust from time to time, but have not written anything serious with it. Those kind of comments are not based on looking at Rust's features on a theoretical level. It's more from the viewpoint of "How hard is it to get something (correctly) done". Those impressions are mostly formed either from using the language and failing (or having severe difficulties) to solve a given problem, or b…

It is hard to stop people perceiving Rust as over-complex if they are motivated to perceive it as over-complex.

I think the problem here is that Rust exposes a lot of additional problems in a domain that are swept under the rug in other languages. I mean, those problems have always existed, it's just we are used to hoping or assuming that the generic solution within a language runtime will save us from them.

Re: Why asynchronous Rust doesn't work

#253

Post by navaati » Wed, Mar 10, 2021, 12:00 PM UTC

jedisct1 wrote: post #251

If Rust had to be rewritten from scratch today, it would probably be done differently, learning from experience since it was invented. Cargo, macros, const generics and `#[cfg]` wouldn’t exist any more, replaced with comptime evaluation. The standard library would be half its current size (considering its redundant functions, deprecated functions, or constructions that Clippy wants to be replaced with other construct…

> [async] “colorless”

I’m super interested that you think that’s something that can exist, how would it work, what would it look like in your mind ?

Re: Why asynchronous Rust doesn't work

#254

Post by amelius » Wed, Mar 10, 2021, 12:00 PM UTC

ironmagma wrote: post #89

gsserge wrote: post #57

I like to joke that the best way to encounter the ugliest parts of Rust is to implement an HTTP router. Hours and days of boxing and pinning, Futures transformations, no async fn in traits, closures not being real first class citizens, T: Send + Sync + 'static, etc. I call this The Dispatch Tax. Because any time you want more flexibility than the preferred static dispatch via generics can give you - oh, so you just w…

In a systems context, where performance and memory ostensibly matter, why wouldn’t you want to be made aware of those inefficiencies? Sure, Go hides all that, but as a result it’s also possible to have memory leaks and spend extra time/memory on dynamic dispatch without being (fully) aware of it.

> In a systems context, where performance and memory ostensibly matter, why wouldn’t you want to be made aware of those inefficiencies?

Perhaps, but a bigger problem is that lots of folks are using Rust in a non-systems context (see HN frontpage on any random day).

Re: Why asynchronous Rust doesn't work

#255

Post by bullen » Wed, Mar 10, 2021, 12:00 PM UTC

gher-shyu3i wrote: post #248

bullen wrote: post #195

Earlier quoted context omitted.

Java 8 is the last free Oracle JDK, nothing added after 8 is really interesting enough to take the complexity hit that Java 9/10/11 etc. mean. I'm waiting for user space network, that is the last feature that will make the switch worth: my system uses almost as much kernel copy CPU as my user space process!!! C# is an ok alternative but they went for value types instead of sticking to the VM. Java has atleast 10 year…

> Java 8 is the last free Oracle JDK, nothing added after 8 is really interesting enough to take the complexity hit that Java 9/10/11 etc. mean. The low latency GCs and the general performance improvements seem quite good though. > C# is an ok alternative but they went for value types Java is also getting value types (project Valhalla). > Go has no VM but uses GC, thay miss half of the requirements to make Joint Para…

Well, there was a real-time thing bought by Sun from Sweden but I'm still unclear as to how much of that has made it into the open-source part of the JDK. Time will tell!

Joint Parallelism is a term that I invented, it means loosely defined: if two threads can read and write to the same memory at the same time without it causing too much loss... basically you need atomic concurrency which is only really efficient on a complex memory model VM with GC if you want high level language support:

"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html

"Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-co...

I'm not an expert, I can't explain why these things are true, because I'm trying to make something useful on top of C/Java instead of going too deep.

But what I do know is that my app. server kicks everythings ass to the stone age in terms of performance and ease of use: https://github.com/tinspin/rupy

It's facinating to see humans struggle with the wrong tools, and defending those same tools without even trying the alternatives (I have also worked with perl, PHP and C# so I know why those are bad).

But I'm sure time will flush the bad apples out eventually, specially when electricity prices go up.

Re: Why asynchronous Rust doesn't work

#256

Post by _pfxa » Wed, Mar 10, 2021, 12:00 PM UTC

ironmagma wrote: post #8

> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…

> It’s a systems language, not a functional language for describing algorithms in CS whitepapers.

This kind of toxicity is why I left programming behind as a career.

Re: Why asynchronous Rust doesn't work

#257

Post by pjmlp » Wed, Mar 10, 2021, 12:02 PM UTC

As I already mentioned multiple times, the future are tracing GCs with an ownership concept for niche use cases.

Rust's ideal use case are the scenarios that use stuff like MISRA-C, kernel and drivers code.

The design team has done a wonderful work pushing for affine types into mainstream, however outside of forbidden-GC scenarios, the productivity loss versus any kind of automatic memory management approach, isn't worth it.

Re: Why asynchronous Rust doesn't work

#258

Post by akvadrako » Wed, Mar 10, 2021, 12:03 PM UTC

int_19h wrote: post #168

akvadrako wrote: post #157

Earlier quoted context omitted.

The problems are (1) either you write two versions of almost every function or you can only support one use case (sync or async). If you could write generic functions which work in both cases it would be better. (2) it creates a lot of noise writing async/await. It's like if we had to always write x = call f() in the sync case.

If you write your functions as async, it's trivial to make a sync wrapper out of it.

If you feel like wrapping every function call.

Re: Why asynchronous Rust doesn't work

#259

Post by newpavlov » Wed, Mar 10, 2021, 12:03 PM UTC

the_mitsuhiko wrote: post #210

newpavlov wrote: post #152

Earlier quoted context omitted.

>There's a difference between "we decided this 3 years ago" and "we rushed the decision". As far as I understand the situation, the completion-based API simply was not on the table 3 years ago. io-uring was not a thing and there was a negligible interest in properly supporting IOCP. So when a viable alternative has appeared right before stabilization of the developed epoll-centric API, the 3 year old decision has not…

> As far as I understand the situation, the completion-based API simply was not on the table 3 years ago Completion APIs were always considered. They are just significantly harder for Rust to support.

Can you provide any public sources for that? From that I've seen Rust async story was always developed primarily around epoll.

Re: Why asynchronous Rust doesn't work

#260

Post by saurik » Wed, Mar 10, 2021, 12:08 PM UTC

zelly wrote: post #178

newpavlov wrote: post #173

Earlier quoted context omitted.

>Why did polling have to be baked into the language? See this comment: https://news.ycombinator.com/item?id=26407440 >Meanwhile C and C++ can easily adopt any async system call style because it made no assumptions in the standards about how that would be done. Do you know about co_await in C++20? AFAIK (I only have a very cursory knowledge about it, so I may be wrong) it also makes some trade-offs, e.g. it requires a…

C++20 coroutines are not async in the standard. They are just coroutines. Actually they have no implementation. The user has to write classes to implement the promise type and the awaitable type. You could just as easily write a coroutine library wrapping epoll as you could io_uring. The only thing it does behind your back (other than compile to stackless coroutines) is allocate memory, which also goes for a lot of o…

Is this not also true of Rust? Are you saying Rust in some sense hardcodes an implementation to await in a way C++ doesn't? (I am not a Rust programmer, but I am very very curious about this and would appreciate any insight; I do program in C++ with co_await daily, with my own promise/task classes.)