Kotlin is a great language for developing server-side applications; it's an object-oriented language and also a functional one, supporting features such as function types, lambdas or higher order functions. But...is this enough to switch completely from a imperative paradigm to a functional paradigm? In this talk we'll see how features from Arrow library completes Kotlin in order to follow a pure functional way.

1. Kotlin & Arrow:
The functional way
Noe Luaces
@noe_luaces

2. ● Galician since I have memory (now living
in Barcelona)
● Avid comic book reader since I was a
teenager
● Software Engineer since October 2007
● Kotlin Developer since October 2018
> whoami

3. What is
Kotlin?

4. Designed to
interoperate fully with
other JVM-based
languages
Object
Oriented
Kotlin is...

5. Designed to
interoperate fully with
other JVM-based
languages
Object
Oriented
Great introductory
language to
functional
programming
Functional
Kotlin is...

6. Designed to
interoperate fully with
other JVM-based
languages
Object
Oriented
Great introductory
language to
functional
programming
Can be used in
backend, frontend or
as a script language
Functional
General
Purpose
Kotlin is...

7. Designed to
interoperate fully with
other JVM-based
languages
Object
Oriented
Great introductory
language to
functional
programming
Can be used in
backend, frontend or
as a script language
Functional
General
Purpose
Kotlin is...
Android has officially
adopted Kotlin as the
supported language
for mobile
development services
Mobile
Standard

8. ● Developed by JetBrains in 2011
● Its name comes from Kotlin island,
Russia
Kotlin background

9. ● JetBrains lead Dmitry Jemerov said
that they were looking for a language
with the same features as Scala but
with a compilation velocity similar to
Java
Kotlin background

10. Function type

11. Function Type
● Functions in Kotlin are first-class values
● They can be assigned to variables and passed around as parameters

12. Function Type (function reference)

13. Function Type

14. Function Type

15. Function Type

16. Higher Order
Functions

17. Higher Order Functions
● Functions that accept parameters typed as a function
● Functions that accept lambda expressions as parameters

18. Higher Order Functions
● Scope functions like run, apply, let, with, also accept a lambda expression
● Other functions such as map, flatMap, filter, fold

19. Higher Order Functions

20. Pure Functions

21. Pure Functions
● Depend only on the input to produce the result, not on any hidden
information or external state
● Have no observable side effects, like modifying a variable passed by
reference.
● Hence, they are easy to test

22. Pure Functions

23. Not pure functions

24. Immutability

25. Immutable objects
● Remain in exactly the state in which they were created. Therefore, they are
thread-safe
● Are easier to write, use and they make cleaner code
● Make easier to parallelize the program as there are no conflicts among
objects

26. Immutable objects
● Are preferred whenever possible in Kotlin
● Are defined with the keyword val and can be initialized only single time
● Data classes, that hold the state which they were created with

27. Immutable objects

28. Pattern
matching

29. The "when {}" block
● Advanced form of the switch-case statement known from Java
● No break statements are needed at the end of each case

30. The "when {}" block
● Due smartcast, we can access methods or properties of the type without
extra checks
● Smartcast also works with subclasses providing a full pattern matching
● Could be used as an expression or a statement

31. The "when {}" block

32. The "when {}" block

33. Currying

34. Currying
● Is a mathematical technique
● Consists on breaking down a function that takes multiple arguments into a
series of functions that each take only one argument

35. Currying

36. Null safety

37. Null safety
● Explicit nullable declarations
● Safe calls
● !! operator

38. Null safety

39. What is missing?
In Functional Programming, we try to avoid throwing exceptions:
● For methods which fail often and predictably, like parsing user input as a
number, it’s costly and unnecessary to throw exceptions
● Handling checked exceptions can easily make the client’s code needlessly
complicated

40. What is
Arrow?

41. Arrow background
● Open source library sponsored by 47 Degrees
● Fusion between KATEGORY and funKTionale, the most
relevant FP libraries for Kotling in 2017
● First release was available in 2018
● Equivalent to Cats for Scala and Vavr for Java

42. Modeling absence

43. Data Type: Option
● Avoids NullPointerException, without error detail
● Possible values: None or Some

44. Data Type: Option

45. Dealing with Option values: Fold
{() -> "Nothing!"}
{(Book) -> "Book.name found!"}

46. Dealing with Option values: Fold

47. Dealing with Option values: Fold

48. Capturing
Throwable

49. Data type: Try
● Useful to handle Runtime Exceptions
● Failure or Success
● Can be combined with a when statement that uses smart cast

50. Data type: Try

51. Modeling Errors

52. Data type: Either
● Represents a value with two possibilities
● Left (error case) or Right (happy case)
● Allows to fail fast providing all the context

53. Data type: Either

54. Data type: Either

55. Dealing with Either values

56. {cat -> IsDeadFailure(cat)}
{ cat -> cat.name}
Dealing with Either values: Bimap

57. Dealing with Either values: Bimap

58. Dealing with Either values: Bimap

59. Dealing with Either values

60. Modeling Parallel
Errors

61. Data type: Validated
● Collect all errors at once
● Possible values: Valid or Invalid
● Often used the typealias ValidatedNel ( instead of Validated<Nel>)

62. Data type: Validated

63. Data type: Validated

64. Data type: Validated

65. To sum up...
KOTLIN ARROW
HIGHER ORDER FUNCTIONS ✅
IMMUTABILITY ✅
PATTERN MATCHING ✅
CURRYING ✅
EITHER ✅
OPTION ✅
TRY ✅
VALIDATIONS ✅

66. Why Kotlin?
● Concise syntax
● Null safety
● Ease of transition from Java
● Interoperability with other JVM-based
languages
● Introductory language to functional
programming
● Android's adoption as the supported
language

67. Why Arrow?
● Data types
● Type classes
● Effects
● Optics
● Other functional programming
patterns as higher- level abstractions
ready to use

68. Noe Luaces
@noe_luaces
Thank you