←back to thread

193 points ingve | 2 comments | | HN request time: 0.613s | source
Show context
michalsustr ◴[] No.43713518[source]
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.

replies(7): >>43713603 #>>43713615 #>>43713878 #>>43714039 #>>43715073 #>>43716268 #>>43724017 #
eru ◴[] No.43713603[source]
> [...] 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.

replies(1): >>43713874 #
nesarkvechnep ◴[] No.43713874[source]
No reason. OC probably thinks that immutable data structures are always copied when being operated on.
replies(1): >>43714389 #
michalsustr ◴[] No.43714389[source]
Yes indeed, unless you use ropes or other specialised structures
replies(4): >>43714422 #>>43715066 #>>43715416 #>>43724028 #
xmcqdpt2 ◴[] No.43715066[source]
Lists aren’t copied on prepend.

Tries (like scala’s Vector) or trie maps (the core map types of Scala, Clojure and probably Haskell?) aren’t copied on updates.

In fact, whether a data structure is an immutable or persistent data structure or merely an unmodifiable data structure (like Kotlin uses) is based on whether it requires full copies on most updates or not. In FP languages, immutable data structures aren’t “specialized” at all.

replies(1): >>43717117 #
1. Y_Y ◴[] No.43717117[source]
> whether a data structure is an immutable or persistent data structure or merely an unmodifiable data structure...

This hurt my brain. It seems that in some places (e.g. Java land) unmodifiable refers to something that you can't modify but could just be a wrapper around a structure that can be modified. In that case they use immutable to mean something that is nowhere modifiable.

I may be misrepresenting this idea, but I think the terminology is so poor that it deserves to be misunderstood.

replies(1): >>43717750 #
2. mrkeen ◴[] No.43717750[source]
Think about mutability in Java land this way:

  // Using mutability.
  // `increment` is void, and makes 2 bigger for everyone.
  increment(2); 

  // Typical Java "safety".
  // It's still void, but now it throws a RuntimeException
  // because the developers are saving you from making everyone's 2 bigger.
  increment(2);

  // Immutable
  // Returns 3
  increment(2);