Hacker News new | past | comments | ask | show | jobs | submit login

I think i have a more elegant solution for this deadlock:

"Switch to haskell".




If serious: that’s dismissive, superior, and a low-effort appeal to Haskell fans.

If not serious: it’s still low effort, but while it is framed as a zinger, it’s not funny at all. I don’t even understand what the humor might be, maybe it’s serious after all.


It would have been better to write:

Switch to a language/runtime that's not only had virtual threads for decades, but also a saner synchronisation model (transactions) rather than synchronized blocks.


Every language with sufficient concurrency and parallelism primitives are prone to dead locks/live locks and any other kind of race conditions.


Exactly! It's the same thing with memory management primitives. If you expose malloc and free directly to an application programmer, things will eventually get buggy.

It's better to hide the locking primitives and let the runtime handle it for you safely.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: