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

111–120 of 129 posts

Re: Concurrency in Haskell: Fast, Simple, Correct

#111

Post by butterisgood »

whateveracct wrote: post #106
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.

It doesn't actually have "large memory allocations" due to immutable data structures. This is a meme that isn't true. Immutable data structures, especially at small scale, do not have huge performance penalties. You don't copy the entire structure over and over...you copy the O(log n) spine. Haskell's GC is also fast when you are mostly generating garbage, which is inherently true for web server handlers.

Deforestation helps with that

A composition of catamorphic and anamorphic functions can eliminate a lot of the in-between allocations (a hylomorphism)

Basically it looks like you’re building a ton of intermediate structure then consuming it - meaning much of the in-between stuff can be eliminated.

Interesting optimizations and a little mind blowing when you see it.

Re: Concurrency in Haskell: Fast, Simple, Correct

#112

Post by eduction »

eduction wrote: post #110
robto wrote: post #97

Earlier quoted context omitted.

Clojure atoms use STM, though. I've been writing Clojure for almost a decade now, it's not that STM isn't great, it's just that immutable data will carry you a very long way - you just don't need coordinated mutation except in very narrow circumstances. In those circumstances STM is great! I have no complaints. But it just doesn't come up very often.

That’s incorrect. Only refs+dosync use stm. https://clojure.org/reference/refs Not atoms. From Hickey’s History of Clojure paper: “ Taking on the design and implementation of an STM was a lot to add atop designing a programming language. In practice, the STM is rarely needed or used. It is quite common for Clojure programs to use only atoms for state, and even then only one or a handful of atoms in an entire program.…

PS I agree atoms and stm are both solid though — and that you can go a very long way without touching either!

Re: Concurrency in Haskell: Fast, Simple, Correct

#113

Post by butterisgood »

tasuki wrote: post #100
cosmic_quanta wrote: post #77

Earlier quoted context omitted.

There's no time like the present. Feel free to reach out if I can help you along your journey

Not the person you're replying to, but I'll bite: I've written low thousands of lines of Haskell. Similar to mikojan, I love Haskell in theory, but ended up not enjoying it as much in practice. 1. The multitude of string-y types. I end up converting between String, Text, Lazy Text, ByteString, Lazy ByteString, and I forget what else. Each library wants me to pass in a specific string type, and each other library retu…

Hence GHC extensions? Overloaded Strings don’t help? It’s been about 20 years since I wrote Haskell in production.

Re: Concurrency in Haskell: Fast, Simple, Correct

#114

Post by butterisgood »

tasuki wrote: post #49
revskill wrote: post #7

Earlier quoted context omitted.

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.

Can’t stand Python. Have to use Python. Wish it would DIAF to be honest.

Re: Concurrency in Haskell: Fast, Simple, Correct

#116

Post by revskill »

Philpax wrote: post #70
tasuki wrote: post #49

Earlier quoted context omitted.

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.

The concept of "the Pythonic Way" indicates to me that there are people who are proud of being Python programmers. May God have mercy on their souls.

Could u be more specific ?

Re: Concurrency in Haskell: Fast, Simple, Correct

#117

Post by sriram_malhar »

mrkeen wrote: post #101
sriram_malhar wrote: post #99

Earlier quoted context omitted.

I'm surprised you say this. The core type system guarantees is that there is no aliasing while mutating, and no mutation while it is aliased. You get single writer multiple reader for free without overhead. If you want multiple writers, you can always use the Arc container and use the built-in lock.

>> or some comment like: Rust guarantees that you aren't mutating shared state. > The core type system guarantees that there is no [sharing] while mutating, and no mutation while [sharing]

Not sure what you are pointing out, so let me spell out what I said earlier.

1. You get single-writer multiple reader for free from the type system, without any runtime overhead.

2. For the same reason, the type system does not allow multiple writers. If you want multiple writers, then you are forced to use locks. Once you use locks, the runtime guarantees safety for this case.

Either way, you get 100% safety.

Re: Concurrency in Haskell: Fast, Simple, Correct

#118

Post by eru »

whateveracct wrote: post #107
eru wrote: post #78

Earlier quoted context omitted.

> The canonical Haskell compiler, GHC, is excellent at transforming operations on immutable data, as Haskell programs are written, into efficient mutations, at the runtime level. Yes, at the level of native machine code and memory cells, there's not that much of a difference between immutability + garbage collection, and higher level source code that mutates. Thanks to GC you are going to overwrite the same memory lo…

Programmers for some reason really don't understand that generational garbage collection provides locality. I am really surprised how often I see C/C++/Rust types not understand this.

I think that only applies to a moving GC. A conservative GC (like the Boehm GC for C) doesn't move any items around, and thus doesn't do anything for locality.

Of course, even a moving GC has limits, itwon't turn a hashtable into something that has local accesses.

Re: Concurrency in Haskell: Fast, Simple, Correct

#119

Post by eru »

whateveracct wrote: post #109
michalsustr wrote: post #46

Earlier quoted context omitted.

Yes indeed, unless you use ropes or other specialised structures

Well luckily, Haskell is full of said "specialized structures." containers and unordered-containers handle most of your needs and they only copy their trees' spines (O log n) on update.

Haskell also support eg arrays with O(1) in-place updates just fine.

Re: Concurrency in Haskell: Fast, Simple, Correct

#120

Post by tasuki »

cosmic_quanta wrote: post #104
tasuki wrote: post #100

Earlier quoted context omitted.

Not the person you're replying to, but I'll bite: I've written low thousands of lines of Haskell. Similar to mikojan, I love Haskell in theory, but ended up not enjoying it as much in practice. 1. The multitude of string-y types. I end up converting between String, Text, Lazy Text, ByteString, Lazy ByteString, and I forget what else. Each library wants me to pass in a specific string type, and each other library retu…

I'm not going to sell you on anything. All of the things you've mentioned are true. Loosely, the multitude of string types and the state of the standard library come from the same place: the language is 30+ years old! There are many warts to be found. However, if you decide to start learning, the path is hard, especially if you come from a non-computer-science background like me. I attempted to learn Haskell twice; I…

> Having a goal in mind, that has nothing with the choice of language

Yes, yes, that's exactly what my encounters with Haskell looked like. The last one is ~1k lines of code backend for a personal project. I feel that's about as much as I could manage at this point.

> The book Haskell Programming from First Principles

That book is getting recommended all the time! I'm concerned if it's perhaps a little too basic for me. (I understand monads, monad transformers, have some notion of final tagless and free monad. Yet I get perpetually confused by various relatively simple things.)

I guess what I'm missing is haskell-language-server to help me a little. Here I'm confused about the interplay between `haskell-stack` (which is in Debian repos and which I think I'd like to use), ghcup, cabal, and haskell-language-server.

Post reply on HN