3 ms·
Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that
by marvy 12y ago
Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.
- dilap 12y agoDefinitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy. With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sane programmer would create by hand. (I wish I had it at hand, but there was an excellent post from a .NET/CLR guy a while back that went into all the crazy stuff that got instantiated just by creating one specialization of List<T>, the associated performance overheads, and the things the compiler and runtime tried to do to avoid those.)
- marvy 12y agoThat bad? Wow. I would love to read that.
- sigmaml 12y agoYou should, however, note that Go does not have inheritance. That single difference reduces the `crazy stuff' by an order of magnitude. In addition, not having inheritance also means that you do not need to take variance into account, which further reduces the complexity significantly.