Hacker News Reader

Comment by keymone | Hacker News Reader

> Sometimes mutations are useful

especially in a hello-world sized projects. as you scale up mutations become a constant source of bugs, bottlenecks and complexity.

> always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions

structural sharing in functional persistent data structures makes this problem go away 99%

what you get in exchange for giving up mutability are programs that are easier to reason about, have less bugs, better modularity, less man-hours wasted on maintenance. all the good stuff.

View on HN

I think the person's point was that you sacrifice performance - having the ability to mutate is only a good thing there, as immutability without being able to exit out of that is too inflexible and potentially could cause other hacks to appear when trying to solve that problem.

FP with a focus on immutability is good for the default, but ignoring its limitations is bad.

Sure, but I don't know any pure languages that provide no facilities for mutation whatsoever, they just ask you to be explicit about it and add some syntactic weight (which is a good thing, you want mutation called out as a reader). Haskell provides several different mutation options from simple references to various kinds of thread-safe references depending on what semantics you need. There's even a "no-really-trust-me" option.

So where does the myth that you can't exit out of immutability come from?

Erlang is purely immutable and doesn't have any "facilities for mutation" that I know about, although it does have side effects (I/O, but no Haskell-style effect system).

That's not entirely true. I built a FlatBuffers implementation for Erlang as NIFs so that I could still take advantage of FlatBuffers memory efficiency features, which fundamentally required "unsafe" and mutable access to a byte buffer. I just had to be very aware of exactly how the runtime was going to interact with my implementation and account for it.

Sadly the place where I worked was not keen on open source posture, so it's locked away for all of time probably. However, the place I now work is a lot more open source friendly and I expect to take another whack at it, but using Rust on the NIF side this time around instead of C.

Well, with NIFs you can do anything — it's a parallel C universe. I was really referring to Erlang the language.

Maybe GP meant something like FFI? Which is a mechanism that allows for any mutation you'd like and is present in most FP languages.

> having the ability to mutate is only a good thing there

hard to discuss without specific examples, but it is provably bad thing whenever you share the value that you're mutating.

if your problem boils down to crunching numbers, maybe even in a couple threads without needing to communicate and cooperate between them - sure, mutability is hands down best approach, but in other 99.9999% of problems it is a hindrance.

Reply on news.ycombinator.com