| ▲ | RadiozRadioz 4 hours ago |
| So instead we have 10 different libraries and 100 different custom implementations to do those things in Go. Compared to almost every other major language where you can do functional stuff (and everything else the Go developers decided we didn't need) natively: 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;
|
|
| ▲ | desumeku 4 hours ago | parent | next [-] |
| Rob Pike has talked before[1] on this exact subject, about how all languages are merging into one giant PL-theory sludge where every camp is adding and stealing features from one another, and that one of purposes of Go was to avoid following in this same direction. [1]: https://youtu.be/_cmqniwQz3c?t=34 |
| |
| ▲ | RadiozRadioz 4 hours ago | parent [-] | | Fair enough. I agree with the sentiment that we need diversity in languages. 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). | | |
| ▲ | coin 4 hours ago | parent [-] | | Agree. Removing useful features in the name of diversity seems silly. > 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. |
|
|
|
| ▲ | johnnyjeans 4 hours ago | parent | prev [-] |
| You could just use a for-statement, you know. I feel like there's a reactionary avoidance to iteration to the point that it doesn't really make sense. 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. |
| |
| ▲ | coin 4 hours ago | parent | next [-] | | Loops are just clutter. I’d rather concentrate on the filter and transform and not be bothered with the raw mechanics of looping, creating an intermediate array and appending to it. Not to mention that some languages returns a lazy evaluated view of the original storage. | |
| ▲ | RadiozRadioz 4 hours ago | parent | prev [-] | | In my particular example, these were of course deliberately simple snippets to illustrate the point. The power comes in chaining these things, .map.filter.reduce... . Using iteration, you end up writing a lot of boilerplate that is much harder to parallelise, and extremely difficult to lazily evaluate. Without these constructs, to express "the concept of filtering & reducing an array", the reader of your program needs to read how you implemented those things, in addition to what you're using them for. You can do that stuff yourself in goroutines, but there is no contest to having native support for these extremely common operations. |
|
