181–190 of 261 posts
Earlier quoted context omitted.
Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.
It comes up in Scala. The solution is to have notation to specify the variance of types.
Earlier quoted context omitted.
Yes, though Scala can hardly be an example of simplicity.
I don't think it's the simplest language out there but its parametric polymorphism is quite straightforward
Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…
What is your point? Serious question. If you tell me, for example, that Go generics are going to be like C# generics, then I have to be familiar with the full semantics of C# generics. Essentially you tell me that in order to understand X I have to understand Y first, that's not good. Consumers of your language are not, for the MOST part, PLT nerds.
Chiming in here as a Swift dev - I find its generics system incredibly helpful and end up writing something that uses generics about once a month. To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable.
Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing. That said, I do want generics to come to Go, just... with an emphasis on what Go is, not…
I know how to use them. They are valuable to me.
I think another area of Go that could use improvements is a more portable standard library optimised for embedded and OS dev. A lot of people want to use Go as a "systems language" and do drivers etc. in it. But the standard library don't have good support for freestanding, or at least it's not a priority. C and Rust and other languages designed for usage in a non-hosted environment have very clear delineated areas o…
"Go's runtime by default assumes the presence of an operating system." It also assumes the existence of several megabytes of runtime and enough RAM to feasibly use GC, which if nothing else is probably a real mess when it comes to drivers. What you probably need, rather than being a second-class citizen of the main Go language indefinitely, is a separate dialect that is close to Go, but can go its own way if it makes…
Not certain I like that this is now valid Go: func Foo (type T) (t T) (t T, err error) { … } Seems like an awful lot of parentheses in a single line! It's a bit tricky to read, because 'generic function' here means something subtly different from what 'generic function' means in CLOS …
func (a A) Foo(x int) (n int, err error) { … }
func Foo(type T)(t T) (t T, err error) { … }Earlier quoted context omitted.
Must every popular language evolve into C++ or Common Lisp?
I wonder if there's room for a language that is small, allows for nearly limitless abstraction, and still has great tooling. Go is (or, you could argue, was) small, and now has better tooling, but is just beginning to increase its ability to create abstractions. Common Lisp is large (only 200 pages fewer in its spec than C++, if I remember correctly), has unparalleled tooling (like the don't-unwind-the-stack debuggin…
Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…
Part of the explicit goal stated by the go team is that generics must still feel like go. If you slapped java generics onto go it would not feel like go.
Earlier quoted context omitted.
You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.
a := Bar(baz)(buzz) Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.
Earlier quoted context omitted.
Which interfaces-based solution? The one used by sort is a hack that only works for some of the things that you would want to do. The one where you use introspection performs badly and isn't typesafe. The tree implementation in the article cannot be done in a safe and performant way in Go today.
The one mentioned in the article. It's not a hack: it's a runtime equivalent that requires that your type implements some interface.
Find smallest/largest element in slice
Find average/standard deviation of slice
Compute union/intersection of maps
Find shortest path in node/edge graph
Apply transformation function to slice/map, returning new slice/map
Sets
Self-balancing trees, with efficient insertion and traversal in sorted order
Multimaps, with multiple instances of a key
Concurrent hash maps, supporting parallel insertions and lookups with no single lock