Man... Go could have been so good.
Instead it just takes all the problems that exist in programming and pretend they don't exist.
"How big is an array?" "An int big!" "...a signed int?" "Yeah sure why not." "What happens if your array is 2049 MB long on a 32-bit platform?" "*shrug*"
@icefox in my imaginary "C, but better," there would be an explicit difference between "native"-sized ints and explicitly-sized ints. Both are useful in different cases.
@icefox For me it would be more, explicit size for net/disk/other comms and where the precision/size is important, and native everywhere else where I don't care. As long as there's the option. I've considered making a few #defines so I could have this in C already, but the library interoperability would make it confusing.
@impiaaa Yeah, except you always care, because numerical overflows/underflows are almost always unchecked and almost never what you want.
"Don't care" is i32, or f64, or i64 if you want. Because then you don't *have* to care. It will never act differently from one platform to another, and how it will act is always exactly how you want it to act. You will never get fucked over by it unexpectedly.
@impiaaa "This isn't going to be a problem" just means it's not a problem until someone else touches it and does something unexpected, or it means the size invariants are enforced by something other than the compiler (loading a known file format, for example).
@impiaaa yeah, native-sized ints are for array indices and pointers. Explicit ints are for everything else.
Rust does this and it is actually kinda wonderful.