The thing I miss most is the Maybe monad. In idiomatic Haskell, Maybe serves roughly the purpose that null serves in Java -- a value may or may not be present. You don't need monads to query a Maybe value -- it works roughly like a Java Optional -- but working within the Maybe monad allows you to write a series of operations as though the Maybe value always has an accessible value and know that the whole series will short-circuit to a Nothing value if a Nothing is ever examined.
For a series of operations, is that one monad or a series of monads?
If I have to use a monad for each operation, that feels like the same order of magnitude of effort as checking for null after each operation. If it's just one monad, then it feels like the monad saves work.
For that matter, the monad may still save work, because I only have to think about how I handle Nothing in one place, at the end of the series of calls. Whereas with null, I have to think about how to handle it after each call that can return null.
Just one. If you have a series of functions that could return Nothing (Maybe's version of null), you chain them like:
foo >>= bar >>= baz
This will automatically return Nothing if any of the contained functions do. This does require all of the function to have the type (a -> Maybe b), indicating that they take a value and can return either another value, or Nothing. If you have a function with type (a -> b), indicating that it is guarenteed to return something, you can wrap it like so:
foo >>= return . bar >>= baz
A complete usage might look like:
f x = fromMaybe defualtValue $ Just x >>= foo >>= bar >>= baz
