4 ms·

should be == 0? I don't like the Ruby example myself.

stouset 5y ago
Should be >= 20. 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!
- azornathogron 5y ago
  Two things... I think (?) - 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)
  - stouset 5y ago
    Yep, the `userNames` thing was my own dumb mistake while editing in a comment box and was not intended as a reflection of the language. The capacity/length issue is the actual bug I was intending to include. 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.
    - jatone 5y ago
      and its an optimization the ruby version doesn't necessarily have. you could have just as easily written: 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.
    - pipe_connector 5y ago
      I grant you that the API for capacity and length when creating a slice in Go is bad because of this exact mistake, and I believe a few of the Go authors said they regretted it and would like to change it. However, it's odd to classify this as an advantage of Ruby, because pre-allocating memory for a large slice like this has been one of the biggest single performance advantages when we moved from Python to Go, and it's effectively a one line change. For known-to-be-tiny slices we don't even bother.

Should be >= 20. 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!

azornathogron 5y ago
Two things... I think (?) - 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)
- stouset 5y ago
  Yep, the `userNames` thing was my own dumb mistake while editing in a comment box and was not intended as a reflection of the language. The capacity/length issue is the actual bug I was intending to include. 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.
  - jatone 5y ago
    and its an optimization the ruby version doesn't necessarily have. you could have just as easily written: 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.
  - pipe_connector 5y ago
    I grant you that the API for capacity and length when creating a slice in Go is bad because of this exact mistake, and I believe a few of the Go authors said they regretted it and would like to change it. However, it's odd to classify this as an advantage of Ruby, because pre-allocating memory for a large slice like this has been one of the biggest single performance advantages when we moved from Python to Go, and it's effectively a one line change. For known-to-be-tiny slices we don't even bother.