4 ms·
Kotlin looks promising. Sure, you can use the whole JVM ecosystem with Kotlin/JS or Kotlin Native. But it looks like JetBrains is trying to bootstrap a JVM-inde
by mwcampbell 8y ago
Kotlin looks promising. Sure, you can use the whole JVM ecosystem with Kotlin/JS or Kotlin Native. But it looks like JetBrains is trying to bootstrap a JVM-independent Kotlin ecosystem.
So why Kotlin instead of TypeScript?
1. Potentially more static optimization, because Kotlin is designed from the start for static typing.
2. Ability to target other platforms (Android, iOS, desktop) without adding the overhead of a JS runtime.
Why not Scala?
1. Scala's standard library is heavier. For instance, Scala has its own collection classes, whereas Kotlin merely has its own collection interfaces. I assume this is why Scala.js advertises a starting size of 45 KB gzipped for an optimized build. That's not actually very small.
2. On the JVM, Scala fundamentally gets interop wrong in at least one way: Java getters and setters don't automatically become Scala properties, as they do in Kotlin. So idiomatic real-world Scala requires more wrappers.
The one thing that worries me about Kotlin is that it has reflection instead of compile-time metaprogramming (e.g. macros). Wherever reflection is used, it impedes static optimization (e.g. ProGuard, other tree-shaking). Sure, real-world JVM work has to use reflection sometimes, but at least JetBrains should have refrained from providing an API for doing Kotlin-specific reflection, and provided something like macros instead. (Edit: And yes, the Kotlin reflection API is implemented in the JS back-end. That was a mistake.)
- mwcampbell 8y agoOops, meant can't use the whole JVM ecosystem with JS or Native.