ClojureScript vs Kotlin

Figwheel builds your ClojureScript code and hot loads it into the browser as you are coding! Every time you save your ClojureScript source file, the changes are sent to the browser so that you can see the effects of modifying your code in real time.

Lispness makes ClojureScript trivial to comprehend after an initial learning overhead.

Clojure and ClojureScript are designed to be able to interact with their host. So the language by design makes it is easy to use existing JS libraries.

Google's Closure Library converts regular JavaScript into a highly optimized form - including dead code analysis/elimination. It can even remove pieces of unused code from 3rd party libraries (eg, if you import jQuery but only use one function, Google Closure includes only that piece).

Clojure is also able to run web servers, so one can reap similar benefits to NodeJS in terms of sharing code between client and server.

Both Leiningen and Boot are great build tools that manage code dependencies and deployment.

ClojureScript has superb wrappers around React.js (see Reagent) that make building single-page apps a breeze. With figwheel, it's a web dev experience unlike any other -- hotloaded code, repl interaction, and instantly reflected changes make good development fun and fast. You can add things like Garden to make CSS-writing part of the same holistic experience and suddenly all development is a pleasant, smooth process.

From the creator of Clojure:
Spec is a new core library (Clojure 1.9 and Clojurescript) to support data and function specifications in Clojure.
Writing a spec should enable automatic: Validation, Error reporting, Destructuring, Instrumentation, Test-data generation and Generative test generation.

Since Kotlin is made by Jetbrains (the developers of IntelliJ IDEA) so it stands to reason that the IntelliJ support for Kotlin is also great. Besides that, Kotlin also works well with existing Java tools such as Eclipse, Maven, Gradle, Android Studio, etc...

Kotlin runs on the JVM and Java interoperability has been one of the main objectives since the language was born. It runs everywhere Java does; web servers, mobile devices (Android), and desktop applications. It also works with all the major tools in the Java ecosystem like Eclipse, IntelliJ, Maven, Ant, Gradle, Spring Boot, etc.

All of this makes adoption extremely easy even for existing Java projects. On top of this there's also ensured Type safety and less boilerplate code needed.

Kotlin's syntax is extremely easy to understand. The language can be picked up in a few hours just by reading the language reference.

The standard library is relatively small and tight. It mostly consists of focused extensions of the Java standard library and as such adds no additional runtime overhead to existing Java projects.

Starting with version 3.0 of Android Studio, Kotlin support will be built-in. This means that it's now easier than ever to use Kotlin for existing Android projects or even start writing Android apps only with Kotlin from scratch.

This also means that Kotlin and Kotlin plugins for Android Studio will be fully supported in the future and their likelihood of being abandoned is quite small since Google is fully embracing the language for their Android ecosystem (alongside Java and C++).

Since it has such a good interoperability with Java, Java libraries, and Java tools. It can be adopted for an existing Java codebase at little to no cost. The codebase can be converted from Java to Kotlin little by little without ever disrupting the functionality of the application itself.

It's not overly OOP like Java and it does not enforce strict functional paradigms either.

Kotlin has been designed and built by developers who have an industrial background and not an academic one. As such, it tries to solve issues mostly found in industrial settings. For example, the Kotlin type system helps developers avoid null pointer exceptions. Reasearch languages usually do not have null at all, but APIs and large codebases usually need null.