Why you might want async in your project
notgull.net
Why you might want async in your project
1–10 of 182 posts
Re: Why you might want async in your project
#2I 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 might want a library to use a buffer it got from the client or vice versa and fighting with the borrow checker all the time to do that is just saying “i choose to not be able to develop applications above a certain level of complexity.”
Re: Why you might want async in your project
#3I 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
Re: Why you might want async in your project
#4I 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
java benchmarks are close to C's benchmarks; thousands of times faster than python
Re: Why you might want async in your project
#5FYI This is an interesting response by the maintainer* of smol to this recent discussion:
https://news.ycombinator.com/item?id=37435515
* EDIT: corrected, thanks
Re: Why you might want async in your project
#6I 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
Re: Why you might want async in your project
#7I 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
I don’t like Java, but you are completely wrong.
Re: Why you might want async in your project
#8I 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…
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, global, compiler-enforced convention. I agree that there's a non-trivial initial skill hurdle, one that I also struggled with, but you only have to climb that once. I don't see that there's a limit to program complexity with these mechanisms.
Re: Why you might want async in your project
#9I 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
Any tool can be misused - the same comment could be made about Javascript, PHP, Perl, C, C++, Python, really any language.
Re: Why you might want async in your project
#10FYI This is an interesting response by the maintainer* of smol to this recent discussion: https://news.ycombinator.com/item?id=37435515 * EDIT: corrected, thanks
Maintainer, not creator. Smol was originally created by stjepang, who has basically disappeared these days.
EDIT: I originally incorrectly claimed that stjepang also created rather than maintained crossbeam, making the same msitake as I was correcting.