5 ms·

Neither one is used like an integer though. As in, you don't really add GUIDs together¹, so there's no real benefit over a byte array or struct. 1. I guess hav

by PeCaN 10y ago

Neither one is used like an integer though. As in, you don't really add GUIDs together¹, so there's no real benefit over a byte array or struct. 1. I guess having bit mask operations for IPv6 addresses could be useful.

drfuchs 10y ago
But you do want to compare GUIDs. And hash them, which can involve shifting, adding, xor'ing, multiplying, remaindering, etc.
- Gankro 10y ago
  If you can't already hash/compare an array of bytes, something terrible has happened with your language design.
  - rickycook 10y ago
    well, you can already do operations on 128bit of data that represents and int as well, but that's a kind of silly thing to say because higher level abstractions are just about making things easier. so now you can do it in 1 operation rather than several; if that's all you gain, then it's still worth it
  - drfuchs 10y ago
    Not in a way that complies into one or two machine instructions. So, your array code is an order of magnitude or two too slow. Never mind having to write it at all. Added: I'm talking about implementing specific, optimized hash functions on 128-bit values (e.g. GUIDs, IPv6 addresses), and not generic hash functions that can take any length input (although many of them speed up linearly in the size of int that gets used internally).
    - Gankro 10y ago
      Rust isn't hashcode based. You don't define how to hash a type in that way. You define hashing algorithms which operate on arrays of bytes. All a type has to do to implement hashing is specify how to feed its bytes into a hasher. Hashers provide conveniences for feeding in a u8, u16, u32, u64, etc., but most hashers just implement this as casting the value to an array of bytes and using the generic implementation. This is because most algorithms are defined in terms of bytes. Evidently there isn't any interesting optimization to do by statically knowing you have a u32 vs a u64 for these algorithms (appears to be the case for SipHash, XXHash, and Fnv). And indeed, u128 continues this tradition in the PR: https://github.com/rust-lang/rust/pull/37900/files#diff-232730be2a8dd8895c3ab4fe291ff4d1R194 https://github.com/rust-lang/rust/pull/37900/files#diff-2327...
    - dbaupp 10y ago
      Whatever one can do on an i128, one can do "manually" on an array of bytes, e.g. coerce to a pair of u64s to avoid having to manipulate each byte individually.
      - deleted 10y ago
        [deleted]
XorNot 10y ago
Avoiding pointers to arrays is nice. This is the big annoyance in Golang with it's net.IP type - it's `type IP []byte`, which means you can write ip1 == ip2 and you can't pass by value easily, nor use it as a map key. I've ended up inventing my own type for that a lot of the time as a struct wit static fields, since those you can copy around and do 1:1 comparisons. Though to be honest I'd be super happy if there was a drop-in varint type, or you could trivially have the compiler calculate instructions for a arbitrary fixed size ints.
- dbaupp 10y ago
  Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].
  - steveklabnik 10y ago
    That's exactly how the UUID crate implements them: https://github.com/rust-lang-nursery/uuid/blob/master/src/lib.rs#L133 https://github.com/rust-lang-nursery/uuid/blob/master/src/li...
  - barsonme 10y ago
    So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.
    - dbaupp 10y ago
      I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.
      - int_19h 10y ago
        I think the point was that when it's a mere alias, you can end up passing an array of the right size and type that is not an IP address.
eropple 10y ago
IP addresses are used like integers all the time. Ask your friendly neighborhood sysadmin how a network mask works. (Maybe you want to foreach over an array every time you want to apply one. I'd rather not.)
- CuriousSkeptic 10y ago
  I realize integer has rather specific meaning in this context. But really, your comment just highlights the issue. In my world integer is a mathematical construct with no particular representation, making things like bitmasks and or shifts nonsensical. If you really want to work with fixed length bitstrings why not just have a type for that? Operating on a string of 128-bits should be valid on all such bitstrings no matter wether those represent a number or a string of code points. And equally operations on integers should not care about particular bitstrings representations of the number in question.
  - eropple 10y ago
    > In my world integer is a mathematical construct with no particular representation Your world doesn't map to the reality of silicon and registers, whereas Rust does. As it happens, you can be fixed much more easily than the whole of modern computing. > If you really want to work with fixed length bitstrings why not just have a type for that? I don't. I want to work with integers. An IPv6 address is not the hex format that you read--it is a 128-bit integer. You can go read RFC 2460 if you don't believe me, but it's true. It is an integer that I can add and subtract from; I don't add 1 to an octet of an IP address and then do a bunch of carries if I want the next IP address in my network, I add 1 to the IP address. I don't perform some magic operation to determine what a subnet looks like, I bitand the integer. They are inescapably based on the representation used both by my computer and by my network hardware. (As is the performance of both my network hardware and yours. There's a reason that your router doesn't use BCD or whatever.) There are programming languages that do not represent the underlying system. They are, for the most part, bad at dealing with the kinds of problems Rust is tailored to effectively represent. You can use those. It's pretty presumptuous to suggest that languages designed for lower-level problems accommodate your peculiarity.
- 10y ago

by PeCaN 10y ago

drfuchs 10y ago

But you do want to compare GUIDs. And hash them, which can involve shifting, adding, xor'ing, multiplying, remaindering, etc.

Gankro 10y ago
If you can't already hash/compare an array of bytes, something terrible has happened with your language design.
- rickycook 10y ago
  well, you can already do operations on 128bit of data that represents and int as well, but that's a kind of silly thing to say because higher level abstractions are just about making things easier. so now you can do it in 1 operation rather than several; if that's all you gain, then it's still worth it
- drfuchs 10y ago
  Not in a way that complies into one or two machine instructions. So, your array code is an order of magnitude or two too slow. Never mind having to write it at all. Added: I'm talking about implementing specific, optimized hash functions on 128-bit values (e.g. GUIDs, IPv6 addresses), and not generic hash functions that can take any length input (although many of them speed up linearly in the size of int that gets used internally).
  - Gankro 10y ago
    Rust isn't hashcode based. You don't define how to hash a type in that way. You define hashing algorithms which operate on arrays of bytes. All a type has to do to implement hashing is specify how to feed its bytes into a hasher. Hashers provide conveniences for feeding in a u8, u16, u32, u64, etc., but most hashers just implement this as casting the value to an array of bytes and using the generic implementation. This is because most algorithms are defined in terms of bytes. Evidently there isn't any interesting optimization to do by statically knowing you have a u32 vs a u64 for these algorithms (appears to be the case for SipHash, XXHash, and Fnv). And indeed, u128 continues this tradition in the PR: https://github.com/rust-lang/rust/pull/37900/files#diff-232730be2a8dd8895c3ab4fe291ff4d1R194 https://github.com/rust-lang/rust/pull/37900/files#diff-2327...
  - dbaupp 10y ago
    Whatever one can do on an i128, one can do "manually" on an array of bytes, e.g. coerce to a pair of u64s to avoid having to manipulate each byte individually.
    - deleted 10y ago
      [deleted]

XorNot 10y ago

Avoiding pointers to arrays is nice. This is the big annoyance in Golang with it's net.IP type - it's `type IP []byte`, which means you can write ip1 == ip2 and you can't pass by value easily, nor use it as a map key. I've ended up inventing my own type for that a lot of the time as a struct wit static fields, since those you can copy around and do 1:1 comparisons. Though to be honest I'd be super happy if there was a drop-in varint type, or you could trivially have the compiler calculate instructions for a arbitrary fixed size ints.

dbaupp 10y ago
Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].
- steveklabnik 10y ago
  That's exactly how the UUID crate implements them: https://github.com/rust-lang-nursery/uuid/blob/master/src/lib.rs#L133 https://github.com/rust-lang-nursery/uuid/blob/master/src/li...
- barsonme 10y ago
  So does Go, so a net.IP could be [16]byte or [4]byte, but I'm sure you can see the obvious problems that might occur there (with having two separate IP types). Most UUID libraries I've seen and written use [16]byte as the concrete UUID type.
  - dbaupp 10y ago
    I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.
    - int_19h 10y ago
      I think the point was that when it's a mere alias, you can end up passing an array of the right size and type that is not an IP address.

eropple 10y ago

IP addresses are used like integers all the time. Ask your friendly neighborhood sysadmin how a network mask works. (Maybe you want to foreach over an array every time you want to apply one. I'd rather not.)

CuriousSkeptic 10y ago
I realize integer has rather specific meaning in this context. But really, your comment just highlights the issue. In my world integer is a mathematical construct with no particular representation, making things like bitmasks and or shifts nonsensical. If you really want to work with fixed length bitstrings why not just have a type for that? Operating on a string of 128-bits should be valid on all such bitstrings no matter wether those represent a number or a string of code points. And equally operations on integers should not care about particular bitstrings representations of the number in question.
- eropple 10y ago
  > In my world integer is a mathematical construct with no particular representation Your world doesn't map to the reality of silicon and registers, whereas Rust does. As it happens, you can be fixed much more easily than the whole of modern computing. > If you really want to work with fixed length bitstrings why not just have a type for that? I don't. I want to work with integers. An IPv6 address is not the hex format that you read--it is a 128-bit integer. You can go read RFC 2460 if you don't believe me, but it's true. It is an integer that I can add and subtract from; I don't add 1 to an octet of an IP address and then do a bunch of carries if I want the next IP address in my network, I add 1 to the IP address. I don't perform some magic operation to determine what a subnet looks like, I bitand the integer. They are inescapably based on the representation used both by my computer and by my network hardware. (As is the performance of both my network hardware and yours. There's a reason that your router doesn't use BCD or whatever.) There are programming languages that do not represent the underlying system. They are, for the most part, bad at dealing with the kinds of problems Rust is tailored to effectively represent. You can use those. It's pretty presumptuous to suggest that languages designed for lower-level problems accommodate your peculiarity.
10y ago