4 ms·

Haskell threads have some similarities to Goroutines. They are also real cheap and there's no problem creating lots of threads (M:N scheduling behind the scenes

by adeon 3y ago

Haskell threads have some similarities to Goroutines. They are also real cheap and there's no problem creating lots of threads (M:N scheduling behind the scenes). There's also no function color problem with the threads. There's one special thing that Haskell threads have that I think I've only seen in Erlang: it's safe to kill threads. Things will be cleaned up properly. You can safely expect that Haskell code created by someone else has been written to not go into a bad state if it's suddenly cancelled. For example, you can write a generic timeout function that works by launching the work in a new thread, then wait N seconds, then kill that thread if it's still running. You don't need to make any kind of signalling thing where you send "please stop" message to a Goroutine. The article talks about Goroutines in context of serving lots of requests. I like to think Haskell's threads and the fact that you can kill them safely makes it much easier to develop servers or job orchestration with simpler code.

aseipp 3y ago
To be fair, there have been plenty of bugs in Haskell libraries wrt exception safety. Cancellation and asynchronous exceptions are actually really hard in practice. But yes, actually having the possibility can make some code a lot easier to write and think about.
- whateveracct 3y ago
  the flipside is async exceptions mean you can always kill a thread if a goroutine doesn't select on a chan, you're screwed and don't get me started on how bad Go gets in terms of exception safety. I've seen defer go wrong in so many ways. Unrestricted mutability is mostly to blame.
whateveracct 3y ago
Yes! People malign async exceptions but the fact that you can zap GHC thread is genius. I am mostly a Haskeller (10 years now) but I used Go at a startup once. It was shocking how often we leaked goroutines. Whereas in Haskell, if you use async it's hard to. Haskell exceptions are tricky (and there are plenty of bloggers who make a niche living acting like they're so hard to deal with you need to hire them) but in 2023 it's trivial. Just use the unliftio wrappers and you're golden.

by adeon 3y ago

aseipp 3y ago

To be fair, there have been plenty of bugs in Haskell libraries wrt exception safety. Cancellation and asynchronous exceptions are actually really hard in practice. But yes, actually having the possibility can make some code a lot easier to write and think about.

whateveracct 3y ago
the flipside is async exceptions mean you can always kill a thread if a goroutine doesn't select on a chan, you're screwed and don't get me started on how bad Go gets in terms of exception safety. I've seen defer go wrong in so many ways. Unrestricted mutability is mostly to blame.

whateveracct 3y ago

Yes! People malign async exceptions but the fact that you can zap GHC thread is genius. I am mostly a Haskeller (10 years now) but I used Go at a startup once. It was shocking how often we leaked goroutines. Whereas in Haskell, if you use async it's hard to. Haskell exceptions are tricky (and there are plenty of bloggers who make a niche living acting like they're so hard to deal with you need to hire them) but in 2023 it's trivial. Just use the unliftio wrappers and you're golden.