81–90 of 125 posts
Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).
Earlier quoted context omitted.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
Go can statically type check hash maps, arrays, and channels. If you want some other container type it must be written with a concrete element type in mind.
Nice work. But, serious question - When going with parameterized types I know from Haskell how you always end up needing one more language extension and always end up banging your head against the wall that separates types and values a little more. At least if you're not a math genius, but probably even then. And from Java I know that there's a pretty trivial example that showcases how its Generics implementation is…
Earlier quoted context omitted.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
What do you mean?
void do_stuff(Integer[] integers) {
....
}
do_stuff(new String[]{"1", "2", "3"})
Compiler: whoops, you passed an array of strings when the API called for an array of integers.The only time I find I need generics is when I'm prototyping things and making lots of changes. Node, Ruby, & Python are great for this. In fact, PHP's associative array is really powerful/sloppy since it can be used as a list, hash/dictionary, iterable, or object. That aside, I don't think I've ever really been bothered by the lack of generics for actual work code.
I've been working full time in Go since 2012. I've never had a use for generics.
Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
You've definitely had a use for it. Maps, chan and slices are all generic types. The built-in functions len(), make(), delete(), new(), append(), etc. are also generic. It's just that you can't define your own generic functions and types.
Earlier quoted context omitted.
Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).
Why would I need to re-implement what is already there?
Or, for another example, you can't write a generic LinkedHashMap, which is a weird data structure that allows you to write constant time LRU caches, and which I presume Go doesn't have.
Earlier quoted context omitted.
I've been working full time in Go since 2012. I've never had a use for generics.
One of my first Go programs was based on this image resizer: https://github.com/nfnt/resize/blob/master/resize.go#L109 Do you have any recommendations for how to write this code without generics, without sacrificing performance, and without hundreds of lines of duplicated code?
The constructor might be harder to abstract as a single thing since there are variations for each image type... but that's the gist of how I'd tackle it with all of my 10 minutes of experience with your code :-) If this approach is workable, it should end up being clean and testable IMO.
Earlier quoted context omitted.
How does Go statically type check collections, then? It seems like a pretty common, desirable use-case to me. I could understand not missing this if you're coming from a dynamically typed environment, but understand that many people aren't.
Umm don't? Why are you iterating over unknown types?
Earlier quoted context omitted.
Go can statically type check hash maps, arrays, and channels. If you want some other container type it must be written with a concrete element type in mind.
Wait, really? The language designers gave themselves (effective) generics and then kicked down the ladder afterwards so that other container implementers couldn't follow? That's hilarious.