4 ms·

> Not in the slightest. You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing t

by gwd 2y ago

> Not in the slightest. You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing to the discussion. I like Go and use it extensively; and I like having the option to fall back to the `any` type. But it's simply a fact that using the `any` type means that certain properties of the program can't be checked at compile time, in the same way that Python isn't able to check certain properties of the program at compile time. > If you want to compare it to something, it's more like Rust's unwrap(), which will panic if you apply it to the wrong result. Rust's unwrap() is used when a type can have one of exactly two underlying types (which is why no type is specified). In this case, getting back an `any` type means the underlying type could literally be anything -- as demonstrated by the example, where they put an integer, a string, and an empty struct into the pool. That's almost certainly not what you wanted, but the compiler won't prevent you from doing it.

tgv 2y ago
Sorry, but comparing Python's total absence of typing to extracting a value from any is quite weird. > certain properties of the program can't be checked at compile time Neither can you check if a number is positive or negative, or if a string is empty or not at compile time, but that doesn't make Go similar to COBOL or Forth. `var v any` declares v to be of the type any, not of any arbitrary type, which is what Python does. Writing `v + 1` gives a compiler error, unlike Python, which may or may not turn it into a runtime error. It is rather different, and especially so when you look at interfacing. Even though you may declare a variable to be an integer in Python, there is no guarantee that it actually is, whereas in Go that is the case, which has significant implications for how you handle e.g. json. > the compiler won't prevent you from doing it. It will prevent you from using e.g. an array of strings as if it were an array ints. Python does not. They are quite different. > You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing to the discussion. Ffs.
- sophacles 2y ago
  Python doesn't have "total absense of typing". It doesn't have static typing, so compile time checks are not possible (well historically, there's some psuedo static typing things these days). The fact that you can call `+` on some objects but not others is literally the result of the objects being different types. A truly typeless language (or maybe more accurately single type for everything language) is ASM, particularly for older CPU designs. You get a word - the bitfield in a register, and can do any operation on it. Is that 64 bits loaded from an array of characters and the programmer intended it to be a string? Cool you can bitwise and it with some other register. Was it a u64, a pointer, a pair of u32s? Same thing - the semantics don't change.
  - tgv 2y ago
    The language itself is practically devoid of restrictions on data types. There only are standard lib functions that check the type of their arguments.
9rx 2y ago
> But it's simply a fact that using the `any` type means that certain properties of the program can't be checked at compile time Yes, structural typing removes the ability to check certain properties at compile-time. That doesn't make it typed like Python, though.
- int_19h 2y ago
  "any" is not structural typing.
  - 9rx 2y ago
    any isn't a special type. It is an alias for interface{}. The empty set is trivially satisfied by all types, but obviously can be narrowed as you see fit.
    - int_19h 2y ago
      I know, but having a type that is a supertype of everything is still not structural typing. Structural typing naturally has such a type, yes, whereas with nominal type systems it has to be explicitly introduced - but that still happens often enough, e.g. object in Python or System.Object in C#. OP's point was that `any` in Go is much akin to duck typing in Python because in both cases the type check happens at runtime at the moment you're about to use the object. Yes, in Go, technically there's a separate step of downcasting to some interface type before you invoke the members, and it's that downcasting which fails, but c'mon, this is a pedantic distinction without a meaningful difference in practical usage scenarios of `any` to work around language limitations. The relevant thing is that it has all the same downsides.

by gwd 2y ago

tgv 2y ago

Sorry, but comparing Python's total absence of typing to extracting a value from any is quite weird. > certain properties of the program can't be checked at compile time Neither can you check if a number is positive or negative, or if a string is empty or not at compile time, but that doesn't make Go similar to COBOL or Forth. `var v any` declares v to be of the type any, not of any arbitrary type, which is what Python does. Writing `v + 1` gives a compiler error, unlike Python, which may or may not turn it into a runtime error. It is rather different, and especially so when you look at interfacing. Even though you may declare a variable to be an integer in Python, there is no guarantee that it actually is, whereas in Go that is the case, which has significant implications for how you handle e.g. json. > the compiler won't prevent you from doing it. It will prevent you from using e.g. an array of strings as if it were an array ints. Python does not. They are quite different. > You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing to the discussion. Ffs.

sophacles 2y ago
Python doesn't have "total absense of typing". It doesn't have static typing, so compile time checks are not possible (well historically, there's some psuedo static typing things these days). The fact that you can call `+` on some objects but not others is literally the result of the objects being different types. A truly typeless language (or maybe more accurately single type for everything language) is ASM, particularly for older CPU designs. You get a word - the bitfield in a register, and can do any operation on it. Is that 64 bits loaded from an array of characters and the programmer intended it to be a string? Cool you can bitwise and it with some other register. Was it a u64, a pointer, a pair of u32s? Same thing - the semantics don't change.
- tgv 2y ago
  The language itself is practically devoid of restrictions on data types. There only are standard lib functions that check the type of their arguments.

9rx 2y ago

> But it's simply a fact that using the `any` type means that certain properties of the program can't be checked at compile time Yes, structural typing removes the ability to check certain properties at compile-time. That doesn't make it typed like Python, though.

int_19h 2y ago
"any" is not structural typing.
- 9rx 2y ago
  any isn't a special type. It is an alias for interface{}. The empty set is trivially satisfied by all types, but obviously can be narrowed as you see fit.
  - int_19h 2y ago
    I know, but having a type that is a supertype of everything is still not structural typing. Structural typing naturally has such a type, yes, whereas with nominal type systems it has to be explicitly introduced - but that still happens often enough, e.g. object in Python or System.Object in C#. OP's point was that `any` in Go is much akin to duck typing in Python because in both cases the type check happens at runtime at the moment you're about to use the object. Yes, in Go, technically there's a separate step of downcasting to some interface type before you invoke the members, and it's that downcasting which fails, but c'mon, this is a pedantic distinction without a meaningful difference in practical usage scenarios of `any` to work around language limitations. The relevant thing is that it has all the same downsides.