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

Why you might want async in your project

notgull.net

Post reply on HN
Print view View original

121–130 of 182 posts

Re: Why you might want async in your project

#121

Post by zozbot234 »

rendaw wrote: post #119
klabb3 wrote: post #87

I mean.. I appreciate that there are proponents and people trying to improve the state of async rust but to allude that everything is dandy is either dishonest or more likely a strong curse of knowledge bias. I’ve worked deeply in an async rust codebase at a FAANG company. The vast majority chooses a dialect of async Rust which involves arcs, mutices, boxing etc everywhere, not to mention the giant dep tree of crates…

I generally agree, but specific to your point about arcs/mutexes - what would be the alternative for shared mutable data? Or do you mean people use it for stuff that isn't shared too?

> what would be the alternative for shared mutable data?

You can use atomics if the data fits in a machine word. That's a lot faster than a full mutex.

Re: Why you might want async in your project

#122

Post by hgomersall »

vc8f6vVV wrote: post #118
hgomersall wrote: post #66

Earlier quoted context omitted.

Your answer boils down to: "I know this technique, I don't want to learn blub technique. My job is to get stuff done, not learn new techniques." In which case, good for you; enjoy your sync code (seriously), and please stop telling the rest of us that have learnt the new blub technique that we shouldn't use it.

Nope, my answer boils down to: "I said I never had much use for one. Never said I didn't know how to use it." (c)

Honestly, your dismissal of its value sounds very much like you don't know how to use it. The whole argument can be turned around and the same said about threads, which are not "simple" as you suggest if you don't already know how to use them. You might as well say "simple async".

Re: Why you might want async in your project

#123

Post by mborch »

atoav wrote: post #106
insanitybit wrote: post #101

Earlier quoted context omitted.

> The vast majority chooses a dialect of async Rust which involves arcs, mutices, boxing etc everywhere And? > not to mention the giant dep tree of crates to do even menial things. Again, And ? I don't really care about having to pull in crates. That has always been how Rust does things - it prefers many small crates over fewer large crates. Async is no different. And I don't care about Arc either. Writing `let x = b…

I am of the same impression — Rust as a language forces you to come at terms with your own ideas of how code should look. That being said I still have a deep dislike of having to read through nested Arc Mutexes or whatever to figure out what the code does in principle before I figure out what is going on in detail with the ownership. I know there are no perfect solutions and there are trade-offs to be made, but I wis…

Looks like you're asking for syntax sugaring for T::new wrapping, e.g. `"bar" |> Something |> Arc |> Mutex`.

Re: Why you might want async in your project

#124

Post by eternityforest »

Nullabillity wrote: post #83
im3w1l wrote: post #74

Earlier quoted context omitted.

Are you saying that a finalizer is guaranteed to run when the last reference is deleted? So you could actually rely on them to handle the resources, as long as you are careful not to use reference cycles?

In CPython 2.7, yes. In CPython in general, I believe it's currently still the case, but I don't think it's guaranteed for future versions. For Python in general, no. For example, as far as I know Jython reuses the JVM's GC (and its unreliable finalizers with it). It's also easy to introduce accidental cycles. For one, a traceback includes a reference to every frame on the call stack, so storing that somewhere on the…

The tracebacks were a lot of what made me cut back on using weakrefs and trying to make things manage their resources automatically.

Now I use close() methods for anything that needs to be closed. If I mess up and there's some obscure bug, hopefully GC will fix it, but it seems too brittle and easy to make mistakes with to rely on.

Re: Why you might want async in your project

#125

Post by eternityforest »

mplanchard wrote: post #31
eternityforest wrote: post #24

Earlier quoted context omitted.

Python handles all kinds of stuff with garbage collection. The problem is that things like closing a socket are not just generic resources, a lot of the time nonmemory stuff has to be closed at a certain point in the program, for correctness, and you can't just let GC get to it whenever.

I don’t think this is true. Context managers call special magic “dunder” methods on the instance (I don’t remember the specific ones), and I’m pretty sure those don’t get called during regular garbage collection of those instances. It’s been a few years since I was regularly writing python, so I might be wrong, but I don’t believe that context manager friendly instances are the same as Rust’s Drop trait, and I don’t…

with: does in fact use different dunder methods, but __del__ allows one to do GC-based cleanup if one wishes.

Re: Why you might want async in your project

#127

Post by cies »

za3faran wrote: post #95
cies wrote: post #84

Earlier quoted context omitted.

> underappreciated widely used though. not sure if that count for appreciation, but i think it's one of the highest forms. it's not bad, not not great either. i miss proper sum types, and it really lament the fact that static things are nearly impossible to be mocked which prompts everyone to use DI for everything instead of static.

Java has sum types now with sealed interfaces and pattern matching. Records have detructoring out of the box, and I believe supporting it for general classes is in the works.

I think sealed interfaces it not quite the same as "tagged unions"-style enum's with payloads.

Also, it does not matter much anymore, the whole std-lib is full of exceptions-to-implement-multiple-return-values.

Re: Why you might want async in your project

#128

Post by nmlt »

olalonde wrote: post #117
insanitybit wrote: post #110

Earlier quoted context omitted.

A Runtime generally refers to "things added to the program to make it work". That can mean libc, it can mean a GC, etc. > I don't understand the arguments on either side. In terms of what code looks like I far prefer being able to just declare green threads like golang does. Under the hood `async` is sugar over a function such that the function returns a `Future ` instead of a `T`. What is done with that future is up…

> That's fine - lots of Rust libraries that work the way you're suggesting will just assume a runtime exists. Is this a new development? Last time I checked, every library seemed to be tied to a specific runtime (usually tokio).

I don’t think that has changed.

Re: Why you might want async in your project

#129

Post by IshKebab »

conradludgate wrote: post #90
IshKebab wrote: post #46

> Even the simple, Unix-esque atomic programs can’t help but do two or three things at once. Okay, now you set it up so, instead of waiting on read or accept or whatnot, you register your file descriptors into poll and wait on that, then switching on the result of poll to figure out what you actually want to do. > Eventually, two or three sockets becomes a hundred, or even an unlimited amount. Guess it’s time to brin…

It's necessary to use some kind of poll construction if you want cancellation and timeouts without shutting down the entire application

True but you can still do that using traditional threads using cancellation tokens.

In some ways it's worse because you have to explicitly add them, and I have yet to see any Rust APIs that actually use them (though there is a `cancellation` crate so at least some must be).

In other ways it's better because it gives you control and explicit visibility over the cancellation points.

Re: Why you might want async in your project

#130

Post by imetatroll »

insanitybit wrote: post #110
imetatroll wrote: post #107

Earlier quoted context omitted.

I don't have a degree in CS so I always feel out of my element in these discussions... Is the runtime something the compiler adds to the binary to make sure it is able to correctly interact with the system it is built for? It seems like people argue that green threads require a runtime as if async doesn't? I don't understand the arguments on either side. In terms of what code looks like I far prefer being able to jus…

A Runtime generally refers to "things added to the program to make it work". That can mean libc, it can mean a GC, etc. > I don't understand the arguments on either side. In terms of what code looks like I far prefer being able to just declare green threads like golang does. Under the hood `async` is sugar over a function such that the function returns a `Future ` instead of a `T`. What is done with that future is up…

I don't really understand when you say that spawning async would be just like a green thread (goroutine). I thought they were fundamentally different.
Post reply on HN