5 ms·

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.

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.