In most real world applications, the cost of doing an in-memory data manipulation like this is negligible compared to I/O, waiting for the database etc. It's already the wrong language for someone who wants to squeeze out every CPU cycle, and imo it's a Good Thing for a language upgrade to embrace its strengths ie syntax sugar in the case of Ruby, as long as the perf hit isn't out of control.
I'd agree developers should pick the right data structure for the job and some APIs can obscure the cost to the point of misleading developers into woefully wrong decisions. I just don't think it's the case with array ops like union as it's easy enough to handle them efficiently. I too would be interested to see any benchmarks though.
I might be more receptive to this if this was added to all collections, then, rather than just arrays. (Maybe it was? I don’t write Ruby, so I don’t know for sure. Maybe Ruby doesn’t have a generic “collection” protocol?)
Interesting point. Ruby has an Enumerable module, but these methods were added only to Array. Since the main native collections (Set/Hash/Array) all support them now, they could probably be added to Enumerable in the future, with class-specific optimizations if necessary.
I'd agree developers should pick the right data structure for the job and some APIs can obscure the cost to the point of misleading developers into woefully wrong decisions. I just don't think it's the case with array ops like union as it's easy enough to handle them efficiently. I too would be interested to see any benchmarks though.