Value objects may be simple, but they're not obvious. If they were, more code would use them. To the extent that the concept is relevant, the difference is obv

Value objects may be simple, but they're not obvious. If they were, more code would use them. To the extent that the concept is relevant, the difference is obvious unless you only ever use languages that are ambiguous about reference/value semantics. If you use a language like C or C++ or even assembly, where pointers and taking an address are explicit and fundamental concepts, there's mostly no problem. Your data is a value by default, and if you want a reference (pointer) instead, you just make one, explicitly. The exception is arrays, and in not entirely unrelated news, array semantics in C and C++ are a significant source of bugs. If you use a functional programming language, again data is typically immutable unless you explicitly use some sort of reference type, so again no problem. I have long maintained that one of the worst of Java's many design flaws was using the exact same syntax to represent two distinct but related concepts, depending on whether you were referring to a primitive or a class-based type. At least with the static typing you can see which you've got, though. I can't fathom why you'd deliberately design a language to work like JS or Python, where not only can the exact same syntax mean two completely different things but which you get depends on dynamic typing information that you can't even see until runtime, or even on the exact values you're using rather than their types, in a case like Python's handling of small integers. I shudder to think how much productivity has been lost by now to bugs caused by mixing up .equals() with == in Java, == with === in JS, and == with `is` in Python.