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

81–90 of 182 posts

Re: Why you might want async in your project

#81

Post by moregrist »

meindnoch wrote: post #16
codeflo wrote: post #8

Earlier quoted context omitted.

I agree that memory management can't be solved locally. The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that. I disagree that this criticism applies to Rust. For 99% of the cases, the idiomatic combination of borrow checking, Box and Arc gets back to a unified, gl…

>The situation in C++, where every library or API you use has a different cleanup convention, that you need to carefully read about in the documentation to even properly review a pull request, is proof of that. Lol wut. The C++ resource management paradigm is RAII. If you write a library that doesn't use RAII, it's a bad library. Not a fault of the language.

There’s a lot of C++ code out there and a lot that interfaces with C.

RAII is one method of cleanup but it doesn’t work in all situations. One that comes to mind is detecting errors in cleanup and passing them to the caller.

So it’s not right to call every library that doesn’t use RAII “bad.” There are other constraints, as well. Part of the strength of C++ is to give you a choice of paradigms.

Re: Why you might want async in your project

#82

Post by delusional »

Arnavion wrote: post #72
delusional wrote: post #65

The author starts by citing greenspun's tenth rule and goes on to elaborate on the argument that if you are going to have a half implementation of async anyway, why not just pull it in? Yet fails to interrogate the relationship between this argument and the cited "rule". If you should use async because you might need it in the future, shouldn't we all be writing in lisp? If we presuppose that all software eventually…

The author said what you wrote in the first sentence, ie "use async if you are going to have a half implementation of async anyway". "Use async because you might need it in the future" is something you made up, not what the author said.

greenspun's tenth rule is about the inevitability of the half baked implementation of lisp. By evoking the sentiment of the rule the author is implicitly making the argument that all "sufficiently complicated programs" will eventually contain a half baked implementation of async.

The implicit argument doesn't stand alone though. The author goes on to write:

> It happens like this: programs are naturally complicated. 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.

The implication is clear. Even simple programs will eventually require async, and should therefore just use it right now. unix-esque in this paragraph is supposed to evoke ls or cat. Is your program really going to be simpler than cat? No? Then you apparently need async.

Re: Why you might want async in your project

#83

Post by Nullabillity »

im3w1l wrote: post #74
Nullabillity wrote: post #57

Earlier quoted context omitted.

Python is a fun case of "all of the above" (or rather, a layering of styles once it turns out a previous one isn't workable). Originally, they used pure reference counting GC, with finalizers used to clean up when freed. This was "fine", since RC is deterministic. Everything is freed when the last reference is deleted, nice and simple. But reference counting can't detect reference cycles, so eventually they added a s…

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 stack would create an unintentional cycle!

Re: Why you might want async in your project

#84

Post by cies »

fnord77 wrote: post #6
PaulHoule wrote: post #2

I find async is so much fun in Python and meshes with the other things you can do with generators but that is because I have the reference collector cleaning up behind me. Looking back with like 30 years of hindsight it seems to me that Java’s greatest contribution to software reuse was efficient garbage collection; memory allocation is a global property of an application that can’t efficiently be localized as you mi…

the JVM is an underappreciated engineering marvel

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

Re: Why you might want async in your project

#85

Post by __MatrixMan__ »

vc8f6vVV wrote: post #58

> Why don’t people like async? That's pretty simple. The primary goal of every software engineer is (or at least should be) ... no, not to learn a new cool technology, but to get the shit done. There are cases where async might be beneficial, but those cases are few and far in between. In all other cases a simple thread model, or even a single thread works just fine without incurring extra mental overhead. As profess…

Another reason to is that it lets you handle bursty input with bursty CPU usage. Sounds great, right? Round peg, round hole.

But nobody will sell you just a CPU cycle. They come in bundles of varying size.

I recently heard a successful argument that we should take the pod that's 99% unutilized and double its CPU capacity so it can be 99.9% unutilized, that way we don't get paged when the data size spikes.

When I proposed we flatten those spikes since they're only 100ms wide it was sort down because "implementing a queueing architecture" wasn't worth the developer time.

I suppose you could call it a queueing architecture. I'd call it a for loop.

Re: Why you might want async in your project

#86

Post by cies »

fnord77 wrote: post #4
airstrike wrote: post #3

Earlier quoted context omitted.

And Java's worst contribution to software was how painfully slow and resource hungry most of the software written with it tends to be... Your argument is looking at the advantages Java brought to development speed and entirely disregarding runtime speed

java benchmarks are close to C's benchmarks; thousands of times faster than python

not in terms of memory usage and startup time. otherwise it's quite fast.

Re: Why you might want async in your project

#87

Post by klabb3 »

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 to do even menial things. The ones who try to use proper lifetimes etc are haunted by the compiler and give up after enough suffering.

Async was an extremely impressive demo that got partially accepted before knowing the implications. The remaining 10% turned out to be orders of magnitude more complex. (If you disagree, try to explain pin projection in simple terms.) The damage to the ecosystem from fragmentation is massive.

Look, maybe it was correct to skip green threads. But the layer of abstraction for async is too invasive. It would have been better to create a “runtime backend” contract - default would be the same as sync rust today (ie syscalls, threads, atomic ops etc – I mean it’s already half way there except it’s a bunch of conditional compilation for different targets). Then, alternative runtimes could have been built independently and plugged in without changing a line of code, it’d be all behind the scenes. We could have simple single-threaded concurrent runtimes for embedded and maybe wasm. Work stealing runtimes for web servers, and so on.

I’m not saying it would be easy or solve all use-cases on a short time scale with this approach. But I do believe it would have been possible, and better for both the runtime geeks and much better for the average user.

Re: Why you might want async in your project

#88

Post by Arnavion »

delusional wrote: post #82
Arnavion wrote: post #72

Earlier quoted context omitted.

The author said what you wrote in the first sentence, ie "use async if you are going to have a half implementation of async anyway". "Use async because you might need it in the future" is something you made up, not what the author said.

greenspun's tenth rule is about the inevitability of the half baked implementation of lisp. By evoking the sentiment of the rule the author is implicitly making the argument that all "sufficiently complicated programs" will eventually contain a half baked implementation of async. The implicit argument doesn't stand alone though. The author goes on to write: > It happens like this: programs are naturally complicated.…

>The implication is clear. Even simple programs will eventually require async, and should therefore just use it right now.

There's no implication. Read what you quoted instead of digging for quick jabs. "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..."

>unix-esque in this paragraph is supposed to evoke ls or cat. Is your program really going to be simpler than cat? No? Then you apparently need async.

cat and ls don't do two or three things at once.

Re: Why you might want async in your project

#89

Post by orangea »

delusional wrote: post #65

The author starts by citing greenspun's tenth rule and goes on to elaborate on the argument that if you are going to have a half implementation of async anyway, why not just pull it in? Yet fails to interrogate the relationship between this argument and the cited "rule". If you should use async because you might need it in the future, shouldn't we all be writing in lisp? If we presuppose that all software eventually…

The rule isn't really about lisp, it's about the kinds of functions and structures you find in the standard library of a typical programming language, such as strings and arrays and file IO and so on. Rust already has those things so your argument doesn't really apply.

Re: Why you might want async in your project

#90

Post by conradludgate »

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
Post reply on HN