[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.

[pvorb]

The compiler is significantly slower than Java's, though.

[vbezhenar]

That's the sad truth for a lot of modern compiled languages (I think Go is an exception). While I did not dig into their compiler internals, it just seems an inevitable consequence from a powerful language (Go is pretty simple in that regard). C++, Rust, Scala, Kotlin, Swift, they all have significantly longer compilation times compared to their predecessors. Probably that's the price we have to pay.

[bjoli]

Chez compiles a 80Kloc project of mine in less than a second, and apparently that is still 2x slower than before they switched to a nanopass compiler.

There is no reason compiling things should not compile at similar speeds to chez unless you are telling your compiler to ootimise everything.

C++/ruae are just exceptionally slow and it became the new bottom line somehow. I know rust does a lot of housekeeping, but after using chez and sbcl, 45s for a 1.5kloc project is killing me inside.

[pjmlp]

Not really.

.NET Native, D, Delphi, Ada and Eiffel also have pretty fast compilers, while offering quite powerful languages.

Lets even pick Turbo Pascal 7.0 for MS-DOS, which was quite feature rich, and was able to compile very large programs in a couple of seconds.

Also Visual C++ with modules preview support, incremental compilation and linking is also reasonably faster than the FOSS alternatives.

It is only a matter how much money one is willing to invest into improving tooling support.

[cryptos]

As far as I know Google is supporting JetBrains in making the Kotlin compiler faster.

[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.

[fiddlerwoaroof]

My impression is that Eta is a better choice, if only because it is compatible with a wider variety of Haskell libraries.

https://eta-lang.org/

[0815test]

Eta is a better choice, if you care about Haskell compatibility in the strictest sense. Frege doesn't really pursue this, but the flip side is that it optimizes for working as smoothly as possible with the JVM ecosystem.

[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.