[danmux]

Thank you, and may I say what a well written comment.

Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference.

Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about.

Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.

[bluejekyll]

> being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.

It's funny, every language I know gives you an option to basically ignore the error and just pray. I get what your saying, but if this is the type of code you want to produce, you can still do that in other languages that have strong types around Null and Errors.

In Rust for example:

  my_possible_error.unwrap()

In places where you are explicitly making that choice. And to me that's the big difference. Is it explicit or implicit/unknown?

[danmux]

Fair point, just differing levels of hoops to jump through, or general expectations of best practice. In that sense I would say Java and C# do not allow you to 'ignore' exceptions.

I suspect your "pray" == monitor closely and fix fast (often never).

I agree it can be problematic that there is nothing in the language that indicates that the author is explicitly in 'pray' mode. It could well be that even a brief defence of a missing error check during a PR code review is not worth avoiding (un-triggered) err handling.