I need to explain this sentence for readers to understand my concerns:
Kotlin and Swift are far too opinionated for my taste.
IMO, many programming language features should be optional. In other words, not required. In far too many cases, programming language designers have decided that features are required because the designers know better than you what’s good for you. I reject such thinking.
For example, after years of suffering with checked exceptions that Java programming language designers had decided was a ‘good thing’, C# made exception declarations on methods optional (ie. ‘unchecked’). Since then, most new programming languages having either omitted exception declarations completely, or have followed the lead of C#. It was the opinion of the Java designers that caused checked exceptions to be implemented in the first place - that forcing programmers to declare their exceptions would make the resulting systems less buggy. However, the reality is that it didn’t make much difference. That is, their opinion was wrong. The result was that there were real costs to programmers that didn’t do much to help fix the perceived issue. That’s an example of what I mean by ‘opinionated language’.
The designers of Kotlin did good by removing certain required elements of Java. For example, by removing the requirement for semi-colons, by allowing the var keyword when the type can be inferred on declarations, by removing checked exceptions, and by removing a few other syntax elements that are today referred to as “boilerplate”.
However, the designers and implementors of Kotlin made several poor decisions because of what I perceive as their opinions of what is a ‘good thing’ that programmers must be required to adhere to.
Example 1. Nullability declarations. Why can’t programmers have the option of not using the feature, instead of being required to use it. By simply adding the concept of “platform type” as a declaration option, then programmers could use the nullability declaration where appropriate, but are not required to if they don’t want to.
Example 2. Static fields and methods in classes. I perceive that Kotlin designers have the opinion that the concept of “static” is bad, and thus it was omitted from the language. I wrote at length about this issue in a thread referenced above. And no, the suggested solution with @JVM… annotations is not useful for writing portable code, because it is not part of the Kotlin language and thus (I assume) won’t be supported in Kotlin/JS and Kotlin/Native.
Example 3. The compiler warning about ‘var’ vs ‘val’. I realize that this is not a language specification issue per se, but please, will the compiler implementors make a special switch to turn this one warning off? Some warnings are very helpful. This one is really annoying, particularly during initial development.
Example 4. The language does not allow these method two overloads for the same method: fun abc(vararg x: String) and fun abc(x: Array
>). Why? I suspect it was the opinion of the Kotlin designers that this is not a ‘good thing’, therefore it could be omitted. This is just one element of my dislike of the design of Array in Kotlin.
Example 5. C-style for loops were removed. Why?
There are several more examples of what I call ‘language designer opinions’ that are requirements and that I disagree with. Readers might find this article enlightening: https://kukuruku.co/post/why-kotlin-sucks/.
That said, IMO, Kotlin is still much better than Swift. I just wish it was better than Java.