Yeah, for this reason null shouldn't be part of any production code. If there's the possibility of having a null value, you need to check every variable or returned value to be safe.
These monads tell the consumer of your functions to do something (a check for emptiness or wait for it to be ready, or iterate it) to access the value inside. In a safe language, if the value is not wrapped by a monad, then you should expect to access it without issues.
I kind of get why people don't want to call them monads, since it sounds like a heavy term and more things to learn that are not strictly "necessary", but the earlier you learn about their importance, the earlier you can use any of their benefits in your codebase.
Many of these meanings seem to be captured in some modern solutions already:
Futures?
Exception?
Resultmonads? (Okay, yea, we try to avoid the m word, but bear with me there)An
OptionorMaybemonad?An enumeration of return types would seem to solve this problem. I can picture doing this in Rust.
Yeah, for this reason null shouldn't be part of any production code. If there's the possibility of having a null value, you need to check every variable or returned value to be safe.
These monads tell the consumer of your functions to do something (a check for emptiness or wait for it to be ready, or iterate it) to access the value inside. In a safe language, if the value is not wrapped by a monad, then you should expect to access it without issues.
I kind of get why people don't want to call them monads, since it sounds like a heavy term and more things to learn that are not strictly "necessary", but the earlier you learn about their importance, the earlier you can use any of their benefits in your codebase.