Probably because it's an informal short form of "Technology." It does seem kind of weird as I'm used to seeing "Tech" used as a word in its own right but it's the likely reason why they did it.
The lack of proper non-Java support in the Hadoop world is maddening, and Zookeeper is a prime example of this. It's a heterogenous world, people! How many people are missing out on Zookeeper because it lacks proper Python or PHP support?
Nothing to say about Hadoop/Java homogeneity, but a Zookeeper alternative I've been looking at for the same reasons is Dozerd from Heroku (https://github.com/ha).
The thinking might be along the line: if you need to use Hadoop at all, you are probably already using Java anyway to maximize single machine performance.
Personally, I've never looked to Java as a top performer.
It's a middle language---not as expressive as Python, not as fast as C. Even compared to C#, I wouldn't naturally choose Java but I've been forced to because C# wasn't well supported away from a windows' box.
Now adays, I just skip the Java step for CPU intensive work and go to straight C integrated with Python.
The Python bindings are not very robust, don't fit the language well, and have a build process alien to the Python ecosystem. If it's representative of the other non-Java bindings, it's small wonder it doesn't get used by non-Java projects.
The C client isn't what I would call great, and the API surface is fairly complicated for languages to bind to -- you see many reports about the bindings crashing their respective languages.
I'm currently hacking on a pure-Node.js implementation of the Apache Jute RecrodIO and Apache Zookeeper network protocol: https://github.com/racker/node-zk
The core problem is that Zookeeper is using a deprecated serialization layer as its network protocol. Jute predates Apache Thrift or Apache Avro, and it only has code-gen for C and Java. Ideally Zookeeper would add a second network protocol, one which was either a spec for a nice binary protocol, or a more modern serialization framework like Thrift or Avro, which support many more languages.
12 comments
[ 4.2 ms ] story [ 35.9 ms ] threadPersonally, I've never looked to Java as a top performer. It's a middle language---not as expressive as Python, not as fast as C. Even compared to C#, I wouldn't naturally choose Java but I've been forced to because C# wasn't well supported away from a windows' box.
Now adays, I just skip the Java step for CPU intensive work and go to straight C integrated with Python.
That was my impression, but I haven't used Hadoop for anything nontrivial or in any language but Java, so I don't really know.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZKClie...
The C client isn't what I would call great, and the API surface is fairly complicated for languages to bind to -- you see many reports about the bindings crashing their respective languages.
I'm currently hacking on a pure-Node.js implementation of the Apache Jute RecrodIO and Apache Zookeeper network protocol: https://github.com/racker/node-zk
The core problem is that Zookeeper is using a deprecated serialization layer as its network protocol. Jute predates Apache Thrift or Apache Avro, and it only has code-gen for C and Java. Ideally Zookeeper would add a second network protocol, one which was either a spec for a nice binary protocol, or a more modern serialization framework like Thrift or Avro, which support many more languages.
The ticket to change out Jute is here: https://issues.apache.org/jira/browse/ZOOKEEPER-102
But no one seems to actively be working on it.