Giuseppe! Long time no see. Rockset’s architecture changed somewhat since we last talked— not in fundamental ways, but in ways that would alleviate your concerns.
If you want to talk (not secret) technical details, you know where to find me :)
I think the main difference between our flavor of SQL and CockroachDB's (or PostgreSQL's) is that we don't have a specific "json" data type, but rather:
1. We don't need you to specify the types of any fields, indeed, we don't even need to know upfront which top-level fields ("columns") may exist in the document.
2. You don't need to use special operators / functions to deal with JSON-typed values.
Then you really won't like it that we're moving in the opposite direction :)
I personally like strong, static type systems. But a lot of real world data doesn't match static schemas, which is why businesses hire data engineers to (build systems to) clean it up.
That's on my TODO list, both in terms of performance and in terms of features / ease-of-use. (Another interesting thing to compare against is SQL++ (https://ci.apache.org/projects/asterixdb/sqlpp/manual.html) which has a couple of usability affordances that we might adopt.)
Yes. In our case, though, Rockset is not a transactional database, but a query engine on top of existing data, so we're not the right place to enforce constraints anyway.
> But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract).
Sure. Those are overly simplistic categories, but a full discussion of type systems in programming languages would be out of scope for that post.
> some statically typed languages supports variable shadowing in the same scope
Shadowing is a different issue. Shadowing refers to two different variables (which happens to have the same name), so it's orthogonal to whether the same variable is allowed to hold values of different types at different times.
If you want to talk (not secret) technical details, you know where to find me :)
-Tudor.