6 ms·
>This just leads to people rolling their own [containers] Nah, Go was careful to make that impossible. (You know exactly what I'm talking about, I'm not going
by logicallee 9y ago
>This just leads to people rolling their own [containers]
Nah, Go was careful to make that impossible. (You know exactly what I'm talking about, I'm not going to come out and say it. What one, specific thing makes rolling your own container in Go literally impossible?)
- Waterluvian 9y agoClasses (inheritance)? (I'm actually guessing... This isn't my domain)
- dmoy 9y agoI'm guessing they meant generics? Also not sure.
- logicallee 9y agoYes, that is what makes it literally impossible to roll your own container.
- kasey_junk 9y agoThey meant generics. But it’s not impossible, it’s tedious.
- paulddraper 9y agoGenerics. You can't write good containers without generics. And it's the #1, #2, and #3 Go issue that people complain about. (Unless of course you do code generation...but then you're not writing Go, you're writing a program that writes in Go.)
- logicallee 9y agoyes. no idea why I'm being downvoted so heavily. you can't write your own containers today.
- gitgud 9y agoIs it concurrency issues, race conditions?
- deleted 9y ago[deleted]
- masklinn 9y agoIt's userland generics. Containers are the level 0 of generic data structures: not only is an "array" significantly less useful than an "array of T" it also leads to loss of safety (you may intend your array to be an array of int, but codegen aside there's nothing precluding a user from shoving a string in there) inefficiencies (since the type of values must be erased you need an indirection, usually a pointer) and usercode-complexity (the user needs to downcast all values to the data type they hope they are).
- lobster_johnson 9y agoNot impossible. People use code generation for this a lot.
- cortesoft 9y agoCode generation is cheating, and doesn't really count.
- lobster_johnson 9y agoWhat exactly does "cheating" mean, and why doesn't it count if it solves a problem? With generics, the compiler will internally generate type-specific implementations for each instantation, so the end result is the same. I'm not arguing against generics at all (I wish Go had it), but I'm also not sympathizing with this response.
- logicallee 9y agoIt's not cheating, but you haven't rolled your own container: because in the end you don't have one. Let's make an analogy. Suppose a language didn't have tail recursion, but by using goto you could "roll your own." So we're on the same page, right? you get what I'm saying, and how rolling your own might look and work, right? Now suppose I said that without goto, it is literally impossible to roll your own tail recursion. (ignore whether this is true it's just an analogy.) You are saying, no it's not: you can patch the generated executable, so as long as it is possible to patch executables using go (i.e. if it can read and write binary files), then you can roll your own tail recursion even without goto, through binary patching post compilation. It might just be tedious or special-cased to one specific file but you can do it (you're saying) See the difference? It's not that patching an executable is "cheating." It's just that it's outside of the definition of rolling your own tail recursion. Likewise it's not that source code generation is "cheating." It's just outside the definition of rolling your own container. it's simply not what rolling your own means. after you've done it, you don't have a container. my analogy is a bit leaky but I think it gives insight, and I hope you see what I mean.