Dont Try Kotlin on The Backend or You'll Get Hooked
0 likes104 views
The document discusses the benefits of using Kotlin for back-end development, emphasizing its low barrier to entry and excellent compatibility with existing Java code and libraries. It highlights features such as compile-time null safety, immutability by default, and boilerplate-less class definitions, which can enhance productivity and reduce errors. The author encourages trying Kotlin, suggesting its various capabilities can significantly improve back-end programming experiences.
Dont Try Kotlin on The Backend or You'll Get Hooked
- 1. Don’t try Kotlin on the Back-end or You’ll Get Hooked! by Oleksii Fedorov
- 2. Don’t try Kotlin on the Back-end or You’ll Get Hooked! Who am I? Oleksii Fedorov • Sr Software Engineer @ Pivotal Berlin • Entrepreneur In-house @ Pivotal Berlin • Founder @ iwillteachyoukotlin.com • Kotlin on Back-end in Production for 2+ years • Programming for more than 2/3 of my life • Writer, mentor, coach 2
- 3. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 3 You don’t have to rewrite anything
- 4. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 4 You don’t have to rewrite anything 1) Add tiny change to your Gradle/Maven build, e.g for Gradle:
- 5. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 5 You don’t have to rewrite anything 2) Create your 1st Kotlin file, in same directory with Java files:
- 6. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 6 You don’t have to rewrite anything 3) Use your Java (code and libs) from Kotlin, as if it was Kotlin:
- 7. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 7 You don’t have to rewrite anything 4) Use your Kotlin (code and libs) from Java, as if it was Java:
- 8. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 8 Barrier for entry is so low (so it’s almost a crime to not give it a shot)
- 9. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 9 Great support on back-end • Spring (Boot) is fully supported (any recent version). And since Spring 5 (Boot 2) offers more concise Kotlinesque APIs • Vert.x provides dedicated Kotlin support • Ktor, specifically created for Kotlin, offers high scalability and easy-to-use idiomatic APIs • And virtually almost any JVM library
- 10. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 10 Compile-time null-safety Compile error now > Runtime exception 1 year later
- 11. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 11 Compile-time null-safety Compiler forces you to handle possible null value:
- 12. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 12 Compile-time null-safety Instead of “if” statement, leverage safe calls:
- 13. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 13 Compile-time null-safety Handle edge cases with Elvis operator
- 14. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 14 Compile-time null-safety Thank you to Kotlin team for Smart-casting: as opposed to:
- 15. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 15 Compile-time null-safety Extension functions and properties on nullable: “car” is nullable
- 16. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 16 Type inference “car car = new car” “car entity repository car entity repository = new car entity repository” we live in the world of redundancy
- 17. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 17 Type inference If it is apparent, why repeat?
- 18. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 18 Type inference And if it is non-default, then specify it: (not redundant)
- 19. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 19 Type inference Not only variables and properties, return types too:
- 20. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 20 Type inference No type inference for function arguments (because compiler will become insanely slow) (and your code insanely complicated)
- 21. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 21 Immutability by default Variables, properties and collections
- 22. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 22 Immutability by default “val” is preferred over “var”
- 23. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 23 Immutability by default Collections don’t have modifying methods by default
- 24. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 24 Immutability by default And you can make it mutable if you need it
- 25. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 25 Proper “==”
- 26. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 26 Named arguments and default parameter values Build your own light-weight DSLs
- 27. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 27 Named arguments Object factory methods for your test suite where you specify only things you care about
- 28. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 28 Default parameter values Object factory methods for your test suite where you specify only things you care about
- 29. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 29 Named arguments When you want to pass them in order you want
- 30. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 30 Named arguments and default parameter values Find your own usage that improves readability
- 31. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 31 Boilerplate-less class definitions Less redundancy!
- 32. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 32 Boilerplate-less class definitions Short syntax for constructors
- 33. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 33 Boilerplate-less class definitions Short syntax for binding constructor parameters to properties
- 34. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 34 Boilerplate-less class definitions Data classes for your DTOs
- 35. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 35 Boilerplate-less class definitions Data classes: “==” based on field values
- 36. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 36 Boilerplate-less class definitions Data classes: “.copy(…)” to create new instance and modify only few fields:
- 37. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 37 Boilerplate-less class definitions Data classes: convenient “.toString()”
- 38. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 38 Boilerplate-less class definitions Data classes: convenient “.hashCode()”
- 39. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 39 Boilerplate-less class definitions Data classes: de-structuring
- 40. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 40 Boilerplate-less class definitions Properties: concisely define default getter and setter
- 41. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 41 Boilerplate-less class definitions Properties: separate visibility of getter & setter
- 42. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 42 Boilerplate-less class definitions Properties: custom implementation of getter/setter
- 43. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 43 Ever wished this other class from standard lib had certain method X? With extension methods & properties now you can!
- 44. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 44 Extension methods It’s like “monkey-patching” (from Ruby) It’s like “adding method to prototype” (from JS) but without negative consequences you have to import it where used
- 45. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 45 Extension properties When you want to make it feel like accessing a property ALT+ENTER auto- import works here
- 46. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 46 Extension methods & props • No global scope pollution • They do not modify original classes • They are basically a syntax sugar: • Except that you can call them as methods/props
- 47. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 47 So much more we can talk about proper function types “it” passed lambdas look like blocks lambdas with receiver for DSLs + infix functions
- 48. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 48 And more absolutely amazing for SQL in your repositories stop treating certain things as exceptions (int, bool) forgot to handle a case for enum, use exhaustive when just what you want from a singleton!
- 49. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 49 And more
- 50. Don’t try Kotlin on the Back-end or You’ll Get Hooked! 50 I’m covering all of that in: iwillteachyoukotlin.com/newsletter bit.ly/2MSsuZG or Thank you! Questions & Answers