I actually agree with some points in this article. Companion objects are more complicated than they need to be for new users and IMO just having static methods would be fine. But then again, static methods are already part of kotlin as top level functions.
Yes, if you use APIs that need a java-class-reference the kotlin syntax for it looks worse then the java one.
Compile time null safety has some problems, but they are not the ones described in the article. The main problem is that you sometimes have “linked” properties, e.g if this “a is X then b and c must not be null”. This leads to sometimes ugly looking checks, without real meaning (!! is used a lot in this case, up to a point where it’s meaningless).
Yes, interop between a kotlin function which cares about null-safety and a java function which does not is not trivial. It requires the programmer to tell kotlin about the nullability. That said, I like kotlins approach there. It gives flexibility without trowing away the power of kotlins system.
The article complains, that null can still travel through the entire program, due to platform types (T!), which is not true. Sure, as long as you only use platform types, they can be null. But as soon as you try to assign a platform type to a non-null type kotlin adds a null-check and since it’s impossible to declare platform types in kotlin (they can only be inferred from java calls) this is not really an issue.
In the last 2 years of using kotlin I never had a problem with this, not even once.
The biggest offense of platform types is that they can be used in public/protected properties and functions. IMO this should at least be a warning and not just an IDE inspection.
This brings me to name shadowing. I agree with the article in that maybe kotlin goes a bit too far here. But the claim that this is only a warning in IDEA and not a compiler warning is just wrong. Ok I know that many people out there just ignore all compiler warnings, but that’s their fault and not kotlins.
I’m not going to repeat the criticism @medium already listed. I totally agree with his/her points. Although I might add that I don’t think kotlin is hard to learn for a programmer that knows java. Yes, it’s a new language and has a different syntax. There are a few features (the way inline functions work, companion objects) and because of the null-safety people have to learn to think a bit differently when designing classes, but this is not different to learning any new language. I concede however that someone completely new to functional programming might take a bit longer (but then so was I).
In conclusion I don’t think this article gives any good reasons, why you should not use kotlin. It does however have a one or two good points about areas kotlin might still improve. But then, I could probably list 10 about java without thinking much about it.