Some patterns arise from language design * You can't express `T` where `null` is forbidden in the type system so you get NullPointerException everywhere and de

Some patterns arise from language design * You can't express `T` where `null` is forbidden in the type system so you get NullPointerException everywhere and defensive null checks. * You express a sum type as a product type because your language does not have sum types . * Your language doesn't have first class multiple return values (or tuples) so you return extra parameters via out parameters or thread local variables such as `errno`. * Your language doesn't have exceptions (or algebraic effects) and can't do IO so you have monad transformers. * Your language doesn't have set-theoretic types so you need hacks like `thiserror` . * Your language doesn't have stackful coroutines or can't infer async IO for you so you have `async/await` spam or callback hell or "mono's". * Your language doesn't have exhaustive checks (or pattern matching) so you need a fallthrough case check on switch statements . * Your language doesn't have algebraic effects, so you need to pass context everywhere. I know someone will reply about Java's null annotation checking options, so here is one of them: https://github.com/uber/NullAway https://github.com/uber/NullAway .