There is a huge semantic difference between sharing an object by providing a reference to it, passing the ownership of the object and passing a copy. It’s not a technical low level detail because the results can differ. Many developers use those distinctions in Rust to encode business rules, not to optimize memory use.
Similarly there is an important semantic difference between something you can change and something you shouldn’t change. Again - this can be used to express business logic constraints, similarly to how you can use static types to enforce other properties like e.g. „age must be a number”.
While you may say you can get away with just sharing references everywhere like Java or JS do, and not care about immutability, that’s like saying the only type you need is string and hashmap and you can code everything. And you just document in comments when strings contain numbers. I saw code like that in PHP once. Fun.
Similarly there is an important semantic difference between something you can change and something you shouldn’t change. Again - this can be used to express business logic constraints, similarly to how you can use static types to enforce other properties like e.g. „age must be a number”.
While you may say you can get away with just sharing references everywhere like Java or JS do, and not care about immutability, that’s like saying the only type you need is string and hashmap and you can code everything. And you just document in comments when strings contain numbers. I saw code like that in PHP once. Fun.