Hacker News Reader

Comment by kochthesecond | Hacker News Reader

Why does update(...) mutate the model instead of returning the next state? This would make update a function instead of a side effect mutating the model.

View on HN

Returning a nextState in Redux/JS land is a workaround. Basically, one wants to avoid the situation where the state is mutated, but the framework does not know. This happens because there are multiple references to the state, and because, for performance reason, the framework is comparing the states based on referential (===) equality. Thus the view (in whole or in part) and the model can go out of sync. Always returning a new state object is an expensive way of ensuring this, but on the human time scales we're talking about, an insignificant cost.

On the other hand, in Rust, we have the compiler on our side. If one grabs a mutable reference to the state (&mut Model in the update function in https://github.com/DenisKolodin/yew/blob/master/examples/cou...), then the Rust compiler ensures that there are no other references to that Model. Thus, when the framework does `nextState = mutate(&currentState)`, one is guaranteed that there are no existing references to `&currentState`, and thus it is impossible for a shadow update to occur.

IMO, this is better not primarily for performance reasons, but because it is conceptually easier to mutate a state object instead of using reducers. (I haven't looked into this framework much, so I don't presume to speak about it's internal implementation, so this may be off in some framework-specific details.)

in a nutshell this the counterargument to functional purity: side effects can be done correctly/safely when you have/build the right tools. i'm inclined to agree with it.

It's not really a counterargument so much as another approach. Immutability and purity are still powerful concepts, but you don't need to use them for every single situation in rust.

Mutability is still harder to reason about in many/most cases. I thought that was always the main driver behind pure FP.

In Haskell, mutable APIs are available but this is surfaced in the types. The idea is not so much that you shouldn’t have mutability, as that it shouldn’t look the same (and be treated by the compiler the same) as immutability.

Maybe Haskell goes too far in this regard, but Rust is in line with the same way of thinking, because mutability is surfaced and checked at type level.

Referential equality is possibly an optimization, and makes re-rendering efficiently at least simpler.

Debugging and rewind/replaying application state is also greatly simplified by keeping states immutable.

Having the state mutable would also need some kind of locking between the render view and updateState method

You're certainly right that in the mutable Rust land you don't have rewind/replaying state out of the box.

> Having the state mutable would also need some kind of locking between the render view and updateState method

You may want to brush up on Rust, the language has been designed explicitly to deal with these kinds of situations.

> Having the state mutable would also need some kind of locking between the render view and updateState method

That's right, but that's exactly the main strength of Rust : the borrow checker deals with that locking at compile time with zero runtime overhead.

Not arguing on the other points though.

FWIW, it's more of a "simplicity" choice - it is entirely possible to keep mutations reactive in React with libraries like MobX - it's just extra functionality that React doesn't ship out of the box but it works just fine without a borrow checker.

Probably for performance reasons, allocating a whole new state each frame is pretty expensive.

I would argue that it is obviously worth it for the simplicity of being explicit what is the next state.

This kind of performance optimization, especially outside of game engines seem unnecessary.

This is Rust. Not exactly a language that makes compromises on performance for the sake of simplicity.

Each cycle you waste on mobile is milliwatts you're burning from the battery. Even if the user doesn't perceive it their battery will appreciate it.

You save a single allocation for every state change in your app? Never mind the actual render cycle? And lose a simple reference check to decide if you can short-circuit a part of your app?

it's not any more expensive than allocating a new object in Javascript. possibly less. if you want immutable models, allocation will most likely happen on mutation.

> it's not any more expensive than allocating a new object in Javascript.

so you mean bloody expensive ? seriously, if everybody thinks like you no surprise the current web crawls on beastly computers.

Idk about JS's memory model, but you can allocate the equivalent of a JS object in Java and Haskell very, very cheaply. I really don't think allocating a single JS object is expensive...updates to large immutable data structures should just require a few allocations (aka a handful of pointer bumps). Sure, it's technically more expensive than an in-place update to an equivalent large mutable data structure. But it's also not a fair comparison given one gives you way stronger guarantees about its behavior.

Except in those languages it can be just as brutally painful to allocate. Start modifying strings in the render loop on Android and see how quickly you get destroyed by constant GC pauses.

The only way to address it is with extensive pooling and heuristics.

Or you can just mutate.

Really it's no wonder that the web is so slow if the common conception is that allocating is no big deal. If you really want to do performance right allocations should be at the top of your list right next to how cache friendly your data structures are.

Because in reality it is no big deal. Modern GCs are incredibly efficient.

When a GC allocates memory all it does is check if there is enough memory in the "young generation" if yes it will increment a pointer and then it will just return the last position in the young generation. If there is not enough memory in the young generation the GC will start traversing the GC root nodes on the stack and only the "live" memory has to be traversed and copied over to the old generation. In other words in the majority of cases allocation memory costs almost as much as mutating memory.

There is a huge difference between “algorithmically efficient” (aka big o) and “real life efficient” (aka actual cycle counts). In real life, constant factors are a huge deal. Real developers don’t just work with CS, they work with the actual underlying hardware. Big O has no concept of cache, no SMP, no hypertreading, no pipeline flushes, no branch prediction, or anything else that actually matters to creating performance libraries and applications in real life.

There is a huge difference, you're also discounting GC. Haskell's GC for example is tuned to the aspects of the language, meaning it's pretty efficient at allocating and cleaning up lots of memory; it has to be, everything is immutable.

Mutable language GC's like JS or Java's aren't necessarily built for this compared to GHC. And even discounting all that, things like stack memory, cache, etc all make a huge difference in real world performance. GC's have come a long way, but there is still a gap in performance.

React does not allocate a new object in Javascript. No sane framework does.

"Immutable" data structures are not just objects that never get mutated, they're different manners of organizing the bytes.

React itself does not allocate a new object, but it forces you to do it yourself: to update the application state, you're supposed to call `setState()` with a brand new state (which is a newly allocated object). In React tutorial[1], you can notice the use of the `Object.assign` pattern which perform a new allocation.

However, most JS runtime have a generational GC so an allocation isn't remotely as costly as an allocation in C or Rust.

[1] https://reactjs.org/tutorial/tutorial.html#why-immutability-...

Doesn't make sense. You don't provide an entirely new object when you call `setState()`, just the parts of it that have changed.

When you use `Object.assign()` then you're doing it, but you don't have to use that, and probably shouldn't.

> React itself does not allocate a new object, but it forces you to do it yourself: to update the application state, you're supposed to call `setState()` with a brand new state (which is a newly allocated object)

Afaik you don't have to. It just makes things easier since state changes can be detected through shallow reference comparisons. There is even the shouldComponentUpdate() hook to allow the user to detect state changes which did not trigger a whole state object change.

Incremental updates to large, immutable data structures do not require allocating a whole new state per update (despite maintaining immutability!) Mutation is still frequently more efficient though, at the cost of not being able to reason immutably about your program. But if you're doing something that requires multiple versions of your state (e.g. history, undo/backtracking), the immutable version is going to be more efficient and definitely easier to write efficiently in the first place.

I'll give you that it'll be easier to write but once you start working with value types(like Rust has proper support for) then you don't get the nice efficiencies that come when everything in the world is a reference.

Most efficiency gains of imperative programming languages like C or C++ come from the compact and continguous memory layout and usage of the stack which is usually in the L1 cache.

In theory there would be no difference between mutating an existing memory area and allocating new memory to write to it. The number of bytes written to RAM are the same.

> In theory there would be no difference between mutating an existing memory area and allocating new memory to write to it. The number of bytes written to RAM are the same.

It's not the same, you need to allocate new memory, if it's on the heap then (depending on your allocator/OS etc) you will be making a syscall, which means context switch, cache eviction etc.

This is where understanding the difference between theory and practice is important, by its nature anything in the heap is not going to be in L1 cache.

That means a difference of ~300 cycles before you can even start working with the cache line you pull from main memory.

But the state is likely a tree structure and there will be lots of sharing if coded right.

I think frameworks like React should explicitly demand that state and props will be referentially compared to optimize the rendering.

mutating in Rust is not like mutating in JS, Python, Java C# or many other languages. Rust tracks ownership, you always know who might mutate the object and when. It is a very unique experience programming Rust

This might be more sane in Rust, I am not familiar with Rust.

I have used a lot of redux in js and written a few things in Elm, and the immutible property of application state is very central in both, and an important part of being able to reason with the ui, as well as events happening concurrently.

Immutability and ownership arent unrelated. They solve the same problem.

The problem with shared mutable state might appear to be then “mutable” but it’s the combination of shared+mutable.

Ownership removes one (if it’s mutable it’s not shared). Immutability removes the other.

The outcome is the same: you can reason about your code, including concurrent code.

The price of ownership is some extra mental overhead. The price of immutability is some extra copying and cumbersome updates.

In JS/Elm you have no choice but to manage shared mutable state using pure functions and immutable data. In rust you can use either model.

In rust you can use either model.

Not really. Of course you can copy immutable data upon update, but persistent data structures (large shared state between data versions)[1] are hard to write without GC...

[1] https://en.m.wikipedia.org/wiki/Persistent_data_structure

If you don't have cycles, ref counting can work (it's a kind of GC after all), but it indeed comes with a big performance overhead compared to a modern GC.

Reference counting [1] and atomic reference counting [2] are supported within Rust, and are sufficient for any persistent data structure without cycles. There's also a prototype crate for a mark and sweep GC [3], which would likely work for anything else. Writing such data structures using these features might be a bit more tedious than writing them in a GC language, but I suspect the increased explicitness provides a worthwhile tradeoff. See the crossbeam library [4] for some examples of lockless concurrent data structures implemented in Rust.

[1] https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/std/sync/struct.Arc.html [3] https://manishearth.github.io/blog/2016/08/18/gc-support-in-... [4] https://github.com/crossbeam-rs/crossbeam

As an alternative GC in Rust, you also have Josephine[1], which uses the SpiderMonkey[2] GC. It's cumbersome to use though[3] and should probably not be used outside of Servo.

[1]: https://github.com/asajeffrey/josephine

[2]: mozilla's JS VM

[3]: this is how you call a doubly linked list managed by the JS GC https://github.com/asajeffrey/josephine/blob/master/examples...

I’d say it’s not the immutability that’s so valuable, rather than restricting where it can be done. If the app state can only be mutated in one place in your app and under strict conditions, formal immutability no longer offers that much.

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

The problem is that the banana has a jungle attribute. If you pass a bannana to a function you're also implicitly passing in the entire jungle. The function could mutate the entire jungle without your knowledge. If you remove the jungle attribute from the bannana class you have to explicitly pass the jungle as a function parameter. This makes it far easier to understand the code.

The same applies to return values. If you return every changed value from a function and then explicitly handle the change at the callsite it doesn't actually matter if the data is mutable or immutable because the side effects are visible and easy to understand.

Reply on news.ycombinator.com