Small correction on number one, when using Compressed OOPS, they're actually 12, even on 64 bit. This is enabled by default for Xmx under about 30GiB, so the rest of your values might be off. Yes the pointer chasing is a cost, but I'd rather have the clarity first, and then if it becomes a problem (verified by benchmarking) I'll refactor it later. Code has three priorities: simplicity, correctness, speed, and yes in that order.

​@@dentjoener, although I really like the direction that the presenter is suggesting with stronger types (as mentioned in my initial comment), the main criticism is that the presenter dismissed any performance considerations based on incorrect facts. The video claims that the object header is 8 bytes when that hasn't been true for a long time since everyone uses a 64-bit runtime these days (along with other incorrect statements about memory amounts such as for booleans etc.). The video doesn't consider the effects of cache misses due to increased indirection etc. etc. In fact, most of the section on performance has incorrect statements or suggestions hence the need for my comment. Note that I'm not saying that performance is the most important aspect. The important point is that when convincing another developer about the value of using stronger types, I also acknowledge the memory and performance implications. This advice should not be followed universally without being aware of these costs since there are some scenarios where this would actually be bad advice (for example for intensive data-science computations, constrained environments such as Arduino, high-frequency trading, etc.). You have the priority order not quite right since correctness is definitely more important than simplicity most of the time (imagine trying to explain that a feature doesn't work correctly because the code was a tiny bit simpler this way). The truth is that there is no simple answer that applies in all scenarios since correctness is sometimes sacrificed if a scenario is expected to be extremely rare and the cost of addressing that is too high. Sometimes performance is more important than simplicity when response times are important such as emergency avoidance systems etc. Sometimes performance is even more important than correctness when the cost of determining the correct answer exceeds the required response times so we end up with approximations. There are times when we do the most amount of work possible in a specified amount of time and then stop it short presenting our best solution so depending on the importance of these solutions (eg. perhaps airline travel optimizations etc.) then making the code more performant can have a meaningful impact on the business to get improved solutions and these optimizations or improved algorithms typically reduce simplicity. The other common pitfall that many developers fall into is to completely ignore any performance considerations until it becomes a problem and only after benchmarking. This is a flawed view based on a misinterpretation from a quote from Donald Knuth as he was referring to low-level optimizations that usually aren't available in today's high-level languages (eg. pointer manipulations). Donald Knuth was a strong proponent of efficient algorithms and properly engineered solutions. For example, it's an accepted industry standard that we should use a StringBuilder instead of concatenating strings in a loop and this is expected of a good engineer. We shouldn't wait for concatenating strings to become a problem when we start dealing with non-trivial data-sets as that would be a silly approach. If an engineer replaces code that concatenates strings in a loop with a StringBuilder, we shouldn't ask them to benchmark it first as that would also be silly since we can logically reason about it. So even though string builders are strictly there for performance reasons, they are expected to be used from the beginning when appending strings in a loop. The bottom line is that when making a statement that a certain approach should always be used, it should actually apply to all scenarios or caveats should be mentioned instead of dismissed based on incorrect facts. If the cost of objects was as meaningless as the presenter suggests then Oracle wouldn't be devoting hundreds of combined man-years into project Valhala to try to avoid these costs.

I think that Inline classes were still experimental at the time

In Scala's defense, it is also a research language so it was somewhat "supposed" to go a little too far in exploring its ideas ;)

Haskell went way too far. Scala went back a little, and Kotlin went back to the most comfortable point.

Hold my Haskell!

OCaml is the best! It has the most powerful type inference of all production ready languages.

lmao, so true