3 ms·

Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a

Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience. That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode. > Unlike typescript, it does not really have a non strict mode (except for the dynamic keyword so you can deal with some js libraries and its weird type system). Why is the existence of non-strict mode a concern for you if you are using strict mode? After all, whether you are using Typescript or kotlin-js, you are likely to have JS dependencies, and those might not be written with Typescript strict mode. I guess you could just opt not to use any "native" (Javascript) dependencies and just do it all in Kotlin JS, but beyond a certain point that's not very practical.

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 ago
  Well, 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.

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 ago
Well, 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.