2 ms·
Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those fe
by jillesvangurp 3y ago
Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those features to do all the crazy hacks javascript is famous for; or to be able to use libraries that use those hacks. It's a constant fight to push back that madness. With Kotlin, that's just much less of a concern. Having a language that just says no to all of that is valuable. IMHO typescript could just remove the option to turn off the strict mode and always be strict. It would be a better language. It's impractical of course because a lot of stuff would break. That's the problem with it. Don't get me wrong, I've actually used typescript and don't mind it. But I prefer kotlin.
I do indeed do a lot in Kotlin-js rather than using javascript libraries. We make a few exceptions for libraries like map-libre for which we have a very thin hand crafted Kotlin facade. Things like react we simply don't use at all (we use a pure kotlin framework called fritz2). We actually use a lot of Kotlin multi platform libraries as well. And even some wasm libraries (e.g. sqlite). Most of the foreign code dependencies in our codebase are not javascript libaries.
- rezonant 3y agoWell, strictness actually is optional in Kotlin too, since you can lateinit things and !! your way through nullability like in any language. And of course if you are consuming Java stuff this is more likely, since Kotlin exposes nullable types for everything in Java, so sometimes the right call is to non-null assert since the interface you are consuming can't represent non-nullability.