Why a modern language like Kotlin makes a developer more productive
kotlinexpertise.com
kotlinexpertise.com
Rx is cool and definitely a good solution for some cases, but if what you really want is just to talk to your database without blocking the thread, then it's way overkill. Just give me async/await like C#.
I'm a bit concerned about Kotlin code tending towards being overly concise and clever, especially with the IntelliJ refactoring suggestions that constantly pop up to entice me to make my code a few characters shorter. Of course, "my IDE told me to do it" is no excuse, it's my responsibility to write clear code.
One of the things I like about Go is the tendency to write straight forward code that reads easily from top to bottom. Java has a bit of this tendency too (if you forego the kind of all too common libraries that require you to instantiate 14 objects to do even the simplest things). Java has already become much less noisy with type inference for local variables.
Java code doesn't have to look like this, Java programmers are doing it to themselves:
HttpURLConnection httpConnection = (HttpURLConnection) new URL(url).openConnection();
httpConnection.setRequestMethod("POST");I don't think anyone would be surprised by that.
Jump ahead 30 years and just use LISP already.
Kotlin is a great language for individual productivity, but _can_ be terrible for teams.
You can do the same thing in Kotlin in so many different ways that it makes hard to read other's code, and a lot of time gets wasted in code reviews over preferences.
Compared to that, limiting languages like Go are great for teams since well there's only one (or max, two) ways you can iterate a collection, as compared to what, like, seven ways in Kotlin.
But I am curious, is that just out of familiarity or are there things that JVM ecosystem has that are just not there elsewhere?
I understand that some of the distributed data processing ecosystem (Kafka et al) are _built_ on JVM but there's nothing inherently stopping people from using these things from other languages.
The title is categorical, but the content does not support that claim.
The content gets no further than — "I feel much more productive with the language."
Whether or not the author is more productive seems unknown (and apparently unexamined).
Are you working in an environment where you can't run a JVM at all for some technical reason? Maybe very constrained? But then you wouldn't be able to take many libraries regardless of platform. And in fact Kotlin also has Kotlin/Native which generates small(ish) native binaries.
There is also SubstrateVM which can create standalone, statically linked, natively pre-compiled binaries from Java/Kotlin programs. It even has an ARM backend.
But compile-to-JVM is compelling enough on its own. The Java ecosystem that comes for free with Kotlin gives you an incredible amount of power. A massive collection of battle-tested libraries, the excellent performance of the JVM, and tooling. Beautiful, productive tooling.
VisualVM is very helpful. You can attach to any running Java program on your system and get graphs of CPU, memory usage with garbage collection information, you can take a snapshot of what every thread is doing with reliable stack traces, you can take a heap dump and then query it with the "Object Graph Query Language" or visualise it with tables and charts to understand where your memory is being used. You can do deep CPU profiling or lightweight CPU sampling. It understands mixed language programs and can show you the heap and stack in ways that make sense for not just Java and Kotlin but Ruby, JavaScript, etc.
https://visualvm.github.io/graal.html
Of course all these features work transparently over the network too.
Then there's Mission Control. It's a profiling system so fast and low overhead you're intended to keep it running all the time even in production. You can connect it to a live server and profile without disturbing users.
Then there are ultra-low-pause garbage collectors like ZGC, Shenandoah. Whilst Golang offers such a thing too, it comes with the major caveat that it has a very simplistic design that creates enormous CPU and memory overheads. The Java ultra-low-pause time GCs have more sophisticated designs that impose much lower overheads on running applications.
Then there's SubstrateVM, which can turn Java programs into standalone native executables of small size, without any JVM dependency. This comes with some caveats: execution speed is slower and you can't do dynamic classloading, which quite a few advanced frameworks do require. You also have to tell it in config files what you want to reflect, so it doesn't throw away code accessed only reflectively. Also the garbage collector is fairly middle of the road and not so sophisticated as what you get in HotSpot. After all the regular JVM is large because it's giving you a lot of stuff. But it can be very useful for command line tools.
Talking of which, check out the combination of PicoCLI, Apache SSHD and JLine. They integrate together well to enable you to easily and rapidly create interactive shells for your program, accessible via SSH. There are of course many other powerful libraries available.
Finally you may like to explore things like the Chronon time-travelling debugger, which records what your app does so you can step forwards and backwards through a debugging session.
I had to write something in java recently for the first time in a while. I'd forgotten just how much you have to type for the most basic things.