,
7 tweets,
1 min read
Read on Twitter
To be clear, the Clojure to Java rewrite had nothing to do with Clojure performance. In fact one of the first acceptance criteria for the rewrite was "no performance regressions." 1/
The decision was based on:
1. A desire to clean up/refactor parts of the codebase that had accumulated tech debt.
2. A desire to incorporate a large, Java-based code contribution. 2/
1. A desire to clean up/refactor parts of the codebase that had accumulated tech debt.
2. A desire to incorporate a large, Java-based code contribution. 2/
#2 came from Alibaba. They had reimplemented Storm in Java. Precisely because they lacked in-house Clojure expertise. It was discussed among the community and no one felt particularly religious about sticking with Clojure. 3/
The move to Java would make incorporating the code contribution easier.
The new core was developed only *after* the Java implementation had reached performance parity with the Clojure implementation.
The new core was developed only *after* the Java implementation had reached performance parity with the Clojure implementation.
Clojure was never really a problem. But there was direct and anecdotal evidence that moving to Java would make contributing more accessible to some devs.
So we looked at it as an opportunity to address tech debt, incorporate a large contribution, and potentially make the codebase more accessible to new contributors.
Community is everything for ASF projects. Without it, software rots and dies.
I think the community made the right choice.
/fin
I think the community made the right choice.
/fin
