261–270 of 273 posts
Earlier quoted context omitted.
Say you need a binary heap to hold some customer records, and another binary heap to store some orders. How many times do you implement a binary heap?
Apparently their answer is “five times”.
I don't know why you're all so scared of a little repetition ;)
Earlier quoted context omitted.
It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs. If your git repositories aren't tagged just so , then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequen…
Huh, interesting, thanks for the response. Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!
It would mean that you need to create Go compatible tags for your library releases OR adjust your product versions to match Go's assumptions.
The whole implementation of Go modules is a shit show once you get into the weeds.
Earlier quoted context omitted.
> I think the idea is that these fundamentals could/should be supplied by the standard library There is basically no limit to the number of data structures possible, nor to the possible implementation details of most of them, all of which can be relevant to the situation at hand. The stdlib can hardly be expected to implement them all.
If they're very specific to the situation at hand, they're much less likely to need to be generic. The GP explicitly mentioned "Linked Lists" and "Trees". You don't need to be writing your own linked-list or (basic) tree from scratch.
And graphs.
> You don't need to be writing your own linked-list or (basic) tree from scratch.
Trees are rarely useful in and of themselves, what's useful is the data structures you're building out of them. And that, in turns, informs a significant number of properties of the tree you'll be using as well as the operations to perform. The stdlib providing "a basic tree" and essentially telling users to get bent would be worse than useless, it would be actively insulting.
Even for the humble "linked list" there are half a dozen possibilities: singly linked? Immutable? Doubly-linked? Circular? Array-of-nodes?
Earlier quoted context omitted.
The any is required to avoid a syntactic ambiguity. It was that or use the "type" keyword as in Print[type T] / Print[type T1, T2 Constraint]. The question of what the syntax should look like has been beaten to death.
There is ambiguity in Print[T](t T)? What different things could T represent there?
type A[T] int
Is that a parameterized type named A with a type parameter T, or is it a definition of an array named A whose length is T?
Separately, it's nice that type parameter lists use the same syntax as non-type parameter lists.
Earlier quoted context omitted.
> Every wrapper is a thing itself which must also be understood when trying to understand how things work. I'd offer a different view. Wrapping/abstracting like this should reduce the amount of things a user of the abstraction needs to know. I don't care how Java's BigInteger class works under the hood, only that it does what I need it to do. If I did have to know how it worked to use it, this suggests a failure on t…
I'm not sure how I feel about the `set` wrapper. I suppose its nice to hide some of the detail of how the set works. On the other hand, it is confidence inspiring to be told "this is just a map, its really that simple" as a user. I have a similar conflict about string alias types like `type MyId string`.
I mean, you could support only List objects in the language and call it a day because they can be used as anything else. Or only lambdas, for the same reason. At the end of the day, though, having structures for the various ways you want to treat data is helpful. Using the right structure to hold data reduces cognitive load.
Earlier quoted context omitted.
As someone who finds "indicating intent in the code" an important thing, I must admit I find this concert slightly horrifying. A Map and a Set are two different things and which one you use conveys some intent as to what you mean by your code. I get that it works, but it would still make me unhappy to do.
> A Map [with value type = void/unit/() [0]] and a Set are two different things Not to defend Go or anything, but that's like saying: | A Array [with element type = byte/char/u8] and a String are different things It might be useful to call them different names (of course that would require Go to support generic typedefs for `type Set k = Map k Void`), but they're still fundamentally the same thing. 0: which, to be fa…
Earlier quoted context omitted.
I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.
Most of the casting in Java 1.4 was from collections of Object. In Go the collections are typed, so the casting is confined to some very specialized pieces of code.
class IntList {
private List objList;
public add(int elem) {
objList.add(Integer.of(elem));
}
}
Earlier quoted context omitted.
I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.
People from the post-1.4 era of Java aren't aware how huge code generation was before generics showed up. And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks . It is the worst solution to any problem solvable by a type system.
Earlier quoted context omitted.
Eh, even C supports clean templated type safe containers: https://www.github.com/glouw/ctl Why Go is so far behind is behind me
There is a big difference here. The draft is about adding generics to the Go stdlib, not about if it's possible. Is it even possible? Yeah, there are some implementation (e.g. https://github.com/cheekybits/genny ). So Go is not "far behind" C, which also does not have generics (or did I miss something in C11/C17?).
I've been heavy into Go the past year. I love the simple interfaces they've built over some rather complicated things (concurrency, cross-compilation, networking, etc), which really do tend to just work. I fear that Go will eventually turn into something where we look back and realize we've lost something important by gaining a lot of less importants. The impulse to change things is just too strong these days. C89 ha…