No, that's not how it works. No one is forced to write Kotlin I don't think. Plenty of people have to use Java.
The fact that Kotlin is a simpler language than Scala is a feature, not a bug.
The fact that Kotlin is a simpler language than Scala is a feature, not a bug.
I haven't really used Kotlin much, so I may be wrong, but that's the impression I get.
Java was described as "blue-collar language". I probably won't call Scala that, but it fits Kotlin fine in my opinion.
another comment on that subject
Unless Scala has radically been pared back in the couple of years since I read about it or I was seriously misinformed at the time, then I'd say it probably a yes.
Scala has the reputation for being at the complex end of the language spectrum. Is that undeserved?
The "feature set" really is smaller than Java or Kotlin (especially if you count in terms of "keywords as features" and ignore things included for Java compatibility).
The flexibility though can be genuinely overwhelming (the name, scala[bility], refers to scalability of the syntax, not performance). Both in terms of the syntax flexibility , e.g. where curly braces are optional vs not or different ways of writing lambdas, and powerful/flexible features like implicit. However there are very rarely special cases to these, it's all very consistent once you know the rules.
Even the infamous underscore is "logically" consistent in it's use, it's just a placeholder in both contexts you typically see it used (context of variables and context of types).
Even my go-to example of a special case in scala, vararg unpacking:
`foo(myArgs: _*)`
Despite being a special case actually reads kind of consistently.. it reads like a type ascription[1] asking for myArgs to be treated as a varargs of whattever type. So consistent with other "type context" usages of underscore despite otherwise being weird.
And the flexibility of the type system and the advanced type inference.
It is fair to say that many Scala codebases are complex and difficult to work on. It's a language that punishes poor choice of libraries much harder than many languages (particularly if people are used to JVM languages - what libraries/frameworks can do in Scala is much closer to what they can do in Python/Ruby/...). I don't think it's "fair" to compare Scala to Kotlin on those grounds, simply because we haven't had time for generations of Kotlin frameworks to build up. But obviously that kind of fairness is not your concern if you're a business making a choice of tools.
If you're choosing a language for a short-lived codebase then Kotlin might be a good choice if it does what you want. What I would say is, if you're trying to choose a language for a codebase that will live for 5-10 years, try to think about what Kotlin is going to look like in 5-10 years. Right now Kotlin is able to be a lot cleaner than Scala (at least on a superficial level) because it doesn't have backwards compatibility with large existing codebases hanging over it. That isn't always going to be the case.