Additionally, Nim also has its own runtime, https://nim-lang.org/araq/ownedrefs.html.
Which most likely doesn't have 25 years of optimization algorithms, and monitoring tools, invested into it.
So "No JVM" isn't necessary an advantage.
IntelliJ would be still dog slow even if written in C.
Non stopping indexing files on every startup isn't something that changes with the programming language, or the slowness doing code completion on C and C++ code, despite usage from clangd.
There's also Kotlin JS, which targets the JS ecosystem, and comes with tools that let you import TypeScript type definitions into Kotlin, so you can easily interact with third-party JS modules.
A pure Kotlin library could easily be used on JS, JVM, and native/LLVM seamlessly. Which is pretty impressive. All your non-platform-dependent logic could be placed in a decoupled shared pure Kotlin library. Which avoid code duplication that is so common when you need web + iOS + Android client apps. (And the Intel Multi-OS Engine could be used to write your iOS app in Kotlin.)
Does it mean that startup is slow (possibly due to AOT)?
Does it mean that consumes a lot more memory than the equivalent C/C++/JS/Python/etc program? (I don't think so.)
Does it mean that code execution is too slow? (This hasn't been true for over a decade or close to two; the JVM's JIT is one of best ever.)
Does it mean the GC pauses are too painfully apparent? (I don't think this is true at all.)
Does it mean that users of JVM languages have a tendency to write code that is in inefficient/slow/bloated on average? (Again, I'd say this isn't true; and I've seen code to tend heavily more on the inefficient more so with dynamically typed languages in general.)
So, what really does "heavy" mean here?
(Lastly, while the core compiler tooling for Kotlin is probably reliant on the JVM, you don't have to use a JVM-based IDE for sure - VS Code (which is written in TypeScript/JS) should work fine as well.)
