zlacker

>>lukast+(OP)
When writing some IO bound application, async Rust is great. Less great for libraries that want to support both async and sync without having to make an async runtime a dependency if you just want the sync interface. Mutually exclusive features are taboo unfortunately. One thing I really love about Haskell is you can make any function run in a green thread by simply composing it with the 'async' function. There's nothing special about it. This works much better than say Go, because Haskell is immutable.

>>xedrac+zh
I'm not clear what your last sentence has to do with anything else? What does immutability have to do with Async/sync conversions?

>>XorNot+ri
you can fearlessly run code on another thread if you're not worried it's going to cause a data race or mutate anything

>>throwa+4m
This is very much not free though. Predicting memory usage in Haskell programs is notoriously tricky (and all the memory copies aren't free either).

>>XorNot+Tm
Predicting memory usage in Haskell programs isn't actually tricky. At least, I stopped thinking so once I became an intermediate Haskeller. It's not that hard to have a mental model of the Haskell RTS the same as you'd have the JVM.

Having the ability to do so generally is tablestakes for being an intermediate professional programmer imo. In university, I had to draw diagrams explaining the state of the C stack and heap after each line of code. That's the same thing. And I was 19 lmao. It's not hard.

Maybe you're referring to space leaks? I've run into like 2 in my ten year Haskell career, and neither hit prod

I've actually seem more Go and Java space leaks/OoM bugs hit prod than Haskell - despite having fewer total years using those languages than Haskell! Nobody blamed the language for those though :/