Then you are forced to deal with the fact that you might not have a value, right away.

Imagine you have this:

    Optional<String> get(String k)
    {
        ...
    }

    get("fooo").orElse("not found");

Or imagine for any other reason `get` returns an Optional.empty() when it shouldn't.

It's kind of the flip side of "null". Normally nulls are bad because of nullPointerException and people forgetting to handle null. Clojure in general handles null everywhere, and so you won't get nullPointerException, instead things will just work with whatever defaults makes sense for everything that comes after and is getting the null.

That makes it harder to realize that the null is there not because it missing, but because you have a bug which makes it look like something is missing when it should be there.

  (get m :foo :not-found)

    (get m :fooo :not-found)

If you're really that worried about typos and don't need an open map, Clojure has a solution as well in the form of defrecord and deftype. Now the compiler will catch the problem.

It's just an issue in general whenever the happy path includes optionality as a possible result, how do you then distinguish the happy path of getting a missing value, which you expect is a possibility given the use case, versus a bug to have set the value or have been provided the value or have queried for the value?

I think the only languages that reduce the scope of this problem are those where you can define non-nullable types. In that at least when you know for a fact your use case shouldn't have "missing" things, the compiler can catch those bugs. You can also handle this in Clojure with runtime assertions, albeit catching the bug a little later in development.

But for the times when optional is a real possibility, you still have this issue.

If you move to an explicit set of valid keys, it could be that something failed to assign them a value, etc.

Edit: I guess maybe something where the language simply has no null ever could work. Like say a field not yet assigned a value would have the value :unset, and so if someone doesn't provide a value for the field, you'd still set it, but with the new value :missing. Now technically you could distinguish a bug as `:unset` versus actually missing as `:missing`. I'm not sure this would work for dynamic use cases though, where like you don't know the full range of possibilities in advance. But if you do, you could check that nothing is `:unset` and if it is, you know there is a bug, otherwise it should be `:missing` or some other value.

Edit2: Ok, now that I played a bit more with what you said, I realized thay your solution is actually better then I thought, but it depends how you model things.

    (get {:foo :missing} :fooo :unset)
    ;> :unset

    (get {:foo :missing} :foo :unset)
    :> :missing

It does seem to require a bit of care, and I don't know if its just.moving the issue somewhere else, but it could be an approach.