6 ms·

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

hota_mazi 9y ago
No, it's not safe. It's basically a way to disable compiler checks, so it is by definition, not safe.
- majewsky 9y ago
  It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory). var x int = 5 var i interface{} = &x *(i.(*string)) = "boom"
  - pjmlp 9y ago
    True, now imagine that program was controlling some kind of device and due to the panic it wasn't able to turn the device off.
    - Vendan 9y ago
      That's "shitty programmer", not bad language. You can catch panics, and there's a panic safe "val, ok := ival.(type)" assertion.
    - kazinator 9y ago
      Same thing could happen due to bailing out of a function with a return, after checking some condition. if (bad_thing) return ERR_BAD_THING; ... code here to turn off controlled device ... From my understanding from prior HN discussions, panic is paired with recover; it's a kind of typeless non-local jump and unwind mechanism which can be intercepted. If the device must be turned off, then any panics must be intercepted and code must be executed to put the device in that state.
  - hota_mazi 9y ago
    > It is way safer than void * I said "it's unsafe", not "it's not safer than void*". > (i.e. exit cleanly without corrupting memory). This makes no sense. If it exits, who cares if the memory of the process is corrupted? Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it. That's the point of static type safety (which Go doesn't provide in this case): it lets you ship code that is provably incorrect and that will not work once deployed (it will exit, like you say). This is why I said "it's unsafe".
    - parenthephobia 9y ago
      > If it exits, who cares if the memory of the process is corrupted? People care when memory is corrupted without the process exiting. It is usually better for a program to crash than for it to continue having corrupted its data. The former gives you x-ray machines which sometimes won't start, whilst the latter gives you x-ray machines which sometimes give the patient cancer. I say better, not best. Best, obviously, is for as many failure modes as possible to be detected before the code is deployed. Particularly if you're programming a machine that can kill people. But in the comparison between Go's interface{} and C's void*, neither language has that option.
      - hota_mazi 9y ago
        > It is usually better for a program to crash than for it to continue having corrupted its data And it's even better to no let this program get corrupted data in the first place, which languages with a weak type system (such as Go) allow to happen whenever you use `interface{}`.
    - Merovius 9y ago
      > I said "it's unsafe", not "it's not safer than void". I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you should be talking about.
andreasgonewild 9y ago
Safe as in nil not even being equal to nil any more, I know I'll sleep better.
- weberc2 9y ago
  nil is always equal to nil. You might be confusing it with comparing a nil pointer to a pointer to a nil pointer, which are not equal.
  - andreasgonewild 9y ago
    I don't care what we call it, it's still confusing as hell.
    - weberc2 9y ago
      Yeah, indirection can be confusing to new programmers, but its absolutely fundamental, so it's better to get used to it than to complain about it.
      - andreasgonewild 9y ago
        Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing. This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.
        weberc2 9y ago
        If you think that's my attitude, you don't know me. I have lots of criticism for the language, but pretending a pointer isn't a pointer isn't the solution to people not understanding indirection.
  - 9y ago
saghm 9y ago
Memory safe, yes. Type safe, no.
- Merovius 9y ago
  Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Contrast that with void-pointers, which make that so easy as to be a common bug-source. It's not statically type-checked, yes. That's fine too, in my opinion, but also irrelevant for a comparison with void-pointers (because they also don't provide that). In summary, interface{} is strictly better than void-pointers. Which was exactly my point. Equating the two is intellectually dishonest.
  - saghm 9y ago
    > Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Interesting; for some reason, I was under the impression that you could cast an `interface{}` arbitrarily, but from trying it out, you're absolutely correct. (I should definitely make sure to try these things out before confidently asserting about them...) > interface{} is strictly better than void-pointers No arguments here; even if for some reason they weren't type safe (which they are, much to my surprise), I'd still agree with you there.

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

hota_mazi 9y ago

No, it's not safe. It's basically a way to disable compiler checks, so it is by definition, not safe.

majewsky 9y ago
It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory). var x int = 5 var i interface{} = &x *(i.(*string)) = "boom"
- pjmlp 9y ago
  True, now imagine that program was controlling some kind of device and due to the panic it wasn't able to turn the device off.
  - Vendan 9y ago
    That's "shitty programmer", not bad language. You can catch panics, and there's a panic safe "val, ok := ival.(type)" assertion.
  - kazinator 9y ago
    Same thing could happen due to bailing out of a function with a return, after checking some condition. if (bad_thing) return ERR_BAD_THING; ... code here to turn off controlled device ... From my understanding from prior HN discussions, panic is paired with recover; it's a kind of typeless non-local jump and unwind mechanism which can be intercepted. If the device must be turned off, then any panics must be intercepted and code must be executed to put the device in that state.
- hota_mazi 9y ago
  > It is way safer than void * I said "it's unsafe", not "it's not safer than void*". > (i.e. exit cleanly without corrupting memory). This makes no sense. If it exits, who cares if the memory of the process is corrupted? Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it. That's the point of static type safety (which Go doesn't provide in this case): it lets you ship code that is provably incorrect and that will not work once deployed (it will exit, like you say). This is why I said "it's unsafe".
  - parenthephobia 9y ago
    > If it exits, who cares if the memory of the process is corrupted? People care when memory is corrupted without the process exiting. It is usually better for a program to crash than for it to continue having corrupted its data. The former gives you x-ray machines which sometimes won't start, whilst the latter gives you x-ray machines which sometimes give the patient cancer. I say better, not best. Best, obviously, is for as many failure modes as possible to be detected before the code is deployed. Particularly if you're programming a machine that can kill people. But in the comparison between Go's interface{} and C's void*, neither language has that option.
    - hota_mazi 9y ago
      > It is usually better for a program to crash than for it to continue having corrupted its data And it's even better to no let this program get corrupted data in the first place, which languages with a weak type system (such as Go) allow to happen whenever you use `interface{}`.
  - Merovius 9y ago
    > I said "it's unsafe", not "it's not safer than void". I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you should be talking about.

andreasgonewild 9y ago

Safe as in nil not even being equal to nil any more, I know I'll sleep better.

weberc2 9y ago
nil is always equal to nil. You might be confusing it with comparing a nil pointer to a pointer to a nil pointer, which are not equal.
- andreasgonewild 9y ago
  I don't care what we call it, it's still confusing as hell.
  - weberc2 9y ago
    Yeah, indirection can be confusing to new programmers, but its absolutely fundamental, so it's better to get used to it than to complain about it.
    - andreasgonewild 9y ago
      Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing. This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.
      - weberc2 9y ago
        If you think that's my attitude, you don't know me. I have lots of criticism for the language, but pretending a pointer isn't a pointer isn't the solution to people not understanding indirection.
- 9y ago

saghm 9y ago

Memory safe, yes. Type safe, no.

Merovius 9y ago
Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Contrast that with void-pointers, which make that so easy as to be a common bug-source. It's not statically type-checked, yes. That's fine too, in my opinion, but also irrelevant for a comparison with void-pointers (because they also don't provide that). In summary, interface{} is strictly better than void-pointers. Which was exactly my point. Equating the two is intellectually dishonest.
- saghm 9y ago
  > Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Interesting; for some reason, I was under the impression that you could cast an `interface{}` arbitrarily, but from trying it out, you're absolutely correct. (I should definitely make sure to try these things out before confidently asserting about them...) > interface{} is strictly better than void-pointers No arguments here; even if for some reason they weren't type safe (which they are, much to my surprise), I'd still agree with you there.