JVM Weekly #4 - Kotlin 1.7, Netflix doesn't use RX anymore, Vector API in action
JVM Weekly #4 - Kotlin 1.7, Netflix doesn't use RX anymore, Vector API in action
1 - Who actually uses RX? Turns out it's not Netflix
Today we'll start with some Twitter gossip. Sometimes in an ad hoc conversation, interesting facts can come out in an unexpected way - ones that can turn some commonly known industry facts on their head. It is likely that anyone who has ever used RxJava at some stage has come across the information that this library was created by Netflix. RxJava paved the way for other reactive programming projects. Its original version was created back in the days when nobody even planned Reactive Streams (only the 2.0 release introduced compatibility with this standard). So it's fair to say that it's Netflix we can thank for the boom in reactivity on the backend. So it will come as a surprise to many people that Netflix... has practically phased out reactivity already.
And we found all this out thanks to Twitter. Well, in one of the threads complaining about reactive programming, someone threw out the question " Is any big company using this at all", getting the answer, of course, that the most popular streaming system is known to be a heavy user. However, Netflix employee, Paul Bakker quickly joined in to say that nothing could be further from the truth....
Interestingly, the change was not the result of some top-down decision. Simply, over the years the Netflix code was refactored to the blocking API more and more often, "from below". One of the reasons was GraphQL and the API "graph" being created underneath. That solution become increasingly important for the company, and reactivity wasn't really able to help in this case, so it was gradually got rid of. If you are curious about how Netflix uses GraphQL, I suggest reading a detailed post on the subject.
Of course, absolutely don't take this post as "since Netflix stopped using RX, it's time to throw it finally out of its stack". I was more planning to draw attention to the mass of legends circulating in the industry, often based on information that is no longer current. Companies evolve, and their needs and approaches change. Therefore, however tempting it may be to rely on the authority of established companies when making technological decisions, it turns out that there are even more pitfalls than at first glance.
Controversial opinion: With reactive code, it's like CAP Theorem. It was created to highlight a particular problem but was so catchy that (suddenly) everyone started to classify all databases as AP and CP, as if those were the only differentiators. Just as all applications were suddenly surprised that the introduction of "responsiveness" did not suddenly solve scalability problems.
2. Kotlin 1.7 released
The season of Kotlin news is slowly unraveling. We've only just informed you about Roadmapia, and here comes another "big" edition of Kotlin! Let's take a look at what the new edition of the language brings.
The most important novelty certainly seems to be the alpha version of the K2 compiler. As we had a chance to mention a week ago, K2 is the future of Kotlin. It is the basis for the developers' plans to be able to make Kotlin a truly multiplatform solution, without the need for multiple implementations of the same functionalities. The alpha version supports only the JVM for now and is still quite limited, but the first test release is a very important step for the whole project. You can find out more about the K2 compiler in the developers' presentation.
Among the important new features, we should certainly mention incremental compilation with Gradle. The developers boast that their internal tests have shown an improvement of over 80% for changes after they hit the cache. Kotlin has had a reputation for being quite heavy for years, so any move to improve the Developer Experience (which is, after all, any improvements to the compilation process) is very welcome.
When it comes to things related to the language syntax, this release is definitely marked by further coverage of boundary situations that Kotlin's type system has to deal with (in this respect it reminds me a lot of the recent TypeScript release notes). The new release brings, among others, finally non-nullable types and type inference within the Builders. The underscore operator was also introduced, allowing for automatic inference of a generic type when the other arguments are known.
The standard library also has a couple of improvements, as it re-introduces the original function names, but with a non-nullable return value. More features have been added for Regexpy, and the new functions min(), max(), minBy(), maxBy(), minWith() and maxWith() now return a collection element absolutely or throw an exception.
fun main() {
val numbers = listOf<Int>()
println(numbers.maxOrNull()) // "null"
println(numbers.max()) // "Exception in. Collection is empty."
}On a more interesting note, Optionals have been made extensible to provide greater compatibility with java code and libraries.
val presentOptional = Optional.of("I'm here!")
println(presentOptional.getOrNull())
// "I'm here!"
val absentOptional = Optional.empty<String>()
println(absentOptional.getOrNull())
// null
println(absentOptional.getOrDefault("Nobody here!"))
// "Nobody here!"
println(absentOptional.getOrElse {
println("Optional was absent!")
"Default value!"
})
// "Optional was absent!"
// "Default value!"Of course, this is only part of what you'll find in the new Kotlin release, it's full of minutiae and I haven't really hooked into the changes that have come in the context of KotlinJS, for example.
And while we are on the subject of Kotlin - the results of the Kotlin Multiplatform community usage survey have been released. The results were accompanied by elegant infographics presenting the state of the ecosystem. I won't elaborate, because I would basically start rewriting what is in the summary from JetBrains website.
If you want to access the full report - unfortunately you will have to leave your email to its creators.
Sources
3. Vector API as an alternative to Arrays.sort
And finally, I have something very low-level and technical. Just recently we had the opportunity to toss you a text by James Baker on using the Loom project's precise concurrency control tools as an alternative to Jepsen. It's clear that the enormous popularity of the first text gave James the wind in his wings, because in a short period of time he managed to write another, which also quickly "trended". This time he took on Project Panama and the Vector API that comes with it.
This new publication deals with a seemingly long overdue problem - sorting. James decided to check how much we will actually be able to gain, bypassing Java abstraction and going directly to the processor itself. These support the so-called SIMD operations (Single Instruction Multiple Data), which allow for processing multiple data streams simultaneously using a single instruction. It allows for a significant reduction in calculation time. SIMD are with us for years, but on the way to their popularization stood the fact that it is difficult to write correct code using them, and what is most important, the compiler in many cases can do it for us. However, these mechanisms are not perfect, so in order to achieve maximum performance, programmer intervention will be necessary. Vector API, which is a part of the Panama Project, makes it possible to perform this type of operation in the safest way and avoid potential segmentation errors, so common with direct memory addressing as in the case of SIMD operations.
Arrays.sort was used as a benchmark. The code itself is so complicated and went through so many iterations, that I will not paste it here and let me refer those interested to the original post. However, we will be interested in the author's conclusions here.
We'll start with the positive ones... it's fast, really fast - the implementation proposed by the author achieved benchmarks performance nearly three times better than the solution provided with the JDK. However, it is burdened with some problems. For example, the author makes no secret of the fact that writing with the Vector API is a process of regular shooting on one's own foot and long-term debugging (which in itself is also very difficult, due to the fact that we are working directly with native memory). Just measuring the resulting performance in a realistic way also required some creativity from James. The API itself, by virtue of being a "safe" solution for programmers, doesn't allow for full CPU power either - solutions in C++ are still many times more efficient. It seems, however, that for many programmers Java with its SIMD support may turn out to be a very interesting alternative to languages closer to the machine
I recommend reading the whole thing - it's not the lightest, but the author does his best to painlessly guide the reader through the meanderings of coding with the help of a new acquisition coming from Project Panama.
Sources:
Bonus: We lived to see the frozen list of JDK 19 features.
It presents itself as follows:
405: Record Patterns (Preview)
422: Linux/RISC-V Port
424: Foreign Function & Memory API (Preview)
425: Virtual Threads (Preview)
426: Vector API (Fourth Incubator)
427: Pattern Matching for switch (Third Preview)
428: Structured Concurrency (Incubator)
As you can see, we're likely to get only one stable feature (conversion of Java to Linux running on RISC-V processors), but once again I emphasize - this will be the most interesting new Java release in years.