Dmitry Jemerov

Yes, you can. Kotlin is compatible with all Java frameworks, including JSF.

Your question is very broad; it would be easier for me to answer it if you could tell me what you already know about Kotlin. If you're not familiar with it at all, please check the information on the Kotlin home page: https://kotlinlang.org/

Kotlin uses the standard JDK classes for all of its core functionality, including threads. There is no difference between threaded Java code and threaded Kotlin code.

Kotlin's coroutines often provide a cleaner way to solve problems that are traditionally solved with threads, but you don't need to use them if you prefer to stick to threads.

Unfortunately I'll have to pass on this one. "Briefly summarizing" the entire landscape of concurrent programming would require writing at least a few pages of text, and this is simply too broad for this forum and the time we have now.

The variety of concurrent programming idioms exists because each idiom is best suited for a different set of tasks. I do not expect that Kotlin will converge on a single paradigm at the expense of supporting other use cases.

Retaining type information at runtime is definitely possible; you can see how this works if you look at Ceylon, another language that targets the JVM. The cost of that is that referencing such classes from Java becomes much more cumbersome, because you need to pass the values of the type parameters explicitly. Due to Kotlin's focus on interoperability, we decided that it would not be acceptable.

Also, many very useful patterns in Kotlin (for example, using type-safe keys to access a map: fun <T> getValueForKey(key: Key<T>): T) are only possible because Kotlin does _not_ have reified generics. Reified generics make some kinds of code easier to write and others harder. And for many patterns which are hard to write in Java because of type erasure, Kotlin solves the difficulty through its support for reified type parameters in inline functions.

Therefore, in my opinion, it is extremely unlikely that a future version of Kotlin will support full reified generics.

The return type of Nothing means that the function never completes successfully. In the example you've quoted, the function never completes successfully because it contains an infinite loop (while (true)). Another possibility is a function that always throws an exception (for example, a function that is used to report some error with detailed diagnostics, or a function that is used to report a failure of an assertion in a unit test).

If you're using Clojure and are happy with it, I'm not sure if Kotlin has enough to entice you. I haven't seriously used Clojure myself, but from what I know about it, I think that Clojure and Kotlin are expressive in very different ways. Kotlin is built as a modern statically-typed programming language, trying to make the type system both more powerful (through the addition of nullability) and less costly (through the support of type inference, smart casts AKA flow typing, concise class declarations, etc). Clojure, on the other hand, is much more dynamic - it supports the minimum amount of static typing support required by the JVM environment, but it prefers to use hash tables instead of explicitly declared types, and it also allows the code itself to be dynamic through the use of macros.

Of course, Kotlin's approach allows for much smoother integration into the Java ecosystem - e.g. I haven't heard of any significant number of people using Clojure to develop Android apps, while for Kotlin the migration from Java in the Android context is very straightforward, and appeals to many developers. But if you're happy with the libraries that exist in the Clojure ecosystem, then again this might not be relevant.

_More_ Java-focused? If anything, the feedback we've been getting on the documentation is usually the opposite - that we imply too much knowledge about Java and do not explain the basic concepts enough for people coming from a background of JavaScript or another language such as Python. And that's the direction in which we want to move the documentation.

And could you please point to some specific parts of the documentation that are really bad, in your opinion?

There is a standard delegate for memoization, but not for the LRU cache (this seems to be a fairly specific use case, I don't remember it coming up before).

Static property delegates are supported: you can put any expression after "by", and if this expression evaluates to a singleton object, then this object will be used as a delegate for all instances of the class. The specific instance is passed to the delegate as a parameter.

As for other unique features, I think our approach to inline functions is fairly unique.

Actually Kotlin is not shipped with any extra command-line tools other than kotlinc, which is the command-line compiler and can also be used to execute scripts and to run an interactive interpreter.

The main focus of the book is the language, not the tools. The book gives a couple of simple examples of using kotlinc and integrating Kotlin with build systems such as Maven or Gradle, but it does not provide a complete reference for the tools.

The book covers the Kotlin language in general. It includes examples from specific areas, including both Android development and back-end, but it does not focus on any specific area.

Kotlin is fully interoperable with Java. This means that you can develop any application in Kotlin that you can develop in Java. This requires no additional support from the frameworks that you're using.

The support for Kotlin in Spring 5 means that you can use a nice Kotlin DSL in some places in the API, and that you get full advantages of Kotlin's null safety when using the framework classes (because they have been annotated in a special way). You can find more information and code examples in the Spring blog: https://spring.io/blog/2017/01/04/introducing-kotlin-support-in-spring-framework-5-0

The <T> is necessary to declare a type parameter. This is required because every name in the source code needs to be declared somewhere. For example, if a function returns a List<String>, there is a String class declared somewhere (in the Kotlin standard library), and the declaration refers to it. In this case, there is no class named T, so you need to specify what T is. You do so by declaring T as a type parameter: fun <T> filter(...)

The advantage is exactly what JW says; I'm not sure what other example you need. You get a program which has fewer classes, fewer methods and runs faster.

Yes, there are quite a few applications of Kotlin DSLs for Android. For example, we at JetBrains have developed a DSL for expressing Android layouts: https://github.com/Kotlin/anko/wiki/Anko-Layouts
There are several DSLs used to express database queries, for example, Requery: https://github.com/requery/requery/wiki/Kotlin
I've also seen a DSL used for UI testing of Android applications, even though I'm not sure whether there's public English information about it.