111–120 of 182 posts
Biggest issue I have with async is the lack of native async traits and the lack of support for async closures. You can work around the traits issue but the closure issue you can’t. I’ve spent hours trying to work around closures that wrap async code.
> 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…
That's not "fun", that's table stakes.
Earlier quoted context omitted.
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…
> The problem with garbage collection is that it doesn't work for other kinds of resources than memory Why is that a "problem with GC"? Abstracting away >90% of resource management (i.e. local memory) is a significant benefit. It's like saying the "problem with timesharing OS" is that it doesn't address 100% of concurrency/parallelism needs.
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
It's hip to hate on java, but at least do it from an informed position.
Java is extremely fast, which is why it's so popular for server code where performance matters.
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…
This means that any crate that uses IO will be bound to a limited number of Runtimes. Everything being Tokio-only is pretty bad (though Tokio itself is great), but here we are...
[0] https://github.com/bluejekyll/trust-dns/pull/1373#issuecomme...
I love async in Python and JS. I used to be one of those "Threads aren't that hard, just use threads" people, but that was back when the trend was doing "async" with layers of nested callbacks like as if this was LISP or something where people just accept deep nesting. Now we have async/await and I'm always happy to see it.
I use it in C# and JS with no friction or mental overhead required.
In C#, I can still use channels or threads if I want to as well. But async/await is great for any I/O heavy code.
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…
Is this a new development? Last time I checked, every library seemed to be tied to a specific runtime (usually tokio).
> 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.
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…
Earlier quoted context omitted.
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…
FWIW Arc implements From so you can do `let foo = blah().into()` and if `foo` is passed to something expecting Arc it'll be an Arc. This probably works for Arc > as well so you'd be able to do `.into().into()` but I'm not sure.