Measuring performance in mutable and immutable code
A common complaint about immutable code is that it is less performant than its mutable counterpart. Even without doing a deep dive into the performance characteristics of the Go runtime, this seems like a reasonable statement. After all, in the immutable variant, a new copy of an object is spawned for each function call. In practice, however, these differences in performance are often negligible.
Still, even if there would be a significant performance impact, you need to question if the performance sacrifices make sense in your context. In return for some performance, you are getting thread-safe, easy-to-maintain, understand, and test code. As engineers, it is often extremely tempting to go for the most optimal solution, using as little memory and CPU time as possible. However, for many real-world applications, the performance impact is small enough that this is not something the end user would notice. And for other engineers maintaining...