Java: Arrays.stream(nums).map(n -> n * n).toArray();
Kotlin: nums.map { it * it }
Python: list(map(lambda x: x*2, nums))
C#: nums.Select(n => n * n).ToArray();
Ruby: nums.map { |n| n*2 }
Rust: nums.iter().map(|&n| n * n).collect();
Perl: map { $_ * $_ } @nums;Personally, when I'm solving a problem, I like to reach for the pre-established universally understood pattern that's built into my language. Rather than using a language that doesn't have any of those things and requires me to create my own, worse, implementation that's unique to my program (or use a random 3rd-party module of dubious quality for something basic).
> requires me to create my own
Yes, how many string contains methods are there out there, as the result of everyone having to write their own.
I feel like we've jumped out of the frying pan of the 90s' OOP craze, directly into the fire of doing the same cargo cult behavior with functional programming. Always avoid loops, always use higher-order functions. It just makes sense. If you are not provided with the shotgun spread of higher-order functions out of the box, be frustrated.
I vaguely recall reactions to Haskell in the late 90s where vitriol was spewed over the lack of inheritance and classes.
It has enums, and if you want exhaustive checking, use golangci-lint (as every good gopher should be already, considering the language ensured tooling would be easy to write) https://golangci-lint.run/usage/linters/#exhaustive
> You want functional constructs (map, filter), nope.
There are libraries for map/filter (just make sure you use one with deforestation)
> You want string array contains, nope.
Go now has slices.Contains