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

Why asynchronous Rust doesn't work

theta.eu.org

Post reply on HN
Print view View original

241–250 of 499 posts

Re: Why asynchronous Rust doesn't work

#241

Post by orf »

lmm wrote: post #140
adamch wrote: post #128

Earlier quoted context omitted.

You can't abstract over it in the same way that you can in Haskell, because you have to manage ownership. You can't abstract away ownership as easily, because the language is designed to make you care about ownership. I write Rust code for my day job, and I frequently use map/reduce/filter. IMO if I can write all my collection-processing code using primitives like that, it's got first-class functions.

It's not about "abstracting away" ownership, it's about being polymorphic over it. I want to keep the distinction between Fn, FnOnce, and FnMut. But I want to be able to write a `compose` function that works on all three, returning the correct type in each case. That's not taking away from my ability to manage ownership, it's letting me abstract over it.

You could do the polymorphic return with an enumeration. But those are distinct types with very different semantics: you can’t just say “it returns a function that you can call once or maybe a function you can call more than once. Shrug”.

Re: Why asynchronous Rust doesn't work

#242

Post by amelius »

zamalek wrote: post #193
newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

> A bigger problem in my opinion is that Rust has chosen to follow the poll-based model This is an inaccurate simplification that, admittedly, their own literature has perpetuated. Rust uses informed polling: the resource can wake the scheduler at any time and tell it to poll. When this occurs it is virtually identical to completion-based async (sans some small implementation details). What informed polling brings to…

> the resource can wake the scheduler at any time and tell it to poll

Isn't that called interrupting?

The terminology seems a little off here, but perhaps that is only my perception.

Re: Why asynchronous Rust doesn't work

#243

Post by pron »

hctaw wrote: post #26

I don't think any of this is actually a reason why async rust doesn't work. The function color problem is a bit overblown, it hasn't broken nodejs yet either. Most code is sync, sync can call async and vice versa, and the ecosystem hasn't come tumbling down yet (since most Rust isn't whichever async application runtime for web apps is currently in vogue - its a systems language after all). Either way there are bigger…

The issue is much more general. I also don't see a particular problem with Rust here, but I do see with Rust the same false hope I saw in the late eighties and early nineties with C++ (hell, I fell victim to it myself back then): the belief that with enough features, cleverness, and language complexity we could have the cake and eat it too -- have all the control of a low-level language with the same productivity as a high-level language. Low-level languages, whether they try to appear as high-level ones on the page or not, all suffer from low-abstraction, i.e. the inability to hide internal implementation details behind an API and isolate them from consumers. This makes changing implementation details hard and the program much more rigid, and so increases maintenance cost. The problems with C++ weren't apparent at first, because writing the program the first time is as easy as with a high-level language; the problems start when you change the program over the years. There is no doubt Rust cleans up C++ and solves some particular problems with it, but it doesn't solve this fundamental problem.

There are many situations where a low-level language and the control it affords are absolutely necessary, but low-level programmers are aware of the non-negligible price they pay.

Re: Why asynchronous Rust doesn't work

#244

Post by ha_jo_331 »

thu2111 wrote: post #223
xiphias2 wrote: post #36

Earlier quoted context omitted.

That’s why it’s amazing, type safe efficient multi-threading without dynamic memory allocation with a nice syntax...it’s the holy grail of server programming.

Why would I want to write a server in a language that requires such awkward approaches to basics like coroutines and dynamic dispatch when I could use kotlin on the JVM and get pauseless GC, ultra fast edit/compile/run cycles, efficient and powerful coroutines, and eventually Loom which will eliminate the whole problem of coloured functions completely and let me just forget about coroutines? Multi threading bugs are…

Or even better: Go

Re: Why asynchronous Rust doesn't work

#245

Post by richardwhiuk »

imtringued wrote: post #216
valand wrote: post #184

Earlier quoted context omitted.

` fn do_work_and_then(func: fn(i32)) { thread::spawn(move || { // Figuring out the meaning of life... thread::sleep_ms(1000); // gee, this takes time to do... // ah, that's it! let result: i32 = 42; // let's call the `func` and tell it the good news... func(result) }); } ` you missed a snippet, a thread is spawned. edit: formatting

If for some magic reason thread::sleep_ms(1000) takes longer than 2000ms the main function would reach its end and deallocate the closure that is about to get called. Basically use after free.

And that's possible, because the sleep call is a suggestion, not a guarantee. If the CPU is blocked for 2s, then the order of waking the threads is undetermined, and the race will occur.

Re: Why asynchronous Rust doesn't work

#246

Post by mratsim »

newpavlov wrote: post #173
zelly wrote: post #167

Earlier quoted context omitted.

Why did polling have to be baked into the language? Seems bizarre for a supposedly portable language to assume the functionality of an OS feature which could change in the future. 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. Rust also didn't solve the colored functions problem. Most people think that's an impossible prob…

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

It requires allocation if the coroutine outlives the scope that created it.

Otherwise compiler are free to implement heap allocation elision (which is done in Clang).

Now compared to Rust, assuming you have a series of coroutines to process a deferred event, Rust will allocate once for the whole series while C++ would allocate once per coroutine to store them in the reactor/proactor.

Re: Why asynchronous Rust doesn't work

#247

Post by amelius »

varajelle wrote: post #176

Can we please stop using this "color" argument to Rust? The original colouring article was about JavaScript, a dynamically typed language. But rust is a statically typed language, and in a sense, the type is the colour. You can't return an error from a function that does not return a Result . And most people agree it is a great thing over dynamic/implicit exceptions. Declaring a function just changes the return type…

The only thing a type-system brings to the table in this matter is an error at compile time if you used the wrong color.

It won't solve the color problem.

Re: Why asynchronous Rust doesn't work

#248

Post by gher-shyu3i »

bullen wrote: post #195
gher-shyu3i wrote: post #187

Earlier quoted context omitted.

Why Java 8 as opposed to the latest JDK? And what about C#? It's in a similar boat as Java. Also, how is the Java memory model different from Go for this use case? They both allow mutation by sharing.

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 Parallelism!

What do you mean by Joint Parallelism? I didn't find relevant resources. And is it bound to having a VM?

Re: Why asynchronous Rust doesn't work

#249

Post by gohbgl »

xiphias2 wrote: post #6

As I read through the database example, I saw that the compiler just caught a multi-threading bug for the author, and instead of being thankful, he’s complaining that Rust is bad. I think he should use a higher level framework, or wait a few years for them to mature, and use a garbage collected language until then.

What is the bug? I don't see it.

Re: Why asynchronous Rust doesn't work

#250

Post by ha_jo_331 »

Of course a fiber/green threads based solution would be easier to use, but Rust is supposed to provide zero cost abstractions for concurrency: Maximum performance and efficiency (and safety) coming first, usability second. THat is perfectly fine.

Whereas others (Go for example) sacrifice some efficiency and performance to ergonomics.

Post reply on HN