On the other hand, I advise you NOT to use this kind of library and write simple, fast go code most of the time, with the occasional generics helper. Why the hell would I clutter my code with, for example: https://github.com/samber/lo?tab=readme-ov-file#fromentries-...
I've had many cases in the past (not in go) where I've had to make use of that exact same function (in typescript, in F#, and in C#). it is actually quite useful when doing any amount of data manipulation (map/filter/reduce chain that often ends up into a list of key-value pairs, which then get turned into a map/dictionary of sorts).
At least in my job(s over the years), turning a flat list of db records into a more complex, nested (potentially on multiple levels) data structure before handing it off to the front-end is a very common. I've seen it done with "simple, fast code" (although not in go specifically, but in other languages), but it very quickly turned into huge messes of of long nested for loops and was very difficult to read. LINQ, Lodash, java's streams... I sincerely can't understand how go developers live without them. They make me a lot more productive both at reading and writing the code.
Part of the issue is that Go has a variety of design choices / limitations that conspire to produce different design patterns in this area than what you might see with e.g. Java.
For example: let's say we want to implement something akin to Java's Comparator interface.
Java allows interfaces to be extended with default implementations. It also allows methods to specify their own generics separate from the entire interface / class.
Thus the "comparing()" method can take in a Function<T, U> that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator<T>.
(Generics simplified a bit, there are other overloads, etc.)
There's also thenComparing(), which allows chaining Comparator instances and / or chaining Function<T, U>.
As a consequence, one can use .thenComparing() to build up a Comparator from the fields on a class pretty quickly. Especially with lambda syntax.
Go doesn't support methods having different type parameters than the overall interface / struct.
Go also doesn't have default implementations. It doesn't allow function or method overloading.
Go does have first class functions, however.
To build the equivalent capability, you'd most likely build everything around a comparison function (func[T any](a, b T) int) and write a bunch of functions to glue them together / handle useful operations.
That impacts the readability of a long chain of calls, especially since Go doesn't have a lambda syntax to make things a bit tighter.
Getting rid of the limitation on method-level generics would make this _significantly_ more ergonomic.
You wouldn't write that exact function. You'd have some complicated pipeline that ended up in a map; and it might be easier to follow the logic using map / filter / fromentries.
I strongly agree. Map / filter isn't included, but a fair number of the various utilities are included in the standard library in the `slices` and `maps` packages.
`context` also helps solve a bunch of the channel related use cases in a more elegant (IMO) way.
There are only a handful of things in that package I wish were included, such as "Keys()" on a map.
shirogane86x|2 years ago
At least in my job(s over the years), turning a flat list of db records into a more complex, nested (potentially on multiple levels) data structure before handing it off to the front-end is a very common. I've seen it done with "simple, fast code" (although not in go specifically, but in other languages), but it very quickly turned into huge messes of of long nested for loops and was very difficult to read. LINQ, Lodash, java's streams... I sincerely can't understand how go developers live without them. They make me a lot more productive both at reading and writing the code.
Zach_the_Lizard|2 years ago
For example: let's say we want to implement something akin to Java's Comparator interface.
Java allows interfaces to be extended with default implementations. It also allows methods to specify their own generics separate from the entire interface / class.
Thus the "comparing()" method can take in a Function<T, U> that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator<T>.
(Generics simplified a bit, there are other overloads, etc.)
There's also thenComparing(), which allows chaining Comparator instances and / or chaining Function<T, U>.
As a consequence, one can use .thenComparing() to build up a Comparator from the fields on a class pretty quickly. Especially with lambda syntax.
Go doesn't support methods having different type parameters than the overall interface / struct.
Go also doesn't have default implementations. It doesn't allow function or method overloading.
Go does have first class functions, however.
To build the equivalent capability, you'd most likely build everything around a comparison function (func[T any](a, b T) int) and write a bunch of functions to glue them together / handle useful operations.
That impacts the readability of a long chain of calls, especially since Go doesn't have a lambda syntax to make things a bit tighter.
Getting rid of the limitation on method-level generics would make this _significantly_ more ergonomic.
gwd|2 years ago
Zach_the_Lizard|2 years ago
`context` also helps solve a bunch of the channel related use cases in a more elegant (IMO) way.
There are only a handful of things in that package I wish were included, such as "Keys()" on a map.
mohamedattahri|2 years ago
They were included in the experimental packages on google.com/x.
mplanchard|2 years ago
c2xlZXB5Cg1|2 years ago