Hacker News new | past | comments | ask | show | jobs | submit login

Objects carry prototypes and mutability with them. Further, all primitives/value types of the language are immutable.

Adding those features to an Object would still necessitate creating a new primitive.

At that point, you might as well make that primitive record that is directly available and just use the constructor to convert (just like you'd use `Number("123")`, you'd use `Record({my: "object"})`).




> Objects carry prototypes and mutability with them.

You can deep freeze the objects and freeze their prototypes.


It's not the same as tuples and records. You can do the following with them:

  const first = #{a: 'b', c: 'd'};
  const second = #{a: 'b', c: 'd'};
  first === second // true
So no more deep comparing of objects if they have the same properties.


Fascinating. I would have guessed that identity checks are still possible with ===, and == would use a structural comparison.

I suppose V8 for example could easily optimize records and tuples which are structurally equal into the same memory, then separate them into distinct memory blocks when they differ. This way an equality check could have the speed of an identity check if the two are known to be structurally equal.

I could be talking out of my ass here – maybe this isn't a performance concern at all and has been addressed far better already, and this is nonsense. But I do wonder how you'd quickly check for equality of, say, a large state tree to discover changes. On one hand that could be addressed by architecture. On the other, it is nice sometimes to simply know if two variables reference the same memory.


Yes. This fixes only immutability. For the value semantics (=== comaprison of content) pls check sibling comment thread.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: