4 ms·

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosi

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.

rhinoceraptor 7y ago
It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9ee9303cde7bd6b/src/runtime/sys_linux_amd64.s#L139-L143 https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9... https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
- aeontech 7y ago
  That debug report was incredible, I have to say. Hats off to the author for their patience.
- rob74 7y ago
  I don't think this example justifies the expression "incredibly broken assumptions", I would rather call it an "incredible corner case"...
  - kevingadd 7y ago
    Making assumptions about the stack frame size of third-party code is incredibly broken. You have no way to make any guarantees about it and primitives like alloca mean you can't even be sure the stack size will be the same across multiple calls.
    - amscanne 7y ago
      The VDSO isn’t really any third-party code. It’s very surprising for it to do a stack probe. Though obviously it’s possible, and falls on the runtime to handle (so it’s a legit bug). But.. nearly every “runtime” makes stack assumptions. They usually just have enough slack that it doesn’t matter. E.g. musl has an 80k stack by default — is it still “incredibly broken” if the VDSO needs > 80k? No. While the VDSO doesn’t have an explicit stack requirement, it’s definitely implicit that it will use a small, reasonable amount.
Thaxll 7y ago
"Go programs are much less safe than programs written in Rust or Java for that reason." This is plain wrong. ( Rust included )
- munk-a 7y ago
  Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none? I hope you are reading all the change logs closely because in GoLang nothing will bop you over the head for suddenly not supporting a new `err` response that wasn't previously returned by a function, and if that error is triggered (for whatever reason) it won't be at all visible in your system until something major breaks inexplicably. I really dislike forcing users to be proactive about handling errors, some folks with wrap a System.in call in try { } catch () {} - but these are a clear anti-pattern that can be actively flushed out, tracking down someone forgetting to check the return value of mkdir is much harder.
  - Thaxll 7y ago
    It doesn't make Go much less safer than Java. Go is a safe language. Working long enough with Java I saw all the problems with exceptions and NPE and can tell you that those problems are less prominent with Go.
    - Tyr42 7y ago
      I think you two are using the word "safe" differently. I agree with you that go is memory safe, but I think they mean more that business logic will do something wrong because you got an err you didn't handle, vs deferences a null or something.
    - apta 7y ago
      golang does nothing to solve NPEs, and any line of golang can panic at anytime. At least with Java established frameworks have exception handlers at the base where relevant exceptions can be logged or handled in some other way. With golang, an error that is not handled just silently keeps the program running in corrupted state.
whatsmyusername 7y ago
Java just hides them in 40kb of logs that don't tell me anything. I agree that golang makes it easy to lose errors but using Java as a better comparison is laughable in practical use.

rhinoceraptor 7y ago

It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9ee9303cde7bd6b/src/runtime/sys_linux_amd64.s#L139-L143 https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9... https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

aeontech 7y ago
That debug report was incredible, I have to say. Hats off to the author for their patience.
rob74 7y ago
I don't think this example justifies the expression "incredibly broken assumptions", I would rather call it an "incredible corner case"...
- kevingadd 7y ago
  Making assumptions about the stack frame size of third-party code is incredibly broken. You have no way to make any guarantees about it and primitives like alloca mean you can't even be sure the stack size will be the same across multiple calls.
  - amscanne 7y ago
    The VDSO isn’t really any third-party code. It’s very surprising for it to do a stack probe. Though obviously it’s possible, and falls on the runtime to handle (so it’s a legit bug). But.. nearly every “runtime” makes stack assumptions. They usually just have enough slack that it doesn’t matter. E.g. musl has an 80k stack by default — is it still “incredibly broken” if the VDSO needs > 80k? No. While the VDSO doesn’t have an explicit stack requirement, it’s definitely implicit that it will use a small, reasonable amount.

Thaxll 7y ago

"Go programs are much less safe than programs written in Rust or Java for that reason." This is plain wrong. ( Rust included )

munk-a 7y ago
Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none? I hope you are reading all the change logs closely because in GoLang nothing will bop you over the head for suddenly not supporting a new `err` response that wasn't previously returned by a function, and if that error is triggered (for whatever reason) it won't be at all visible in your system until something major breaks inexplicably. I really dislike forcing users to be proactive about handling errors, some folks with wrap a System.in call in try { } catch () {} - but these are a clear anti-pattern that can be actively flushed out, tracking down someone forgetting to check the return value of mkdir is much harder.
- Thaxll 7y ago
  It doesn't make Go much less safer than Java. Go is a safe language. Working long enough with Java I saw all the problems with exceptions and NPE and can tell you that those problems are less prominent with Go.
  - Tyr42 7y ago
    I think you two are using the word "safe" differently. I agree with you that go is memory safe, but I think they mean more that business logic will do something wrong because you got an err you didn't handle, vs deferences a null or something.
  - apta 7y ago
    golang does nothing to solve NPEs, and any line of golang can panic at anytime. At least with Java established frameworks have exception handlers at the base where relevant exceptions can be logged or handled in some other way. With golang, an error that is not handled just silently keeps the program running in corrupted state.

whatsmyusername 7y ago

Java just hides them in 40kb of logs that don't tell me anything. I agree that golang makes it easy to lose errors but using Java as a better comparison is laughable in practical use.