7 ms·

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that

• pkulak 8y ago
  You are not crazy, and it's what makes this proposal even more appropriate than other languages. "int" is already a magic type.
• nwmcsween 8y ago
  Its not crazy, its defined by the system ABI, C, C++ has this too in that can be whatever depending on the ABI, hell char can be 32 bits.
• Sharlin 8y ago
  It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.
  • user5994461 8y ago
    C only defines char, short, int has having a minimum size of 8, 16 and 32 bits.
    • mrb 8y ago
      Actually C defines the minimum size of "int" as 16 bits, because it defines the minimum range it should support as [-32768 .. 32767] See https://en.wikipedia.org/wiki/C_data_types https://en.wikipedia.org/wiki/C_data_types
      • shric 8y ago
        Nit: [-32767 .. 32767] C permits ones' complement and sign-and-magnitude as well as two's complement.
    • jstimpfle 8y ago
      no, int is 16 bits minimum
  • WakiMiko 8y ago
    Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.
    • friday99 8y ago
      Yeah, that makes sense because you need some type to span the address space and that depends on the size of the address space. That is what int is used for in go, though why they chose signed rather than unsigned is confusing. unsigned you would never have to do negative bounds checks and you can prove a lot of other useful things if you know your index is always positive.
      • earenndil 8y ago
        I don't know how go does it, but in some languages negative indices count backwards from the rear end. E.G. myarr[-1] == myarr[myarr.length-1].
  • lemoncucumber 8y ago
    Right, 64-bit Windows has 32-bit int and long and 64-bit long long (LLP64) while 64-bit unixes generally have 32-bit int and 64-bit long/long long (LP64).
• jerf 8y ago
  "int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints. Probably a good linter idea in there somewhere.
  • kbirkeland 8y ago
    I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.
    • pxia 8y ago
      Because you want to represent errors. For example a find() function that returns the index of some element: you want to return -1 when the element doesn't exist.
      • growse 8y ago
        Shouldn't idiomatic go return an error instead? Magic number ranges for errors always seemed a bit old-fashioned.
        • pxia 8y ago
          It's just an example... Another example would be you want to iterate your array in reverse. The normal `for (uint i=size-1; i >= 0; i--)` won't work.
          • growse 8y ago
            That example doesn't work precisely because you're conflating the concept of the loop counter (which type represents an integer that needs to be able to go <0) with the array index accessor. There's no reason for these two things to be the same type, it's just a pattern that accidentally works because we allow arrays to be accessed using a type that represents negative numbers. What would be a more compelling argument is to use int in the same way that python does - a negative accessor means offset from the end of the array, not the start. I'm not sure golang lets you do this though...?
• throwaway34241 8y ago
  Which would you choose instead? To default to 32 bits (even on 64 bit systems) or to default to 64 bits (even on 32 bit systems). Defaulting to 64 bit math on 32 bit systems will have a huge performance penalty on generally the slowest/oldest systems where this penalty is least desirable. It's not clear to me what the benefit to this would be for most programs. Running 32 bit ints on 64 bit systems will cause problems handling large arrays on systems with a lot of memory. I think it also complicates generating efficient loop code, although C++ gets around this with signed integer overflow being "undefined behavior". Of course Go has int64 and int32 types if you want to use them (and all conversions require explicit casting), but the default type for array lengths etc is the platform native type. But what is the better alternative?
  • toyg 8y ago
    The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.
    • throwaway34241 8y ago
      Even if it's OK to degrade the performance of a small minority of users, is there a big benefit to emulating 64 bit ints everywhere on 32 bit hardware? (I'm not saying there isn't a benefit, just that it's not clear to me what it is). I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...). If at some point in the future 32 bit systems become totally irrelevant for Go users, maybe a release of Go could drop support for it altogether and make int an alias for int64, and save people some type casts. 32 bit systems probably aren't at that point yet though.
      • coldtea 8y ago
        >I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...). Well, 16 bit would also be possible if someone took the effort. Perhaps it just shouldn't be encouraged.
• icedchai 8y ago
  Yeah, sounds crazy. It only worked for C for 40+ years...
  • usrusr 8y ago
    Ignoring the basic int type and using a zoo of preprocessor defines instead is what has worked for C all that time. But I still think that native types have their place. It can often be quite reasonable to accept serious limitations on narrow machines where the performance gains won by the trade-off are desperately needed, lift those limitations on wider machines and grant an enormous safety margin on the widest architectures. When you dive deeper, the values where this makes sense still tend to be "index-like", as GP stated, but they don't have to strictly be indexes (e.g. IDs, a wider machine will be capable of working on bigger datasets and therefore be more likely to exhaust a given width of IDs, all indexes are identifiers but not all identifiers are indexes)
    • geezerjay 8y ago
      > Ignoring the basic int type and using a zoo of preprocessor defines My C is a bit rusty but why should #defines be used in this scenario? A typedef set in a config.h.in is more than enough to meet the requirements of this usecase.
      • icedchai 8y ago
        Why do you need your own typedef? stdint.h is available, if you're using a compiler from the past couple of decades at least.
  • johncolanduoni 8y ago
    And what percentage of programs written in those 40 years are actually able to run on systems with more than one or two different memory layouts?
• AsyncAwait 8y ago
  Why is that a problem? There's int8/16/32/64 for when you need to be specific.
• Too 8y ago
  Crazy indeed. This was like lessons learned #2 from C, which later introduced the stdint types int32_t et. al. A modern language with this type of confusing and platform dependent behavior is inexcusable. By all means, include a native data type as big as the processor can handle (size_t), but don't call it int which is the default data type most people will use out of pure laziness.