I don't like the Ruby example myself.
I don't like the Ruby example myself.
Whether or not you like the Ruby version is beside my point, which is that which one of those is "more complicated" is a matter of perspective. The Ruby one is almost strictly a wrapper around the golang one so it does add absolute complexity. But the golang one is relatively more complex, because the Ruby version uses higher-level equivalents, and those abstractions are good enough that I don't ever have to actually reason about what happens underneath the covers.
Put another way, even the golang version is an abstraction around an absolutely massive amount of hardware and electrical engineering complexity that you virtually never have to think about. The absolute complexity of what happens when you compile and execute those instructions is extreme to the point that no single human or even room of humans collectively fully knows what's going on. And yet we manage just fine.
Or, I love this example:
admin_usernames = users.select(&:admin?).map(&:username)
Versus adminUsernames := make([]string, len(users))
for i, user := range users {
if user.isAdmin {
userNames = append(userNames, user.Name)
}
}
Again, spot the bug!- declaring `adminUsernames` and then using `userNames` (but I assume that's not what you're talking about because that won't even compile)
- you're making an array with its length N instead of length 0 capacity N
(I totally agree with your point, I just like looking for bugs)
But... also it's a mistake that's not even possible in the Ruby example due to not having to handle the "irrelevant" internal details of appending to the array, so maybe there's a point to it after all.
var names []string
for i, user := range users {
if user.isAdmin {
names = append(names, user.Name)
}
}
and hilariously it likely still would be faster than ruby. I've managed large golang and ruby projects and the difference in maintenance work between the two is insane and its not a good look for ruby.