stared at it for a bit and im mostly certain i prefer it to java. at least writing other go = its not bad for me to break apart the signature line on a generic
replyjava feels kinda unhinged the more that i look at it
public static <T extends Comparable<? super T>> T max(Collection<? extends T> c)
Map<String, List<Map<Integer, Optional<Pair<String, Function<? super List<? extends Comparable<?>>, ? extends Map<String, ?>>>>>>> config;
It is verbose but inference helps a lot to keep it “tidy”. I always find myself increasing my focus a notch when I start dealing with generics. It’s one of the things I use only if I really “need”.
replyOne of the reasons it took so long to implement generics in Go was because there was a lot of stuff you could do that didn't need it. Now that generics are there, a lot of that stuff is still the best way to solve the problem and many of the methods that require generics are in the standard library so it's rare that you absolutely need it.
replyYeah, I agree with that.
replyBack when Go's generics came out, I was working with about 20% Go and 80% Python. I looked at the syntax, went "not today, Satan" and never bothered to learn it. For the past half year I've been in a mode where most of my coding time is spent with Go and I've been completely indoctrinated. I unironically like thinking about how generics and interfaces interact now.
I also need to slow down when I need to use them for non-trivial stuff. Not just relative to Go code but relative to how much I needed to think about them back when I was using OCaml. I think part of it is that I save them for hard issues and use interfaces for easy stuff.
It does, but at the same time it's not "normal" code; I see it much like Typescript's advanced types, ultimately it's something that mainly lives in libraries.
replyimho it is much better that C++ equivalent
reply