Hacker News Reader

Comment by keymone | Hacker News Reader

that in my mind is classic example of how immutable approach saves you from the problem of reading inconsistent world. just like assembly registers, cache lines or struct field alignment, having to think about possibility to read the world inconsistently should not be "generic engineer's" job. it should be considered low level. there are more important things my brain has to be occupied with - like doing my actual job of writing business logic. it's great that borrow checker will error out, but i just don't ever want to see an error like that and that's why i love clojure and immutable persistent datastructures in general.

View on HN

> but i just don't ever want to see an error like that

Then, do not mark your variables as mutable. This error only happens if you use `let mut variable_name = ...`

AFAIK, `let var`, e.g. immutable variables, behaves the same as in clojure.

"anything that is legal according to compiler will eventually make it's way into the codebase" (approximately quoting Carmack here)

default behavior should be safe and simple to use, dangerous behavior should be hard to reach and inconvenient to use.

> dangerous behavior should be hard to reach and inconvenient to use

I understand your point, but to me that is exactly the case. It requires the extra "mut" (harder to reach) and is inconvenient to use (more compiler errors).

My point is; Rust gives you the choice. If you need mutability due to performance, or something like that, you can have it (at the cost of simplicity and convenience).

Also, "dangerous behavior" is not allowed, in this example threads sharing mutable and immutable reference to the same object.

we're at risk of splitting hairs now, but given that rust isn't describing itself as "functional immutable language" i posit that rust users will gladly reach for `mut` whenever they feel like it, while in clojure you will think ten times before using transients (i still haven't found myself in a situation where i'd need them).

If you wanted to use an immutable data structure, then you’d just use one. The im crate is a good example.

i'm aware that immutable datastructures are implementable in plenty of languages, that's not the point of my argument.

top comment claim is that clojure's approach to identity and value-semantics is somehow superseded and invalidated by rust's ownership and borrow checker, which is just too much koolaid. example i gave illustrates that given rust's default tools somebody will either have to deal with unnecessary low level errors (has nothing to do with high-level business logic of "i need this array to have new data") or will find a way to write incorrect code. none of that will happen given clojure's default tools.

Reply on news.ycombinator.com