Bryan Duxbury wrote:
I feel that this suggestion is a bit of a red herring. Sure, you could
implement a tiny fraction of the Thrift "library" in C - maybe just the
protocol? - but then you'd still be stuck needing the full code generator
and a set of related language-specific tools. I'm thinking that even if you
coded up the core of the protocol in C, you'd probably have to put a
language-specific C-extension wrapper on it in order for it to be usable in
the way that all the languages operate.
Bottom line, I don't think there's near enough benefit to putting the "core"
in a common C blob. I could be convinced otherwise if someone has some
strong ideas.
Why is (was) there a C-version of the Python run-time? Performance maybe?
Part of the problem with having N languages is that any fast, optimized,
but hard-to-write implementations/features will either have to be
written (and debugged!) N times or will end up not being available to
everyone. This, among other things, lowers the benefits (and therefore
attractiveness) of writing any high-performance code. Which may be why
the Thrift run-timess (even the C++ runtime) are fat & slow compared to
what it could be.
