4 ms·

When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A lan

When have you seen segfaults in Go? I think 100% of the time, it is either a bug in the Go runtime, or you're using cgo (which is not really Go anymore). A language as simple as Go without nilable types would be great, though.

pknopf 8y ago
nil pointers exist in Go. It is common to run into them, especially when using "&".
jdoliner 8y ago
C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.
- regecks 8y ago
  Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.
  - vesak 8y ago
    > dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming. Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".
    - matthewmacleod 8y ago
      Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
      - SamReidHughes 8y ago
        You can't actually accomplish that without making the language really complicated.
        vesak 8y ago
        Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
        SamReidHughes 8y ago
        Are you joking? They're all way more complicated than Go.
        vesak 8y ago
        Okay, let's pretend that's true. Are the complications due to null protection being there, or are they due some other things?
        SamReidHughes 8y ago
        Some of the complications are necessary. You either need generics or a whole bunch of primitives to have non-nullable references. Go would also have to replace slices with something different. Return types and the shape of the interfaces would have to be changed. Algebraic datatypes or some complicated way of defining return types would need to be added for it to be usable. Defer statements that can modify the function's return value would need to be handleable by the type system, or dropped.
  - vultour 8y ago
    It is extremely easy to get a SIGSEGV by creating a double pointer and then attempting to assign something to *p.

pknopf 8y ago

nil pointers exist in Go. It is common to run into them, especially when using "&".

jdoliner 8y ago

C programs tend to call nil-pointer panics "segfaults" even though go runtime doesn't print the word "segfault" anywhere. I'm guilty of the same thing.

regecks 8y ago
Well, I think they're worth separating. I've seen a raw SIGSEGV in Go due to a runtime bug years ago, and the only safe outcome is process termination. On the other hand, dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. For common cases like HTTP and RPC handlers, no big deal, safely recoverable. Edit: on second thought, forget that. I agree that it's not a good thing (not safe) for recovery from goroutine crash to be possible.
- vesak 8y ago
  > dereferencing a nil value in Go in relatively safe (as in Java), all it does is crash the goroutine. Yeah, these are exactly the things I don't want to see: production log messages saying that something or other referred to a nil pointer and thus crashed some process. I don't think they belong to modern programming. Sure, segfaults are even worse since you don't even get the log message, but I still kinda lump both of these problems together as "errors from the 1900s that shouldn't happen anymore".
  - matthewmacleod 8y ago
    Totally agreed. A modern type system should make these errors fundamentally impossible. If you see them in production, it means there is definitely a logic or error handling issue somewhere in your code and I find it weird that there's no support for a known technique for eliminating them.
    - SamReidHughes 8y ago
      You can't actually accomplish that without making the language really complicated.
      - vesak 8y ago
        Are Crystal, Kotlin and Swift really complicated? Is Rust's complications due to null protections or something else?
        SamReidHughes 8y ago
        Are you joking? They're all way more complicated than Go.
        vesak 8y ago
        Okay, let's pretend that's true. Are the complications due to null protection being there, or are they due some other things?
        SamReidHughes 8y ago
        Some of the complications are necessary. You either need generics or a whole bunch of primitives to have non-nullable references. Go would also have to replace slices with something different. Return types and the shape of the interfaces would have to be changed. Algebraic datatypes or some complicated way of defining return types would need to be added for it to be usable. Defer statements that can modify the function's return value would need to be handleable by the type system, or dropped.
- vultour 8y ago
  It is extremely easy to get a SIGSEGV by creating a double pointer and then attempting to assign something to *p.