I love Haskell because I can write provably correct code that still doesn’t work
Concurrency in Haskell: Fast, Simple, Correct
21–30 of 129 posts
Re: Concurrency in Haskell: Fast, Simple, Correct
#22Earlier 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.
Re: Concurrency in Haskell: Fast, Simple, Correct
#23Earlier 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.
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
#24I love Haskell because I can write provably correct code that still doesn’t work
Re: Concurrency in Haskell: Fast, Simple, Correct
#25Btw. 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
#26Re: Concurrency in Haskell: Fast, Simple, Correct
#27I’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.
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
#28I’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
#29I’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
#30I’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.