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

61–70 of 182 posts

Re: Why you might want async in your project

#61

Post by Ar-Curunir »

dpc_01234 wrote: post #44

I might need a lot of stuff in my software. Eventually. I might need distributed database, or to to scale it out to run on multiple machines, and then maybe Raft, or reactive architecture, zero-copy IO, or incremental updates or ... or ... the list goes on and on. Thinking too much and in particularly going with over complicated solutions from the very start because "might" is just bad engineering. Also, even if I do…

> I also need it sometimes. But that doesn't explain the fact that every single thing in Rust ecosystem nowadays is async-only, or at best blocking wrapper over async-only.

Now that’s just plainly untrue.

Re: Why you might want async in your project

#62

Post by dataflow »

codeflo wrote: post #48
dataflow wrote: post #28

Earlier quoted context omitted.

You're missing a bunch of very important stuff in that page you linked to. See what they listed as the culprits: > strings being passed as char* (using c_str()) and then converted back to string > Using a temporary set [...] only to call find on it to return true/false > Not reserving space in a vector c_str() isn't there for "good performance" to begin with; it's there for interfacing with C APIs. RAII or not, GC or…

I'm responding to a comment that claims all lifetime issues are solved by RAII. My argument was that for efficient code, you need to pass references or pointers, which means you do need to care about lifetimes. And your argument is that's not true because we now have std::string_view? You do realize that it's just a pointer and a length, right? And that this means you need to consider how long the string_view is vali…

> I'm responding to a comment that claims all lifetime issues are solved by RAII.

I don't see anybody claiming this. The parent I see you initially replied to said "the C++ resource management paradigm is RAII", not "all lifetime issues are solved by RAII".

> My argument was that for efficient code, you need to pass references or pointers, which means you do need to care about lifetimes.

Of course you do. Nobody claimed you don't need to care about lifetimes. (Even in a GC'd language you still need to worry about not keeping objects alive for too long. See [1] for an example. It's just not a memory safety issue, is all.) The question was whether "every library or API you use" needs to have "a different cleanup convention" for performance reasons as you claimed, for which you cited the Chromium std::string incident as an example. What I was trying to point out was:

> that's not true because we now have std::string_view? You do realize that it's just a pointer and a length, right?

...because it's not merely a pointer and a length. It's both of those bundled into a single object (making it possible to drop them in place of a std::string much more easily), and a bunch of handy methods that obviate the ergonomic motivations for converting them back into std::string objects, hence preventing these issues. (Again, notice this isn't just me claiming this. The very link you yourself pointed to was pointing to StringPiece as the solution, not as the problem.)

So what you have left is just 0 conventions for cleanup, 1 convention for passing read-only views (string_view), 1 convention for passing read-write views (span), and 1 convention for passing ownership (the container). No need to deal with the myriads of old C-style conventions like "don't forget to call free()", "keep calling with a larger buffer", "free this with delete[]", or whatever was there over a decade ago.

> And that this means you need to consider how long the string_view is valid etc., just as carefully as you would for any other pointer?

Again, nobody claimed you don't have to worry about lifetimes.

[1] https://nolanlawson.com/2020/02/19/fixing-memory-leaks-in-we...

Re: Why you might want async in your project

#63

Post by diarrhea »

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…

But async Python is a single threaded. I’d prefer async over multithreading in python nowadays. Otherwise code can be slow as piss, if it’s doing a lot of I/O. Then, async is almost table stakes for almost any level of reasonable performance (GIL and all).

Re: Why you might want async in your project

#64

Post by charrondev »

airstrike wrote: post #3
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…

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

The only Java thing I work with is ElasticSearch (and in the past other lucene based search tools like Solr). These can be resource hungry depending on what your indexing but they are also faster and more scalable than other tools I’d used before.

Re: Why you might want async in your project

#65

Post by delusional »

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 develops an async, and we therefore should use async. Would it not stand to reason that greenspun's rule that all software contains a lisp would imply that we must also all use lisp?

Re: Why you might want async in your project

#66

Post by hgomersall »

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…

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.

Re: Why you might want async in your project

#67

Post by jayd16 »

Nullabillity wrote: post #11
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 problem with garbage collection is that it doesn't work for other kinds of resources than memory, so basically every garbage collected runtime ends up with an awkward and kinda-broken version of RAII anyway (Closeable, defer, using/try-with-resources, context managers, etc). Static lifetimes are also a large part of the rest of Rust's safety features (like statically enforced thread-safety). A usable Rust-without…

You make an interesting point. Has any language introduced a generic-resource-collector? You're not supposed to use deconstructors to clean up resources because you're left to the whims of the GC which is only concerned about memory.

Has anyone build a collector that tracks multiple types of resources an object might consume? It seems possible.

Re: Why you might want async in your project

#68

Post by maxbond »

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…

Most commercial code is running an almost entirely IO workload, acting as a gatekeeper to a database or processing user interactions - places where async shines.

Async isn't a lark, it's a workhorse. The goal is not to write sexy code, it's to achieve better utilization (which is to say, save money).

Re: Why you might want async in your project

#69

Post by dpc_01234 »

Ar-Curunir wrote: post #61
dpc_01234 wrote: post #44

I might need a lot of stuff in my software. Eventually. I might need distributed database, or to to scale it out to run on multiple machines, and then maybe Raft, or reactive architecture, zero-copy IO, or incremental updates or ... or ... the list goes on and on. Thinking too much and in particularly going with over complicated solutions from the very start because "might" is just bad engineering. Also, even if I do…

> I also need it sometimes. But that doesn't explain the fact that every single thing in Rust ecosystem nowadays is async-only, or at best blocking wrapper over async-only. Now that’s just plainly untrue.

Yes, yes. You're right. Though it does sometimes feel like it.

Re: Why you might want async in your project

#70

Post by Arnavion »

maxbond wrote: post #21
api wrote: post #20

Earlier quoted context omitted.

Awaits don’t create threads, at least not in any runtime I know of. There is usually a fixed number of threads at launch.

I think they meant it was likely to spin off additional tasks/green threads.

If they meant that they are still wrong.
Post reply on HN