tudorb

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 :)

-Tudor.

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.

And operator"" _obfuscated1 has a serious bug, as it returns a temporary buffer allocated on the stack.

For now, this requires LuaJIT 2.0+, Linux x86_64.

Now with discussion group: https://groups.google.com/d/forum/facebook-folly

Not the main purpose, obviously, but if you find any bugs, I'll be more than happy to take a look.

folly::small_vector does just that (and it lets you use one bit for a mutex, too! -- we have a lot of memory-constrained apps so we had to design data structures for them).

We might unify that with fbvector eventually.

I'm Tudor, one of the main folly authors. I wrote format, Arena / ThreadCachedArena, DiscriminatedPtr, GroupVarint, TimeoutQueue, and various other pieces (parts of String.h, ThreadLocal, etc), and I'm pretty well-versed with the entire library so I can reasonably answer questions (or poke the appropriate people to make a HN account and answer). Ask away.