4 ms·
>"Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points." Would you mind elaborating on what those Java pain poi
by bogomipz 9y ago
>"Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points."
Would you mind elaborating on what those Java pain points are that Kotlin smoothes over?
Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?
- edem 9y agoThat's incorrect. Right now I do all my development in Kotlin at my workplace and on the backend. We use Spring (which has native Kotlin support from 5.0 btw: https://spring.io/blog/2017/01/04/introducing-kotlin-support-in-spring-framework-5-0 https://spring.io/blog/2017/01/04/introducing-kotlin-support...) and deploy to a Kubernetes cluster. It is absolute seamless. I'll never write server-side code in Java again if I can help it.
- vbezhenar 9y ago> Would you mind elaborating on what those Java pain points are that Kotlin smoothes over? 1. Explicit semantics for nullable variables. It helps to convey information whether this function can accept or return null and compiler checks that your code won't throw NullPointerException. It's not ideal when you're dealing with Java code, but it works. 2. Explicit and convenient semantics for mutable and immutable variables. You can use `final` in Java for variables or parameters, but few people do that, because code becomes quite verbose. With Kotlin you are using `val` or `var`, so code doesn't become more verbose. 3. Almost everything is an expression. Helps to write concise code sometimes and makes a language more consistent. 4. Compiler changes type of variable when developer checks for this type. So you don't have to write nonsense like `if (a instanceof String) f((String) a)`, instead you write `if (a is String) f(a)`. 5. Better replacement for `switch` statement. Kotlin's `when` statement has more features. Not a proper pattern-matching, though. 6. Default values for function parameters. With Java you have to write lot of function overloads with slightly different set of parameters and delegate it to a single function. With Kotlin you're writing one function with optional parameters. 7. Named arguments. Sometimes it leads to much more readable code. 8. Generic parameters can be covariant or contravariant. Basically you can assign `List<Integer>` to variable of type `List<Number>`. It helps sometimes. 9. Operator overloading. `a + b` instead of `a.plus(b)`; `m["x"]` instead of `m.get("x")`. Code looks much more natural, when used appropriately. 10. Singletons. Kotlin doesn't have static classes, instead it has `object`s, which are implementation of singleton pattern. They can implement interfaces, for example. 11. Proper properties. getter/setters generated automatically, property access looks like field access, but with all perks the methods have. 12. No need for artificial utility classes, which are not really a classes, but just a bunch of static methods. You can either use plain functions at top-level or enhance existing classes with utility methods. `str.isBlank()` instead of `StringUtils.isBlank(str)`, for example. Generally Kotlin is much less verbose than Java, but it's concise enough and doesn't try to be implicit or magical. > Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect? According to Kotlin developers their user base was roughly 50% : 50% between server side and Android. I used Kotlin for small server side projects, it works almost flawlessly with standard Java frameworks like Spring or Hibernate.
- bogomipz 9y agoThank you for the detailed response. Cheers.