Are you suggesting that there is a meaningful difference between (:firstname record) and (.-firstName record), or (func x) and (.method x), the first of which is nil safe and the second isn't? (It doesn't seem you are, because you're focused on the ifs, but nil punning is about eliding ifs)
Hi Dustin. No, those function/method calls are equivalent.
My central point is that it is not reasonable to expect the consumer of a value to recover from a failure mode that was generated at the producer. Rather, it is better to handle failover and retries at the producer. Of course, once a (valid) value has left your system, any downstream errors are the purvue of the subsystem, but you may want to provide a signalling pathway back to the producer if it can be resolved upstream.
This naturally results in writing thinner consuming functions and "fatter producers" or "smarter callers."[^1]
nil doesn't have to be a failure mode, if we are programming with data it can just mean "empty". The trouble, I think you would point out, is that (.send bus payload) doesn't have a sensible definition of empty – because the bus reference is imperative/stateful/object oriented, not data oriented. Nil punning can't help with foreign interop to imperative systems, but that doesn't mean nil is the root cause of the pain. The imperative dependency is.
