[dleavitt]

This is salient too though:

The new Java-based implementation has improved performance significantly, and made Storm's internal APIs more maintainable and extensible.

It's not totally clear if this is because it's been rewritten Java, but the intrinsic qualities of the language do matter; there are real tradeoffs between maintainability and dynamism/flexibility. I feel like this sometimes gets shortchanged in these narratives.

[bjoli]

Idiomatic java is like idiomatic C: pretty fast. Most smaller languages prioritize other things. Clojure has immutability and Haskell has purity.

I have noticed this with every "X produces code faster than C": you begin with two programs that use a suboptimal algorithm, then you take your non-c language and try to write C in it. The result is always awful and removes most reasons not to use C in the first place.

This has somewhat changed with rust and in some sense C++,but for other languages my point still stands. They have a nice idiomatic golden path that is fast enough for most cases. Once you need performance badly enough you have to treat you language as an assembler, and then you will always lose to languages that actually are good at that.

I say this as a scheme/Haskell weenie. Writing really performance scheme and Haskell code often means writing ugly code.

[Scarbutt]

I say this as a scheme/Haskell weenie. Writing really performance scheme and Haskell code often means writing ugly code.

The same with Clojure, suddenly you start writing Java with parenthesis.

In the JVM, if you want absolute control over performance its better to just write Java for those parts (don't know much about Kotlin).

[vbezhenar]

Kotlin generally is not slower than Java. One exception is that it inserts a lot of null checks. And there are features that will make it even faster than Java, I'm talking about inline lambdas.

[danarmak]

The announcement says they have a new architecture. At the very least it's not a direct performance comparison to the same architecture implemented in Clojure.

> Storm 2.0.0 introduces a new core featuring a leaner threading model, a blazing fast messaging subsystem and a lightweight back pressure model. It is designed to push boundaries on throughput, latency and energy consumption while maintaining backward compatibility. The design was motivated by the observation that existing hardware remains capable of much more than what the best streaming engines can deliver. Storm 2.0 is the first streaming engine to break the 1 microsecond latency barrier.

[roenxi]

Clojure is marketed as a very fast language (bunch of clever optimisation gets done because data structures are immutable). If the gains were from switching to Java they'd probably have said so less ambiguously.

Surely what they mean is they've rewritten it to be faster, and switched to Java at the same time because they want to open up the contributor pool.

[0815test]

BTW, if anyone's looking for another language that stresses immutability on the JVM, you might want to check out Frege, a Haskell-like language with some "tweaks" that make it work well in that environment. https://github.com/Frege/frege

And as a sibling comment mentions, the announcement does clearly state that a rather extensive rewrite was done, including switching to a new architecture, with likely performance improvements coming from that - it's nowhere close to a pure Java vs. Clojure comparison.

[didibus]

I did find that bit interesting. It seems it's missing a leading "due to the commiters' better familiarity with Java."

Since you can argue knowledge of a language does help with maintenance and extensibility. With this, it also makes more sense for the following bit about finding people able to contribute. No contributors is pretty bad for maintenance.

At my work, we use Clojure, but I do often wonder what would happen if the current Clojure devs left. New devs unfamiliar with Lisps, FP, and Clojure would most likely have a hard time maintaining the code base and extending it, and if they try to rush it before really learning the language, would quickly degrade the quality of the code base, compounding the effect.

I think as long as you continue to have one strong Clojure dev on the projects, you'll be fine, as they can direct newcomers and help them transition to Clojure, but if you lost that, I think a rewrite in a different language would make sense, or there's a risk of the code base degrading quite quickly.