[sillysaurus3]

I've been waiting for a non-Clojure lisp to make some headway. Immutability is mostly a fad: look at how incredibly complicated Clojure's implementation is. It's not worth sacrificing elegance just to attract the true believers.

[macintux]

Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it?

The Erlang VM has immutability deeply baked in, and it just works(™).

[nostrademons]

Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails.

There are some problem domains - eg. GUI software, web browsers, simulations, many of the more complicated parsing, data extraction, or graph-traversal algorithms - that are inherently mutable, and Erlang is not used very much in these domains. C++ still rules the roost there, even though many of its practitioners hate its shortcomings.

[pjmlp]

> C++ still rules the roost there, even though many of its practitioners hate its shortcomings.

The solution has been to move it down the stack, as visible on all Apple, Google and Microsoft OSes, even on Qt.

It is there, making full use of the hardware in all performance critical code, but then the actual GUI code gets written in something else.

[banachtarski]

I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are making in the process.

[ams6110]

It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.

[im_down_w_otp]

Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.

[ramchip]

You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...

[im_down_w_otp]

Yes, that. Thank you.

[banachtarski]

That's not true in a number of cases, and thankfully what you said isn't right or the BEAM would truly be a disaster.

[sillysaurus3]

It's hard. http://hypirion.com/musings/understanding-persistent-vector-...

[flavio81]

>I've been waiting for a non-Clojure lisp to make some headway. Immutability

Common Lisp welcomes you, as awesome as ever since 1994.

>Immutability is mostly a fad

Inmutability is good. What i don't like is mandatory inmutability with no easy way to opt out.

[s4vi0r]

Why/how is immutability a fad? Do you just mean in the context of LISPs? What elegance does having immutable by default data structures?

[tree_of_item]

Clojure's implementation did not have to be so complicated, there are simpler implementations of persistent data structures.

Immutability is obviously the more elegant option as far as I'm concerned: Hickey's The Value of Values[0] lays out the case quite well.

[0]: https://www.youtube.com/watch?v=-6BsiVyC1kM