2 ms·
The problem is that if you're writing code that you want to be as fast as possible, then you're going to want to pin down the size of those integers to be as sm
by Sanddancer 12y ago
The problem is that if you're writing code that you want to be as fast as possible, then you're going to want to pin down the size of those integers to be as small as possible in order to let the compiler take advantage of the vector units found in modern processors. For example, if you're writing a lot of graphics code, not only are you going to be wasting space if you're giving every color channel of every variable 64 bits (8 bytes) of space, but you're going to be giving up a lot of performance, because the compiler has a lot fewer hints when it tries to autovectorize your code. Or, as another example, if you're writing a low-level networking library, then things like byte-level alignment matter. Reducing the integral types may make it simpler, but makes the language itself a lot less useful.
- kornakiewicz 12y agoYeah, I totally understand why there's a place for uint8 and int64, but wonder why I have to write x := uint64(a)+b // b is uint64 and x also will be instead just x := a+b, because type of x is still clear and casting could be done invisibly. But after rethinking the issue I agree with you that's good idea, just hadn't meet place for this in my pet projects.
- Sanddancer 12y agoThere, I think the question is what type is (a). We're starting to get into the philosophy of languages here, regarding how much of a push between implicit and explicit we want. Are we expecting variable a to be pushed up into uint64 size in the intermediary? or are we expecting (b) to be pushed down to (a)'s size before adding them together. To be honest, I personally prefer C#'s model, where one can define explicit and implicit conversions, and handle accordingly, but can see the merits of go's tack in guaranteeing obviousness, even if it means typing a bit extra.