I agree with your point, but you'll have to update your example of something go can't do

> having to write a for loop to get the list of keys of a map

We now have the stdlib "maps" package, you can do:

   keys := slices.Collect(maps.Keys(someMap))

With the wonder of generics, it's finally possible to implement that.

Now if only Go was consistent about methods vs functions, maybe then we could have "keys := someMap.Keys()" instead of it being a weird mix like `http.Request.Headers.Set("key", "value")` but `map["key"] = "value"`

Or 'close(chan x)' but 'file.Close()', etc etc.

▲ lisbbb 3 days ago | parent | next [-]

I haven't use Go since 2024, but I was going to say something similar--seems like I was pretty happy doing all my Functional style coding in Go. The problem for me was the client didn't want us to use it. We were given the choice between Java (ugh) and Python to build APIs. We chose Python because I cross my arms and bite my lip and refuse to write anymore Java in these days of containers as the portability. I never really liked Java, or maybe I never really like the kinds of jobs you get using Java? <-- that

▲ morsecodist 3 days ago | parent | prev | next [-]

Fair I stopped using Go pre-generics so I am pretty out of date. I just remember having this conversation about generics and at the time there was a large anti-generics group. Is it a lot better with generics? I was worried that a lot of the library code was already written pre-generics.

	▲	TheDong 3 days ago \| parent [-]
		The generics are a weak mimicry of what generics could be, almost as if to say "there we did it" without actually making the language that much more expressive. For example, you're not allowed to write the following: `type Option[T any] struct { t T } func (o Option[T]) Map[U any](f func(T) U) *Option[U] { ... }` That fails because methods can't have type parameters, only structs and functions. It hurts the ergonomics of generics quite a bit. And, as you rightly point out, the stdlib is largely pre-generics, so now there's a bunch of duplicate functions, like "strings.Sort" and "slices.Sort", "atomic.Pointer" and "atomic.Value", quite possible a sync/v2 soon https://github.com/golang/go/issues/71076, etc. The old non-generic versions also aren't deprecated typically, so they're just there to trap people that don't know "no never use atomic.Value, always use atomic.Pointer".

▲ diarrhea 3 days ago | parent | prev | next [-]

> Now if only Go was consistent about methods vs functions

This also hurts discoverability. `slices`, `maps`, `iter`, `sort` are all top-level packages you simply need to know about to work efficiently with iteration. You cannot just `items.sort().map(foo)`, guided and discoverable by auto-completion.

▲ metaltyphoon 3 days ago | parent | prev [-]

> Now if only Go was consistent about methods vs functions

Generics can only be on function and not methods because of it's type system. So don't hold your breath and modifying this would be a breaking change.