While Java is one of the world's most widely used programming languages and is the most preferable language for android development but there are many reasons why Java might not always be the best option for your Android projects.
Java isn’t a modern language, and although Java 8 was a huge step forward for the platform, introducing lots of features that developers had been waiting for (including lambda functions), Android only supports a subset of Java 8 features.
It seems unlikely that Android developers will be reaping the full benefits of Java 8 anytime soon, so in future if you want to use Java in your Android projects, then you’re pretty much stuck with Java 7.
Although Java is starting to add some functional programming elements, such as lambda expressions and functional interfaces, at its core Java is still a procedural language. Java’s syntax is also pretty verbose, particularly when compared to many modern programming languages.
Kotlin is intended to be a simpler Scala. If you look a Scala and Kotlin syntax for the basic constructs you’ll see that they are almost identical. That’s no coincidence: Kotlin took a good look a Scala but removed the most complex/advanced & also most dangerous features (e.g. implicits).
Kotlin achieves 80% of Scala’s power with 20% of the complexity.
Especially the collections in the standard lib are much simpler than that of Scala
Scala is a very multi-paradigm language that can range anywhere from being a better Java to a worse Haskell. This means that Scala libraries and codebases often use a variety of different coding styles, and learning to work with them all can take a long time. Plus it makes it harder to standardize a team. In contrast, Kotlin doubles down on being a better Java, so libraries are more consistent and it can avoid many of these issues.
Kotlin has really seamless Java interop. Scala kinda-sorta allows Java interop, but it’s actually fairly painful to work with, to the extent that the most popular Java libraries have Scala-specific wrappers written for them.
You can migrate existing projects from Java by starting to write new classes in Kotlin immediately. The interoperability with Java is done quite well; Scala and Closure are worse in it.
Kotlin gets some nice syntactic sugar by focusing on the most common use cases, while Scala takes on some additional burden by trying to be very general. For example, Kotlin has very simple syntax for safe Null handling, while Scala uses a general notion of union types which is a bit clumsier.
Kotlin compiles faster, especially with large codebases compared with scala
Kotlin is heavily backed by Jetbrains, who make some truly excellent pieces of software. Scala no longer has the same centralized level of support; even TypeSafe changed their name to Lightbend and pulled back from Scala.
Kotlin is much faster to learn for people with Java backgrounds.
Cut down significantly on the verbosity and boilerplate that Java imposes.
Offer a much easier and more fluent way to use functions and lambdas.
Offer the advantage of a way to use the JVM platform without having to write Java.
Swift and Kotlin are two great languages for iOS and Android development respectively. They both have very modern features and syntax that can help enormously to build native apps.
Swift Enums are more powerful: In Swift, enums are very powerful and first-class type. They can contain different associated values per case (discrete union types), computed properties and most of the features of structs. Because of that, it is frequent to see patterns like the Result enum that are not common in Kotlin due to language limitations, A similar pattern can be implemented in Kotlin by using sealed class instead of enum, but it is more complicated that the Swift counterpart
Swift has no data class: One interesting construction in Kotlin is data class. It allows you to declare containers of information that automatically implement things like equality and copying. Very common pattern when dealing with plain objects that has no counterpart in Swift.
Swift does not have delegated classes or delegated properties: A very interesting feature of Kotlin are delegated classes and properties. With them, you can forward invocation of methods to another class automatically, or define behaviors for properties such as lazy, observable, etc.
Swift does not allow annotations: Coming from the Java world, Kotlin has full support for annotations. However, in Swift that is not considered at all, so annotations like @Inject or @Test that are so common in Java libraries do not have any counterpart in Swift.
Kotlin has no tuples: Tuples are not implemented in Kotlin, so you will find yourself creating small data classes as counterpart for Swift tuples.
Memory management: Kotlin assumes the existence of a Garbage Collector (provided by the Dalvik/Art runtime in Android) and therefore memory management is transparent for the developer. On the other hand, Swift manages memory with a Reference Count approach (ARC) so you will need to think about memory ownership and retain cycles.
If you are coming from C#, Java or Kotlin, then Kotlin may be the better choice. If you’re already used to Spring and various Java libraries, then Kotlin may be the better choice.
Kotlin has strong type system thanks to the type inference which will save you many headaches. Since types are inferred, you aren't forced to type out the types the whole time, so a sleek syntax + type safety.
Co-Routines which IMO is much easier and cleaner to use than ES6's Promises in NodeJS
Kotlin Native will in the future allow you to run Kotlin without the JVM
Kotlin has null safety and it is a huge advantage over JS.
Kotlin is a JVM language, which IMO is trying to improve on Java in features and conciseness, while remaining imperative and static. Groovy has a similar concept except decided to go dynamic. As a result, a number of language features will be similar.
Static vs Dynamic: Since Groovy was designed as a dynamic language, and @CompileStatic, while a great annotation (I use it a lot), was added later. Its feature feels a bit bolted on, and it does not enforce people to code in a static manner. It's not usable everywhere (e.g. my Spock tests seem to fail to compile with them). Sometimes even with it on Groovy still seems to have some odd dynamic behaviour every now and then. Kotlin is 100% Static, and dynamic is not an option.
Higher-Order Functions, defined like "fun doStuff(body: Int -> T)): T". Which are much better than the groovy Closures IMO. (very similar to Scala's)
Kotlin doesn't do any implicit conversions, on other hand - groovy implicitly converts double to bigdecimal and so on.
Ternary operator: Both, Groovy and Kotlin provide Elvis operator but the ternary operator is missing from the Kotlin.
Kotlin is null-safe which is perhaps the most valued feature of Kotlin. The null safety feature of Kotlin protects developers from accessing the properties of a null reference, Groovy does not have any Null-safety
Unlike Groovy there is no new keyword in Kotlin. To create an instance of a class you can just use class name with constructor parameters.
Unlike Groovy there is no implicit narrowing/widening conversion for numbers in Kotlin.
Go is very easy to learn and has several interesting concepts like the go funcs and the channel system which makes it a scalable language. But I personally think it also has it’s disadvantages. For example it requires to write much boilerplate code. You need to convert data all the way around.
Kotlin runs on the Java virtual machine, Golang produces native code and does not run on the JVM.
Kotlin plays well with all the libraries for JVM languages, including Java, Scala and Clojure; Golang is a bit harder to link with foreign libraries, but the selection you have there is all the platform native libraries (possibly excluding some advanced C++ libraries because of their API).
1. Install Latest JDK and set Java in Path variable
2. Install IntelliJ IDE for code development
Google did not replace Java, they added Kotlin official support.
This article is written by Pavan, who is serving notice period in an MNC, Bangalore. He thought, let the articles speak rather than his image. He is also the same person who created the reporter for Protractor Jasmine