While my blog post is totally unrelated, I wanted to hint at the idea of having to choose between different types of value and pointer semantics and t

What Color is Your Type?

submited by
Style Pass
2023-05-30 10:30:15

While my blog post is totally unrelated, I wanted to hint at the idea of having to choose between different types of value and pointer semantics and the eventual lack of code consistency that may arise from that. Keep in mind that this is something that I personally find bothersome, but others in the community find unimportant enough to bear talking about. It will most likely not match your opinion (and that’s OK).

My biggest gripe with pointers in Go (and C before it) has never been what they are or what they are used for. It’s that they are so prevalent that I often ask myself why programming languages like Go are value-first and not reference-first. I know I know - memory, heap, garbage collection pressure. I am aware of all that - after all, I spent most of my programming career writing Java code. I know the pain of running an app that eats a few gigs of RAM from the get-go.

Which is why I like the idea of copying values on the stack. When we talk about primitives, it is utterly indispensable. Java has primitive values too, but in the name of consistency, a large portion of the Java code out there would use their boxed counterparts (Integer, Long, Boolean, etc.). Those are classes wrapping up a primitive value for it to be treated like a reference. You can imagine where those end up being stored - yes, on the heap. If you run a Java profiler, you will notice that much of the heap gets consumed by primitives disguised as object references.

Leave a Comment