221–230 of 378 posts
Earlier quoted context omitted.
Shame how k8s was a failure without generics. Think what could have been.
The thing is, Google is paying most of the development costs for Go and Google controls Go too. It makes sense to adapt the language to their needs. They already do stuff like creating new network protocols because it will reduce their costs.
Earlier quoted context omitted.
And honestly, 9 times out of 10, I'm better off rebuilding the list because vectors have lower memory overhead and the memory is contiguous. But that one time... I've also been spoiled by Java's very rich set of collections.
Linked lists aren't the best example because they're almost never the right tool. But in the last month alone on a rust project I'm working on I've used: - Option, Result, and other stuff from the standard library. - My own B-Tree implementation w/ domain specific enhancements, in about 4 different contexts - A heap based priority queue - A custom 2 level vec, to support arbitrary insert & delete without shuffling el…
* manually instantiating (handrolling) every version, possibly duplicating it if you don't realise somebody else did
* same except using codegen, which is easier to maintain but has more semantic overhead (now you need to add codegen to the project and there's an extra build step to consider)
* or manually type-erase and cast back, risking type safety and most likely performances
A flagrant example from the stdlib is the `sort` package with its weird and alien interface (and Interface), inability to use key functions, and which can only work in-place.
Talking about in-place but circling back to generic structures / collections, a big use-case I expect to see for generics would be type-safe (immutable) concurrent collections e.g. HAMT, RRB, …. Current Go significantly limits the ability to "share by communicating" (as well as safely "communicate by sharing") as there's no good way to build and make any sort of high-quality concurrent collection available, whether persistent or mutable.
Earlier quoted context omitted.
There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.
I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build , and people build pretty much everything in every language, generics or not.
What syntax did Go settle on, in the end?
Earlier quoted context omitted.
Go is getting monomorphization, separate machine code for each type specialization of a generic function. I assume reflection will choose the one for the args you want to pass, or make you do that.
> I assume reflection will choose the one for the args you want to pass, or make you do that. According to the spec: > It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions. You won't be able to reflect a generic List or List[T] at all which… makes sense, I think? `reflect` works on values at runtime,…
Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX
This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?
> Generic types can have methods. The receiver type of a method must declare the same number of type parameters as are declared in the receiver type's definition. They are declared without any constraint.
// Push adds a value to the end of a vector.
func (v *Vector[T]) Push(x T) { *v = append(*v, x) }
Earlier quoted context omitted.
The thing is, Google is paying most of the development costs for Go and Google controls Go too. It makes sense to adapt the language to their needs. They already do stuff like creating new network protocols because it will reduce their costs.
Google have alternatives to k8s already. So it's more about making a market.
Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX
Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better? BTW, the readability is really not good as Go 1.
That would rather miss the point as you'd be converting the type-safe result to an unsafe version?
Go doesn't have pattern matching or any "structural" construct which would allow performing this in a single step, so the alternative would be to use HoFs and while Go has them they're quite verbose e.g.
func (o Option[T]) Then(then func(T)) {
if o.OK() {
then(*o.value)
}
}
a.Then(func (v int) { fmt.Printf("\tvalue = %d\n", v) })
An safe other option would be a method mapping to a slice of 0..1 element and you'd use a `for range` as an `if` but that seems way to clever, similar to Scala's comprehensions over everything which I rather dislike.
Also sadly the current proposal has no facilities for methods generic in their arguments independently from the subject, so no `Map` method.
Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.
Even I know (not really being a heavy C++ user) that C++ doesn't have generics, it has templates, which is a much more powerful concept that's often overused.
So… you know wrong?
Templates are a form of generics. What templates are not is an instance of parametric polymorphism.
Pretext: I love Go and write most of my day job code in it. To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. Little things like sorting will use generics pretty much transparently. All of the strongly typed code you write today that receives and returns concrete types will be just as vali…
In fairness: just because that's true doesn't mean the libraries they like or need won't be migrating to generic facilities one way or an other, so they may be forced to the choice of interacting with generics or needing to reimplement their wheels (though also in fairness that's also common in the go ecosystem).
> I think it’s important to remember that the people who design this language like it for the same reasons you do.
That's not necessarily true, the designers of the language are not necessarily designing it for their use or like. See: Rob Pike's well known quotes on the target population for Go.