Serious question, not a troll. Javascript and Kotlin are two very different languages but it's always interesting to take a look at what other developer communities are doing.
If you know both languages, are there any particular aspects that you find Typescript does better than Kotlin?
Or if you are a front-end developer and don't know Kotlin, what are the parts of Javascript/Typescript where you find that the language is at best, concise, safe and eloquent?
The inspiration for this question comes from my last post, I wrote about a nice pattern I found for extracting constants in Kotlin
with(ConfigObject) {
println("Language $KOTLIN is sparking $JOY")
}
And I was blown away by a comment from KIP who reminded my that almost the same exact thing was possible in Javascript
with(ConfigObject) {
console.log(`Language ${TYPESCRIPT} is sparking ${JOY}`)
}
Kotlin is a very nice language, but also a relatively new one and there are still new useful patterns to discover. So I wondered: could I not accelerate this process by taking inspiration from Javascript's good parts?
I looked at the code produced by colleagues from the front-end, and one thing I like is object destructuring
const {id, firstName, lastName} = person
Kotlin also has object destructuring
val (id, firstName, lastName) = person
But in my experience, it's not used very much. One problem is that it is position-based. The code above may we working right now, but if someone changes the order of the properties in the Person
class, the code will fail. Typescript named-based approach is clearly better. Having realized that, I discovered a proposal to implement the same solution in Kotlin https://youtrack.jetbrains.com/issue/KT-19627
Good solution in the long term. But in the long term, we are all dead!
Can I somehow find a pattern that works now to implement something like what Typescript does? As it turns out: YES
Here I used again with
to transform what I need from my object into something I can easily destructure. It's much more general than what Kotlin offers by default, which works only for "the properties of a data class or a Tuple".
Top comments (6)
Kotlin is for the Jvm ecosystem as far as I can tell, it's not an out and out superset of JavaScript nor is it trying to be. It just happens to have multiple compile targets, one just happens to be JavaScript, but Kotlin is not JavaScript and not really related.
As for features, you will find many aforementioned in multiple other languages.
i'm using javascript daily, and agree with you not related topic parts, every language has it's own env, community, advantages and disadvantage, don't forget Kotlin came as alternative for java, so in ancient times we agreed no relation between java and javascript. if there javascript will lose as a programming language.
I'm not confusing anything.
When I look at Ruby on rails code, it gives me ideas that I can take with me in other languages that are not "related to Ruby".
I don't see it as a good thing that developers don't look at what other communities are doing.
I edited the first sentence of my post.
I think your post is valid and certainly something I asked myself a few months back. I love the look of Kotlin and I use typescript as much as not.
Another language which you might find interesting is Lua, it has a fascinating community, syntax and backstory.
My point is that when they designed kotlin, jetbrains has been unafraid to take inspiration and copy what works well in other languages. What helped is that they have in house specialists from every language out there. By following their example I can maybe discover useful design patterns
Since the dawn of programming language design people have been borrowing features and applying them to the new language through grammer. I am writing Jess which is based on JavaScript and css syntax, that is because there is a problem here I am trying to solve, inherently I need feature from both languages so that I can have js and css as compile targets. It's the same story for Kotlin, if you could only write a portion of a compile target, say half of JavaScript, you would have an inferior compiler. So IMHO it's nothing to do with design, it's just a problem to solve.