3 ms·

When I was playing around one of most irritating thing in Go was that I need to write a lot of type conversions, especially since there's eight "normal" integer

When I was playing around one of most irritating thing in Go was that I need to write a lot of type conversions, especially since there's eight "normal" integer types. In my opinion, for sake of simplicity it could be reduced.

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 ago
  Yeah, 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 ago
    There, 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.
enneff 12y ago
To be fair, it's rare to use anything but int and float64 in most programs, and it's exceedingly rare to use anything more than a couple of different precision integer types (unless you're writing a binary codec or something). I don't think you mean "simplicity" here. What's simpler than forcing the programmer to say what they mean? Perhaps you mean "convenience".
- k__ 12y ago
  But it's those problems that keep me away from static typed languages. When I had to use Java for a project, most of the time I was casting objects around, because libA didn't use stuff libB needed etc.
  - lmm 12y ago
    Java is far from state of the art (which is fine, it has different priorities). In Haskell/Scala/F#/OCaml the language can do a lot more of the typing for you, without sacrificing any of the safety advantages.
  - enneff 12y ago
    The Java ecosystem is pretty painful like that. Go's ecosystem is a lot more consistent, in my experience. Honestly, the difficulty expressed by the GP here is way oversold. I spent a decade using dynamically typed languages and I slid into Go with little difficulty. I really appreciate static typing now.

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 ago
Yeah, 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 ago
  There, 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.

enneff 12y ago

To be fair, it's rare to use anything but int and float64 in most programs, and it's exceedingly rare to use anything more than a couple of different precision integer types (unless you're writing a binary codec or something). I don't think you mean "simplicity" here. What's simpler than forcing the programmer to say what they mean? Perhaps you mean "convenience".

k__ 12y ago
But it's those problems that keep me away from static typed languages. When I had to use Java for a project, most of the time I was casting objects around, because libA didn't use stuff libB needed etc.
- lmm 12y ago
  Java is far from state of the art (which is fine, it has different priorities). In Haskell/Scala/F#/OCaml the language can do a lot more of the typing for you, without sacrificing any of the safety advantages.
- enneff 12y ago
  The Java ecosystem is pretty painful like that. Go's ecosystem is a lot more consistent, in my experience. Honestly, the difficulty expressed by the GP here is way oversold. I spent a decade using dynamically typed languages and I slid into Go with little difficulty. I really appreciate static typing now.