It means that your IDE can add all sorts of auto complete magic and cross-referencing if it knows the types and semantics of the code it is displaying. It can also prevent runtime errors to some extent via static analysis of the query.
I like MongoDB, but am familiar enough with type-obsessed languages like Haskell and Scala to summarize your response as
"not much"
I'd argue there are potentially better priorities available for a DSL->DB mapper. But hey, they're the ones putting themselves out there and putting in the hard work, not me.
So, more power to them and I'm glad they're contributing back to the community.
A common software engineering practice whenever one runs into a bug in production is to say "How can I make sure this class of bugs results in a test failure in the future?"
With a good type system, you can take that thought one step further and say, "How can I make sure this class of bugs results in a compilation failure in the future?"
Rogue lets us do that. The DSL is both expressive (it covers almost all of Mongo's query features) and easy to use (Rogue queries are concise and very similar to Mongo queries), yet they eliminate (at compile time!) a whole class of bugs that have bitten us in the past. When your Rogue query compiles, you can be fairly certain that it will generate a well-formed Mongo query. Getting a similar guarantee from a test suite would involve a lot more work.
Jorge - rogue looks great, and had it existed when I started my current project I might well have picked scala rather than clojure and congomongo (which is great too).
However - when you say it would have involved more work to guarantee well formed queries from a test suite, I find myself wondering how that can be true if you test every function that hits the database. Wouldn't malformed queries would cause such tests to fail?
