Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#261

Post by pjmlp » Sat, Nov 13, 2021, 10:34 PM UTC

tialaramex wrote: post #256

pjmlp wrote: post #220

Earlier quoted context omitted.

You as a user of a crate deemed safe, that underneath uses shmem, mmap, or a database, written without taking the proper care to prevent other processes to change exactly the same underlying data segment, written in what knows what, are in for a surprise and long debugging sessions. The crate public API surface is safe after all, and unless the user has experience in distributed systems, the answer won't come right a…

But this hypothetical "written without taking the proper care" code is buggy. Like I said it's just the same situation as a bad implementation of Index but more convoluted. Rust's standard library takes this very seriously. In many languages if I try to sort() things which refuse to abide by common sense rules like "Having a consistent sort order" the algorithm used may blow up arbitrarily. But Rust's sort() is robus…

Rust's npm like approach to crates and micro approach to standard library make it a real problem, regardless of the quality approach to the standard library.

You would have a point if the standard library was batteries included.

When a language sells safety it has to go all in.

Re: Why asynchronous Rust doesn't work

#262

Post by pjmlp » Sat, Nov 13, 2021, 10:35 PM UTC

scotty79 wrote: post #239

pjmlp wrote: post #157

Earlier quoted context omitted.

Yes, that is how C++/WinRT handles cascading deletion of COM instances, however when you are going down that route, it is basically a poor man's tracing GC.

However it just for the stuff you need it for. It's not all encompassing. It's not mandatory part of the language.

True, and unfortunately a reason why we keep having CVEs related to memory corruption.

Re: Why asynchronous Rust doesn't work

#263

Post by pjmlp » Sat, Nov 13, 2021, 10:38 PM UTC

remram wrote: post #245

pjmlp wrote: post #176

Earlier quoted context omitted.

Move closures assume everything is movable, in C++ you can control what actually takes place, and yes there is the possibility to get it wrong.

Parent is saying that you can declare your closure 'move' and move references rather than values, therefore getting the mixed behavior you described. You don't have to move all values.

If you want to copy in such cases in Rust, you need to copy to dummy variables that are then moved into the closure, a common pattern in Gtk-rs that even deserves a macro to simplify the boilerplate.

Re: Why asynchronous Rust doesn't work

#264

Post by auggierose » Sat, Nov 13, 2021, 10:39 PM UTC

rackjack wrote: post #258

auggierose wrote: post #251

Earlier quoted context omitted.

If you say that "Rust sometimes is guardrails, sometimes it is handcuffs, sometimes it is a rollercoaster", that is already a lot of information. That's exactly what I want to avoid when implementing a concept: I don't want to be dependent on how well the type system fits my concept, because I am dealing with all sorts of concepts.

Ok. Sometimes Rust fits good, sometimes it fits bad. If you don't want to deal with that, that's fine. I don't want to deal with memory leaks and stuff, so I use Rust instead of C/C++ when low-level, and I deal with the bad fits. I'd still recommend learning Rust though. I find the way (the clean ways, not the ugly ways like Weak/Cell/etc.) it forces you to structure your programs is a very useful pattern when dealin…

I am working mostly in Swift these days, and some Metal C for GPU and GPGPU. If Swift and SwiftUI both also ran in the browser, that would meet my needs.

I need to break out of that Apple silo though for an important project of mine, so I am looking for alternatives. I was looking at zig, too! It seems very promising, and comptime seems like a great idea. I am considering both Rust and Zig for generating libraries in WebAssembly.

I think I will mostly go with TypeScript for my project, it seems undogmatic and highly productive, and Turbo Pascal was my second language after Quick Basic, so I like its origins :-)

Re: Why asynchronous Rust doesn't work

#265

Post by pjmlp » Sat, Nov 13, 2021, 10:53 PM UTC

scotty79 wrote: post #237

sweeneyrod wrote: post #202

Earlier quoted context omitted.

You can get those cool features in languages such as OCaml/F#/Scala/Haskell, and then you don't have to worry about managing memory because you have a GC.

Sure but all of them are weird. Rust is something you can pick up in an afternoon if you have expeirience in C++-like languages.

From the point of view of somehow that has taught C++ as TA, worked with C and C++ during several years in some heavy contexts, an afternoon won't do it.

Re: Why asynchronous Rust doesn't work

#266

Post by dnautics » Sat, Nov 13, 2021, 10:58 PM UTC

pcwalton wrote: post #229

dnautics wrote: post #215

Earlier quoted context omitted.

I'm holding out for formal-methods based static analysis on lifetimes in zig.

Not possible for the same reasons why just adding a borrow checker to C++ isn't possible. Mostly this comes down to incompatibility with existing code. Zig is just not memory safe, and the only solution would be to add a GC.

This is a very bad take. By your argument there's no reason why sel3 should exist, which is written in C and safer than rust.

Re: Why asynchronous Rust doesn't work

#267

Post by pjmlp » Sat, Nov 13, 2021, 11:01 PM UTC

NoraCodes wrote: post #133

jmull wrote: post #124

Earlier quoted context omitted.

> I see this article as not understanding the goals and tradeoffs of Rust. The author would be happier writing in a higher-level language than Rust. That's a pointless conclusion. The author's criticisms of Rust's tradeoffs are invalid because those are the tradeoffs Rust made. A perfect circle!

That would be circular, but that's not what the parent is saying. Rather, eta's post has one central point - she even bolds it for us: > Rust is not a language where first-class functions are ergonomic. And this... I mean, I don't agree with her, but that might be because I've been immersed in Rust for half a decade. But Rust's tradeoffs are based around four things. It is a: - performant - reliable (incl. memory saf…

> "Systems programming language" means no garbage collector

An opinion not shared by Xerox PARC folks, ETHZ or Microsoft Research.

Re: Why asynchronous Rust doesn't work

#268

Post by tptacek » Sat, Nov 13, 2021, 11:03 PM UTC

hitekker wrote: post #244

tptacek wrote: post #165

Earlier quoted context omitted.

Is that provoked by the author of this post, or just a random commenter on the thread that post spawned? It looks like the latter.

I’d say both. The author of the post called Rust async/await a disaster, and the top commenter, who withoutboats replied to, agreed with the author’s criticism.

I don't think the author of a blog post is accountable in any way for the most inflammatory thing somebody that agrees with them says.

Re: Why asynchronous Rust doesn't work

#269

Post by jdub » Sat, Nov 13, 2021, 11:16 PM UTC

auggierose wrote: post #123

jdub wrote: post #102

Earlier quoted context omitted.

Nah, you're really not. Most of the time, particularly if you're not writing libraries, Rust feels like a dialect of Python that wants to help you get things right.

Well, 90% of what I am doing is writing libraries. I know how to get things right. Does Rust?

"I know how to get things right."

Ah, you're one of those people. Sure. :-)

Re: Why asynchronous Rust doesn't work

#270

Post by secondcoming » Sat, Nov 13, 2021, 11:20 PM UTC

__s wrote: post #187

secondcoming wrote: post #74

There are constant efforts to make async easier in all languages. It'll never be as easy as writing synchronous code. I really don't like futures/promises, I don't know where this abstraction came from. Callbacks are where it's at. Someone, somewhere has to write callback code; they cannot be got rid of. What works for me is keeping the callback handler as short as possible, this usually means just pushing 'work' ont…

I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's per…

> the caller fires it off without a ticket to wait on the result

Exactly! Making a thread block waiting for a result isn't true async in my book. It doesn't matter that the result is going to come from another thread. Futures/Promises make you block a thread.