I love Haskell because I can write provably correct code that still doesn’t work
Concurrency in Haskell: Fast, Simple, Correct
41–50 of 129 posts
Re: Concurrency in Haskell: Fast, Simple, Correct
#42Rust has a bunch of these while being maintainable.
Re: Concurrency in Haskell: Fast, Simple, Correct
#43I 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?
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
#44Re: Concurrency in Haskell: Fast, Simple, Correct
#45Earlier 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?
"Beware of bugs in the above code; I have only proved it correct, not tried it."
Re: Concurrency in Haskell: Fast, Simple, Correct
#46Earlier 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.
Re: Concurrency in Haskell: Fast, Simple, Correct
#47I’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).
Re: Concurrency in Haskell: Fast, Simple, Correct
#48Earlier 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
Re: Concurrency in Haskell: Fast, Simple, Correct
#49Re: Concurrency in Haskell: Fast, Simple, Correct
#50Earlier 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…
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.