I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.
Yes, plenty. It's mostly useless for relational data.
Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.
Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.
Anyway, I was focusing on invariants. But yes, destroying your performance every time you need an atomic change or joining values also makes it bad for relational data.
That doesn't mean it's useless, just that it should not be used on the most common problem people have with their data.
Say you have some json and nested in it somewhere is an array of objects, and you want to just map over that and update those objects. I was writing a migration to do that in Postgres <11 once and it was not fun to try and figure out how to do it.
I haven't worked with Mongo in years though, so no clue how it has evolved since like 2015.
For example: they measured Query B execution time on postgres: 41m3s, mongodb: 1h13m3s. When MongoDB measured Query B with a supported driver, the execution time was only 3m30s more than 10x faster than postgres!
You'll find details here: https://www.mongodb.com/blog/post/benchmarking-do-it-right-o...
I find it rather surprising that somebody who uses Haskell, i.e. clearly sees the value of types as an aid for reasoning about programs, would default to using a schemaless database which gives you essentially zero ways to reason about your data.
It makes much more sense coming from someone who doesn't really like static typing and so prefers run-time, informal reasoning.
For example, if you have a bug in your codebase due to e.g. a runtime type error, you can generally troubleshoot and fix it, but if your data is in an inconsistent state, it may be impossible to fully recover.