Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrency in Haskell: Fast, Simple, Correct

bitbashing.io

Post reply on HN
Print view View original

31–40 of 129 posts

Re: Concurrency in Haskell: Fast, Simple, Correct

#31

Post by zozbot234 »

haskell17373 wrote: post #2

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.

A lot of the complexity here is just hidden in Haskell's runtime, which implements async processing based on green threads, besides other features such as GC. Though to be fair, the software transactional memory (STM) featureset is quite unique to Haskell since it relies on the availability of pure functions to ensure correctness. It's kind of hard to imagine a full equivalent to it in other well-known languages.

Re: Concurrency in Haskell: Fast, Simple, Correct

#33

Post by lemper »

michalsustr wrote: post #25

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.

nah bro, warp is quite performant. think there were some consultancies that wrote haskal web app for their clients.

Re: Concurrency in Haskell: Fast, Simple, Correct

#36

Post by kreetx »

haskell17373 wrote: post #2

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.

While the async library is great, then everything that came before (forkIO, MVar's, etc) was already simple enough - it's only the exception handling that was missing.

Re: Concurrency in Haskell: Fast, Simple, Correct

#38

Post by anonzzzies »

declan_roberts wrote: post #21
jes5199 wrote: post #20

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

I love it because I can spend all my time noodling over types and never ship a product that would have been great shipped in a late night wine-fueled session of 1999 PHP.

Now you would vibe it and ship it during the ol' drink.

Re: Concurrency in Haskell: Fast, Simple, Correct

#39

Post by mrkeen »

dionian wrote: post #12
dsign wrote: post #10

Earlier quoted context omitted.

You are correct, Haskell has quite a few mutex-like types. MVar is one of them. However, if memory serves me right, TVar is a building block for the transactional memory subsystem. The guard on TVar with, say, modifyTVar is not really stopping execution at entrance but simply indicating that the block modifies the variable. In my mental model, some magic happens in an STM block that checks if two concurrent STM block…

https://zio.dev/reference/stm/

> Implication of Using STM Running I/O Inside STM— There is a strict boundary between the STM world and the ZIO world. This boundary propagates even deeper because we are not allowed to execute arbitrary effects in the STM universe. Performing side effects and I/O operations inside a transaction is problematic. In the STM the only effect that exists is the STM itself. We cannot print something or launch a missile inside a transaction as it will nondeterministically get printed on every reties that transaction does that.

Does Zio actually offer any protection here, or is it just telling the reader that they're on their own and should be wary of footguns?

Re: Concurrency in Haskell: Fast, Simple, Correct

#40

Post by mrkeen »

FuckButtons wrote: post #5

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?

Mutexes lock code, TVars lock data.

If you lock a section of code (to protect data), there's no guarantee against mutations of that data from other sections of code.

If you lock the data itself, you can freely pass it around and anyone can operate on it concurrently (and reason about it as if it were single-threaded).

It's the same approach as a transactional database, where you share one gigantic bucket of mutable state with many callers, yet no-one has to put acquire/release/synchronise into their SQL statements.

Post reply on HN