32 ms·
"Go programs are much less safe than programs written in Rust or Java for that reason." This is plain wrong. ( Rust included )
by 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 agoBeing 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 agoIt 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 agoI 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 agogolang 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.
- usddddd 7y agoGo will most certainly notify you if a 3rd party API suddenly returns a new error. Typically you would see an assignment mismatch.
- deleted 7y ago[deleted]
- munk-a 7y agoWon't this only cause an assignment mismatch if the function previously returns values that you captured? For functions that previously had no return value and suddenly have a return value (so those side effect only functions) I believe golang won't complain?
- hota_mazi 7y agoNo, it won't. If a function could return one error but in a new version, it can now return two types of error, the Go compiler will not notify you. And your code is now failing to handle an error case.
- masklinn 7y agoThe only situation in which that will happen is a function going from returning a value to returning a value and an error and you were actually getting & using the value. If a function starts returning more variable errors Go likely won’t tell you (though in fairness that’s a pretty common issue). If a function was not returning anything or you did not care for the value it returned, it adding an error will be a completely invisible event.