Turning didn't work for me. Impressive as hell indeed! The author is probably already busy 100xing other projects, no time to fix such a minor nuisance.
I believe you, but it would be nice if you called out the exact vendors that do that, for others to be cautious. It's not like their pricing is under NDA, right?
Clojure authors are quite conservative about adding such opinionated instruments into the language, especially when they come from outside. But fortunately, being a Lisp allows Clojure to add such language modifications with libraries without forcing those modifications upon every user of the language.
It could certainly be redesigned to have explicit lazy collections/operations and use transducers as the composition glue. It would be a breaking change, so it's never going to happen in Clojure. But if somebody plans to design a language inspired by Clojure, they should certainly take this hint.
Well, if you already use transducers, then you are not exactly the target audience:). It's meant more for the younger developers who see a core language feature and feel inclined towards using it despite the drawbacks.
> In other words, it's something I don't think much about anymore, and it doesn't inconvenience me in any noticeable way.
Interesting, because it still does bother me. I mean, if I use lazy sequences and functions on them. Sure, if I consciously avoid them, then it doesn't me anymore, that's the point of the article :D.
Oh no, I'm saying it's another usecase, not the only one. And yet, it is a pattern I follow quite often in my mixed Clojure/Java projects: Clojure code is much easier to tinker with, take to new directions, rapidly modify and see the results. But once I settle with an approach/algorithm, I rewrite some things to Java for performance, or for easier interop with other Java/Scala teams, or because the imperative mutable code looks much better in Java.
So, you can say that Clojure among everything else is my IDE to write Java code. Is that a bad suit for a language? Depends on your perspective, but I personally am very happy that I have Clojure by my side.
Whatever the benefits of Clojure are, they were enough for Nathan Marz and first contributors to write Storm in it and succeed. Note that it's not an argument about impossibility of writing something like that in Java (see Spark, Flink, Heron, etc). But at that exact moment in time, a Clojure Storm was created and became useful to many people for years. There were many more Java programmers than Clojure programmers then and now, yet the Java coomunity didn't produce their own Storm first.
To me, this makes total sense as the project moved to Apache. Obviously, much more people will be able to consider contributing when it's in Java. Apache goal is sustainability and long-term viability, and Java would work better for that.
I also consider this a success story for Clojure. It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years and benefit thousands of developers until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.
Well, if caching takes a small part of the overall workload, then you can't really say it's a "cache workload" or "cache-heavy workload", right?
My answer meant that Shenandoah would work well in a program where cache occupies like 70-80% of the heap, and generational GCs might not. But surely, neither are going to break from a 1%-heap cache.
> wouldn't the majority of allocations still happen during a request?
Could you please clarify this question? Do you mean that if cached objects are a small part of the total allocation rate, then generation GCs work well with that?