FRESH

Hacker News

Home

Concurrency in Haskell: Fast, Simple, Correct

193 points by ingve

by _jackdk_

0 subcomment

From the footnotes:
> It gets weirder: in Haskell, exceptions can be thrown to other threads!
What's really interesting is that because of purity, you have to have asynchronous exceptions otherwise you give up a lot of modularity. At least that's what Simons Marlow and Peyton Jones argue in Asynchronous Exceptions in Haskell (2006): https://www.microsoft.com/en-us/research/wp-content/uploads/...
> While the semi-asynchronous approach avoids breaking synchronization abstractions, it is non-modular in that the target code must be written to use the signalling mechanism. Worse still (for us), the semi-asynchronous approach is simply incompatible with a purely-functional language, such as Concurrent Haskell. The problem is that polling a global flag is not a functional operation, yet in a Concurrent Haskell program, most of the time is spent in purely-functional code. On the other hand, since there is absolutely no problem with abandoning a purely-functional computation at any point, asynchronous exceptions are safe in a functional setting. In short, in a functional setting, fully-asynchronous exceptions are both necessary and safe — whereas in an imperative context fully-asynchronous exceptions are not the only solution and are unsafe.
If you can read PLTese, it's really quite a nice paper.

by haskell17373

2 subcomments

It's maybe interesting to note that the `async` library in use here is very simple and easy to understand. Nearly every function is one or two lines. Likewise `TQueue` is extremely simple (and easy to prove correct) thanks to STM, and also generally has good performance.

by internet_points

2 subcomments

https://www.oreilly.com/library/view/parallel-and-concurrent... is a great resource for those who want to go deeper into this

by ackfoobar

0 subcomment

"Fast" in title. But I don't see any benchmarks, or discussion on how to reason about the performance of STM code.

by thuanao

0 subcomment

Correct? Anyone who has worked with concurrency in Haskell is probably laughing... :)
Haskell's IO type system doesn't model concurrency at all. `IO a` could be a fork and join, an infinite event loop, really anything, it's a black box in terms of "correctness". Better than using JavaScript maybe, but hardly "correct" in any sort of formal, tractable sense.

by wodenokoto

2 subcomments

I don't know how async is in other languages but I find Pythons async incredibly difficult to use, and I kinda feel validated about how poor chatGPT is at it as well.
Is it because it is just a very hard thing, or is it because its a synchronous language, with async bolted on? (I'm talking about a purely language point of view, not from a python VM / GIL point of view)

by throwaway17_17

0 subcomment

From the footnotes:
> In bare-metal embedded systems or inside the operating system, it’s not unusual to manually break computation into state machines, driven by interrupts.
Although not the topic of TFA, in fact, the footnotes that this is "a whole different ball game." Does anyone have any good source for this aspect of 'low-level'/OS development? I'm more than capable of chasing down sources from a more high level introduction or overview, so anything would be helpful. This concept seems like it may just be a more pragmatic description of embedded/OS development than what I've read previously.

by thih9

0 subcomment

After reading the title I was expecting a "pick two". From my anecdotal experience haskell is usually far from simple, but other configurations are possible too.

by michalsustr

7 subcomments

I’m not familiar with Haskell concurrency. The combination of green threads and large memory allocations due to immutable data structures sounds like it would be hard to implement a web server handling 10k+ concurrent requests on commodity hardware?
Btw. too bad author talks about microsecond guarantees usage but does not provide a link, that would be interesting reading.

by kookamamie

1 subcomments

> 1. Compose the program into several threads of execution, traditionally scheduled and ran by the operating system
The step 0 is missing:
Compose the program into several lanes of execution, traditionally executed via SIMD.
This is a massive piece of performance left on the table on modern computer architectures, by assuming threading is the first manifestation of concurrency.

by FuckButtons

6 subcomments

I thought it was a bit odd that the author claims there’s no mutexes in sight, the TVar is effectively a mutex guard unless I’m misunderstanding this? (I’ve written exactly 0 lines of Haskel). Or is the claim that the lack of ceremony and accidental complexity around threading is the real win for concurrency here?

by cosmic_quanta

2 subcomments

My favourite thing about Haskell concurrency is that there are no colored functions [0]. Writing code in IO, or Async, or the next big thing (asychronous higher-order effect system of the future??), doesn't require language support like Python or Rust.
The one construct that unlocks this lack of colored functions, STM, did require runtime support (as opposed to language support), which at least is transparent to downstream developers
[0]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

by mikojan

6 subcomments

In another life I will be a Haskell programmer

by jes5199

4 subcomments

I love Haskell because I can write provably correct code that still doesn’t work

by kamalhm

0 subcomment

Oh so this could be the inspiration on Virtual Threads and Structured Concurrency in Java

by ilrwbwrkhv

4 subcomments

Rust has a bunch of these while being maintainable.