Live data from Hacker News

Concurrency in Haskell: Fast, Simple, Correct

bitbashing.io

41–50 of 129 posts

Re: Concurrency in Haskell: Fast, Simple, Correct

#43

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?

As siblings note, TVar is a transactional variable. However, it's not just protective against concurrent writes but also against concurrent reads of altered variables, so it offers true atomicity across any accessed state in a transaction.

So if you have a thread altering `foo` and checking that `foo+bar` isn't greater than 5 and a thread altering `bar` and checking the same, then it's guaranteed that `foo+bar` does not exceed 5. Whereas if only write conflicts were detected (as is default with most databases) then `foo+bar` could end up greater than 5 through parallel changes.

Re: Concurrency in Haskell: Fast, Simple, Correct

#44
post #20

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

A Haskell quote I like is: “I’ve only proven this correct, I haven’t tried it.”

Isn’t that one of Dijkstra’s supposed comments?

Re: Concurrency in Haskell: Fast, Simple, Correct

#45

Earlier quoted context omitted.

A Haskell quote I like is: “I’ve only proven this correct, I haven’t tried it.”

Isn’t that one of Dijkstra’s supposed comments?

It's Knuth! [1]

"Beware of bugs in the above code; I have only proved it correct, not tried it."

[1]: https://www-cs-faculty.stanford.edu/~knuth/faq.html

Re: Concurrency in Haskell: Fast, Simple, Correct

#46
post #27

Earlier quoted context omitted.

> [...] large memory allocations due to immutable data structures sounds [...] Why would there be large memory allocations because of immutable data structures? Btw, you can also use immutable data structure in eg Rust fairly easily. And Haskell also supports mutation and mutable data structures. However, Haskell can use a lot of memory, but that's more to do with pervasive 'boxing' by default, and perhaps laziness.

No reason. OC probably thinks that immutable data structures are always copied when being operated on.

Yes indeed, unless you use ropes or other specialised structures

Re: Concurrency in Haskell: Fast, Simple, Correct

#47

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.

You obviously haven’t ran anything on the BEAM (Erlang’s VM).

Correct. Erlang also uses green threads?

Re: Concurrency in Haskell: Fast, Simple, Correct

#48

Earlier quoted context omitted.

No reason. OC probably thinks that immutable data structures are always copied when being operated on.

Yes indeed, unless you use ropes or other specialised structures

Doesn't it depend on the data structure? Eg prepending to a list is actually cheaper with immutable data structures: you keep the original list and add a new head pointing to its head. Now you have two lists available in your program, but only one stored in memory. Yay!

Re: Concurrency in Haskell: Fast, Simple, Correct

#49
post #7
post #3

In another life I will be a Haskell programmer

Why not python ?

No one wants to be a python programmer. It's a practical language to get things done. It isn't a language to make you feel proud of yourself nor about the current state of our industry.

Re: Concurrency in Haskell: Fast, Simple, Correct

#50

Earlier quoted context omitted.

I think Clojure has some kind of STM too? Haskell's STM is pretty world-class though. That's fair to say :)

Clojure's STM never really took off because, for various reasons, it's not as easy to compose as Haskell's (where you can build up a big library of STM blocks and piece them together at the very edges of your program). As such Clojure's STM implementation doesn't actually have a great reputation within the Clojure ecosystem where it isn't usually used in most production codebases (whereas in Haskell STM is often one…

You missed a very important detail, the language runtime.

While Haskell's runtime is designed for Haskell needs, Clojure has to be happy with whatever JVM designers considered relevant for Java the language, the same on the other platforms targeted by Clojure.

This is yet another example of a platform being designed for a language, and being a guest language on a platform.

Post reply on HN