Live data from Hacker News

Concurrency in Haskell: Fast, Simple, Correct

bitbashing.io

21–30 of 129 posts

Re: Concurrency in Haskell: Fast, Simple, Correct

#21
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.

Re: Concurrency in Haskell: Fast, Simple, Correct

#22
post #11
post #7

Earlier quoted context omitted.

Why not python ?

I’m not the OP, but static types, Hindley-Milner type inference, algebraic data types, and pattern matching can be quite ergonomic. I have also come to appreciate functional programming and how it makes reasoning about and testing code easier.

[dead]

Re: Concurrency in Haskell: Fast, Simple, Correct

#23
post #11
post #7

Earlier quoted context omitted.

Why not python ?

I’m not the OP, but static types, Hindley-Milner type inference, algebraic data types, and pattern matching can be quite ergonomic. I have also come to appreciate functional programming and how it makes reasoning about and testing code easier.

Yeah, just last week I updated the numeric precision of a value across an entire user journey in a big enterprise application, spanning many functions and data types. Thanks to Haskell, I could do it in a day.

In any other language I've used (barring maybe Ada) that is a refactoring that would take at least days, if not weeks, to manually track down all the places it interacts with the system directly or indirectly, because mixing e.g. int with long long is not a type error.

In Haskell, I change the type and the compiler spits out a list of locations that needs to change. This is repeated for a few iterations until all transitive interactions are worked out. Done!

Re: Concurrency in Haskell: Fast, Simple, Correct

#24
post #20

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

If that is what you want to do, you can do that in any language. It's just that when you do it in e.g. Java, you have to spend a lot longer proving correctness before discovering that it doesn't work.

Re: Concurrency in Haskell: Fast, Simple, Correct

#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.

Re: Concurrency in Haskell: Fast, Simple, Correct

#27

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.

> [...] 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.

Re: Concurrency in Haskell: Fast, Simple, Correct

#28

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.

> Warp is a high-performance HTTP server library written in Haskell, a purely functional programming language. Both Yesod, a web application framework, and mighty, an HTTP server, are implemented over Warp. According to our throughput benchmark, mighty provides performance on a par with nginx.

Source: https://aosabook.org/en/posa/warp.html

Re: Concurrency in Haskell: Fast, Simple, Correct

#29
post #27

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.

> [...] 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

#30

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).
Post reply on HN