On: Go Is a Shop-Built Jig

[spion]

No, they make the language weaker. For example, its impossible to write the `map` function in Go because of type restrictions.

In python, every function is as generic as it can be.

[lukasm → spion]

You can write map but it's a lot of boilerplate and you loose types

Map func(interface{}, func(interface{}) interface{}) []interface{}

[spion → lukasm]

You also loose the ability to pass existing functions with your implementation of Map

  Map([]string{"a", "b", "c", "d"}, ToUpper)

[nl → spion]

That isn't the case at all. The problem is that the types restrict your functions, so you either have to write a Mao function for every type you want to support, or drop the types altogether.

The situation where you drop the types is the equivalent to Python isn't it?

[spion → nl]

Its not because in Go you cannot reuse existing functions that you've written if you drop the types. In python, you can.

[mwcampbell → spion]

So, you don't write the map function in Go; you use a plain for loop. Again, Go only focuses on solving real problems, and does so in a mostly imperative style.

[polux → mwcampbell]

Map is solving the real problem of code duplication for the scenario "create a new list whose elements are the elements of the original list to which f was applied". Not only does it reduce boilerplate but when you read map(f, list) you know that the result is gonna be a new list of the same size, that if f = id you're gonna get the same list, etc. In other words, map has invariants. It captures a tiny subset of all the for loops you can write.

Saying "we don't need map, we have for", is akin to saying "we don't need toUpper, we have for loops" or "we don't need functions, we have goto".