4 ms·
I am not sure where the authors exact requirements fit in the greater picture of the desired application. But one important tool which works great in Go is func
by _ph_ 9y ago
I am not sure where the authors exact requirements fit in the greater picture of the desired application. But one important tool which works great in Go is functional representation. If you want e.g. an immutable map, make it a structure with private fields, and give access vial functions (methods). The first comment to the article describes a nice example of this approach.
I often read criticism of Go which is based on a missing "feature". In my experience, implementing these features is surprisingly easy in Go, as the building blocks are all there. In this respect, Go has some resemblance on Lego :).
My background contains a lot of Scheme/Lisp, so abstracting things with functions comes natural to me. It turns out that Go has basically the equivalent function concept (first class functions, closures, ..) so enables all the powerful abstractions coming from them.
- kuschku 9y agoBut you still have to write the function a hundred times — once each for every immutable map you'll use. This is the opposite of DRY.
- 43224gg252 9y agoGo also supports libraries.
- kuschku 9y agoGo doesn’t really support libraries of data structures and containers, though. You can’t build a library of different kinds of immutable and mutable maps, trees, etc that are reusable – precisely because generics are missing.
- _ph_ 9y agoYes, if you needs lots of different immutable maps as your interface to a library, then the lack of generics is annoying. But the question is, is the immutable map such a common interface, or should your library and abstraction barrier be something else? I am a professional programmer and have prefer abstractions via objects/functions.
- PeterisP 9y agoThe author discounts this as a good solution because you'd have to re-implement the structure and functions for every single type you might put in the map; i.e. that would be a valid solution iff Go supported generics, but it does not.
- falcolas 9y agoGo's introspection tools do provide enough support to offset the lack of generics, at the cost of having to write your own type checks, and at the cost of having runtime instead of compile time type checking. But it can be done.
- nine_k 9y agoAnything Turing-complete could by definition be run on a Turing machine. But Brainf*k, a straightforward Turing machine implementation, seems less productive than almost any other language.
- krakensden 9y agoPeople say this, but it isn't really true- you could use the sort.Interface interface like everyone else. Consumer wants to use your custom map with their custom type? Make sure it supports Less. Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.
- masklinn 9y ago> People say this, but it isn't really true- you could use the sort.Interface interface like everyone else. Consumer wants to use your custom map with their custom type? Make sure it supports Less. 1. So you have a map of sort.Interface, and that's just as absolutely-not-convenient-or-type-safe as a map of interface{} 2. TFA does not want a sorted map, they want an ordered map, so sort.Interface has no relevance whatsoever: the order of iteration of an ordered map is the order of insertion, not the sort order of the elements. > Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there. Not really. Java does OK without operator overloading. Having to use methods instead of operators can be annoying in some cases (mostly when working with non-built-in numerics e.g. decimals or infinite-precision integrals) but it doesn't limit you much if it does at all.