4 ms·
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 co
by 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 agoYep, 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 agoand 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 agoI 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.