Java (via GWT) vs Kotlin

That's Java, so it is strongly typed, and we can use fully the IDE: error detection, refactoring, auto-completion, etc.

Perfect if you have a strong background in Java programming, and need to code for the client side.

Because Java is statically typed, integrated development environments (IDEs) for Java can provide a lot more feedback on errors you will encounter. Java IDEs can give you specific errors in the location where they occur without having to run the code every time. This makes is faster to debug and learn from your mistakes.

IDEs also have extensive auto complete capabilities that can help you learn the programming libraries you are using faster and tell you what functions are available.

Java is one of the most popular languages in industry, consistently ranking either first, or occasionally second (behind C or Javascript) in terms of usage. Polls (see sources below) show it to be consistently in high demand, particularly as measured by job board postings. This makes Java a great time investment, as you will be easily able to get a job utilizing your skills, particularly as those Java applications in production now will continue to need maintenance in the future. It also results in great support for tools and plenty of computer science books, example projects and online tutorials.

Most Java code follows very standardized coding styles. This means that when you're starting out, there are fewer questions about how you should implement something as the programming styles and patterns are well established and consistent. This consistent style means that it's often easier to follow others' example code, and that it's more likely to meet at least a certain minimum standard of quality. This discipline with consistent stylistic standards also becomes useful later, when collaborating on projects with larger teams.

Produced JS is highly optimized, can be separated in modules with lazy loading, can be internationalized while loading only the chosen language.

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.