24 ms·

What are the things you liked about Kotlin that Typescript didn’t have or did poorly? I’m not familiar with Kotlin at all.

by vosper 5y ago

xrd 5y ago
The biggest thing was automatic null checking. That is such a pain in Java and has bitten me so hard many times. Having the language prevent you from writing code that can crash because of a null access violation is a big step forward. There were other things that made Kotlin seem more modern to me, but I'm foggy now on what they were. But, when I wrote Android, I would always choose Kotlin for new projects.
- eyelidlessness 5y ago
  TypeScript has strict null checks and has only made them stricter over recent releases.
- comp_throw7 5y ago
  Yeah, like the other commenter said, Typescript has better (more comprehensive) null-checking than Kotlin (and, imo, a better type system in general). Obviously both are miles ahead of Java.
lf-non 5y ago
A few things Kotlin does better: - The annotation support is just better. JS ecosystem has forever been debating on decorator spec, but kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation. - Support for builder dsl is just better. The js ecosystem has embraced ugly & verbose embedded XML (JSX) thanks to fb, but in kotlin we can do something like: html { body { div(id="hello") { span(text="whatever") } } } This is just syntax sugar for lambdas passed as last arg to a function, but it makes code a lot more readable. - Inline methods - we don't have to worry about being functional vs being performant in most common cases. The implementations of map/reduce etc. in stdlib are all inline methods and compile down to for loops. - Implicit it (single argument in lambda) and implicit this (in class methods) are minor niceties but they reduce verbosity of everyday code quite a bit. - Interfaces don't get erased - you can use reflection to get interface references, check if an object complies with an interface at runtime. In TS this requires ceremony and assistance from third party libraries like zod/fp-ts etc. - Extensions are cool, you can add extension functions to classes you don't control to mold their API in specific contexts. In JS world we can monkey patch whatever and TS interface merging helps with that but its a pattern generally frowned upon and prone to conflicts (which extension functions are not). - Companion objects are nice to have. Instead of static methods/properties, you have a singleton associated with a class which can comply with any interface, can have its own extensions, can be passed around etc. - Kotlin doesn't have F#/OCaml style pipelines, but you can achieve similar chaining by combining let/apply/with/also extensions. Eg. getName().let { it.contains("foo") }.also { println(it) } - expected & actual are pretty handy for multiplatform development What TS does better: - Structural typing: its a better fit when modelling types for a highly dynamic language. Being able to define interfaces for data coming from sources you can't control without needing mappers etc. makes life simpler. - Features like intersection type, index types etc. are useful and missing in Kotlin. - Compilation times are much better. - large collection of typedefs in the definitively typed repo. My current role involves mostly working with TS and a day doesn't go by that I don't miss kotlin.
- crummy 5y ago
  If I had one request for TS it would be extension functions. Such a great feature in Kotlin and would be even better in TS.
- comp_throw7 5y ago
  No comment on decorators (I think they were a mistake to implement at all, and the TS team agrees), but extension functions? Putting aside the question of how often it makes sense to uses classes at all in Typescript, you can always just... extend a class (or interface) with whatever function you want? It's not like Typescript has sealed classes/interfaces. I might be misunderstanding? Most everything else seems to come down to "Typescript is meant to be runtime-only", which definitely has upsides and downsides (I agree that the lack of meaningful reflection support is annoying).
  - ptx 5y ago
    Let's say we have a list of strings and want to filter for those starting with "a". In Kotlin, we can use an extension function defined on the standard Java ArrayList object: myStringList.filter { it.startsWith("a") } ...and on arrays: myStringArray.filter { it.startsWith("a") } ...and on, for example, a boolean array (a standard JVM primitive array object): myBooleanArray.filter { it != false } This works for any kind of array and any kind of list, etc., even though the objects are ordinary JVM arrays and lists. In Java, because it lacks extension functions, the stream functions are often not accessible from the object itself, so you have to hunt for where they've decided to put them for this particular type. In the first case, we do have a stream method on the list: myStringList.stream().filter(s -> s.startsWith("a")).toList(); But in the case of arrays, we have to hunt down a static method in the Arrays class: Arrays.stream(myStringArray).filter(s -> s.startsWith("a")).toArray(); And in the last case, with a boolean array, that method doesn't work and the solution I've seen suggested is this wonderful mess (involving a different static method on a different class): IntStream.range(0, myBooleanArray.length).mapToObj(i -> myBooleanArray[i]).filter(b -> b != false).toArray();
  - lf-non 5y ago
    > you can always just... extend a class (or interface) with whatever function you want Not quite. Extension functions are statically resolved and abide by usual access modifiers. So within a class, I can have a private extension method for another class (say C). Now if my class receives any instance of C, I can call these extension methods on this instance. But when I forward this instance to someone else, they wont have access to any of these extensions. Libraries like exposed use this quite extensively. > Most everything else seems to come down to "Typescript is meant to be runtime-only" Yes, this one too because it would involve type directed emit.
jillesvangurp 5y ago
Data classes, co-routines and flows, internal dsl support, null checks, smart casts, type inference, an IDE that is actually smart, a standard library that is a bit more comprehensive than what a browser has, a lot of kotlin and kotlin multiplatform libraries, and more. The general feel of the language is that of one developed by people who deeply understand what a nice language should feel like. It has a lot of features and syntactic sugar that eliminate verbosity, make things more straight forward to use and so on. It really shows that this is a language designed from the ground up to be genuinely nice to use by people who really know what they are doing because their core business is selling developer tools to developers. I like typescript. It is a big upgrade from Javascript and MS has a lot of the same mindset that Jetbrains brings to the table in terms of developer friendly-ness and language ergonomics. Kotlin has most of the features that make typescript nice but without the whole business of trying to keep it compatible with javascript. That adds a lot of complexity, ambiguity, and weirdness to typescript that Kotlin simply does not have or need.

What are the things you liked about Kotlin that Typescript didn’t have or did poorly? I’m not familiar with Kotlin at all.

by vosper 5y ago

What are the things you liked about Kotlin that Typescript didn’t have or did poorly? I’m not familiar with Kotlin at all.

xrd 5y ago

The biggest thing was automatic null checking. That is such a pain in Java and has bitten me so hard many times. Having the language prevent you from writing code that can crash because of a null access violation is a big step forward. There were other things that made Kotlin seem more modern to me, but I'm foggy now on what they were. But, when I wrote Android, I would always choose Kotlin for new projects.

eyelidlessness 5y ago
TypeScript has strict null checks and has only made them stricter over recent releases.
comp_throw7 5y ago
Yeah, like the other commenter said, Typescript has better (more comprehensive) null-checking than Kotlin (and, imo, a better type system in general). Obviously both are miles ahead of Java.

lf-non 5y ago

A few things Kotlin does better: - The annotation support is just better. JS ecosystem has forever been debating on decorator spec, but kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation. - Support for builder dsl is just better. The js ecosystem has embraced ugly & verbose embedded XML (JSX) thanks to fb, but in kotlin we can do something like: html { body { div(id="hello") { span(text="whatever") } } } This is just syntax sugar for lambdas passed as last arg to a function, but it makes code a lot more readable. - Inline methods - we don't have to worry about being functional vs being performant in most common cases. The implementations of map/reduce etc. in stdlib are all inline methods and compile down to for loops. - Implicit it (single argument in lambda) and implicit this (in class methods) are minor niceties but they reduce verbosity of everyday code quite a bit. - Interfaces don't get erased - you can use reflection to get interface references, check if an object complies with an interface at runtime. In TS this requires ceremony and assistance from third party libraries like zod/fp-ts etc. - Extensions are cool, you can add extension functions to classes you don't control to mold their API in specific contexts. In JS world we can monkey patch whatever and TS interface merging helps with that but its a pattern generally frowned upon and prone to conflicts (which extension functions are not). - Companion objects are nice to have. Instead of static methods/properties, you have a singleton associated with a class which can comply with any interface, can have its own extensions, can be passed around etc. - Kotlin doesn't have F#/OCaml style pipelines, but you can achieve similar chaining by combining let/apply/with/also extensions. Eg. getName().let { it.contains("foo") }.also { println(it) } - expected & actual are pretty handy for multiplatform development What TS does better: - Structural typing: its a better fit when modelling types for a highly dynamic language. Being able to define interfaces for data coming from sources you can't control without needing mappers etc. makes life simpler. - Features like intersection type, index types etc. are useful and missing in Kotlin. - Compilation times are much better. - large collection of typedefs in the definitively typed repo. My current role involves mostly working with TS and a day doesn't go by that I don't miss kotlin.

crummy 5y ago
If I had one request for TS it would be extension functions. Such a great feature in Kotlin and would be even better in TS.
comp_throw7 5y ago
No comment on decorators (I think they were a mistake to implement at all, and the TS team agrees), but extension functions? Putting aside the question of how often it makes sense to uses classes at all in Typescript, you can always just... extend a class (or interface) with whatever function you want? It's not like Typescript has sealed classes/interfaces. I might be misunderstanding? Most everything else seems to come down to "Typescript is meant to be runtime-only", which definitely has upsides and downsides (I agree that the lack of meaningful reflection support is annoying).
- ptx 5y ago
  Let's say we have a list of strings and want to filter for those starting with "a". In Kotlin, we can use an extension function defined on the standard Java ArrayList object: myStringList.filter { it.startsWith("a") } ...and on arrays: myStringArray.filter { it.startsWith("a") } ...and on, for example, a boolean array (a standard JVM primitive array object): myBooleanArray.filter { it != false } This works for any kind of array and any kind of list, etc., even though the objects are ordinary JVM arrays and lists. In Java, because it lacks extension functions, the stream functions are often not accessible from the object itself, so you have to hunt for where they've decided to put them for this particular type. In the first case, we do have a stream method on the list: myStringList.stream().filter(s -> s.startsWith("a")).toList(); But in the case of arrays, we have to hunt down a static method in the Arrays class: Arrays.stream(myStringArray).filter(s -> s.startsWith("a")).toArray(); And in the last case, with a boolean array, that method doesn't work and the solution I've seen suggested is this wonderful mess (involving a different static method on a different class): IntStream.range(0, myBooleanArray.length).mapToObj(i -> myBooleanArray[i]).filter(b -> b != false).toArray();
- lf-non 5y ago
  > you can always just... extend a class (or interface) with whatever function you want Not quite. Extension functions are statically resolved and abide by usual access modifiers. So within a class, I can have a private extension method for another class (say C). Now if my class receives any instance of C, I can call these extension methods on this instance. But when I forward this instance to someone else, they wont have access to any of these extensions. Libraries like exposed use this quite extensively. > Most everything else seems to come down to "Typescript is meant to be runtime-only" Yes, this one too because it would involve type directed emit.

jillesvangurp 5y ago

Data classes, co-routines and flows, internal dsl support, null checks, smart casts, type inference, an IDE that is actually smart, a standard library that is a bit more comprehensive than what a browser has, a lot of kotlin and kotlin multiplatform libraries, and more. The general feel of the language is that of one developed by people who deeply understand what a nice language should feel like. It has a lot of features and syntactic sugar that eliminate verbosity, make things more straight forward to use and so on. It really shows that this is a language designed from the ground up to be genuinely nice to use by people who really know what they are doing because their core business is selling developer tools to developers. I like typescript. It is a big upgrade from Javascript and MS has a lot of the same mindset that Jetbrains brings to the table in terms of developer friendly-ness and language ergonomics. Kotlin has most of the features that make typescript nice but without the whole business of trying to keep it compatible with javascript. That adds a lot of complexity, ambiguity, and weirdness to typescript that Kotlin simply does not have or need.