The evolution of Arrow has truly been spectacular. As a framework developer myself I can relate even more with a lot of the challenges Simon describes. Over the past years I have considered dabbling with arrow at multiple stages, and my experience has gone from being extremely overwhelmed in the pre 0.12 days to being completely wowed by how simple and idiomatic it has become post 1.x, and the 2.x is just a no-brainer for me to use. So yes, I would agree with the statement 'We've been truly able to get it right in the 2.0 version'. Congratulations to the Arrow team for achieving perfection!
I remember looking at Arrow when I first started with Kotlin and not understanding how to use it. I think I'll look into using Arrow 2.0 for rewriting one of my older Android apps in the future.
🎯 Key Takeaways for quick navigation: 00:02 ⌛️ The talk will cover the 10 year history of Arrow and the decisions made over time. 01:18 🛡️ The talk will discuss complexity of FP in Kotlin and embracing the language to build an ecosystem. 03:37 💼 The talk will cover evolving APIs in open source libraries. 04:20 📜 Arrow originally aimed to provide idiomatic FP for Kotlin. 05:15 🤔 Pre-1.0 Arrow used non-idiomatic concepts like higher kinded types from Scala. 06:39 🚀 Arrow 1.0 embraced coroutines by removing higher kinded types and adding MP support. 08:30 🏃 Arrow 1.x focused on idiomatic suspend and other FP concepts. 09:54 📚 Arrow 1.x reduced learning curve via smaller, uniform APIs. 12:03 🗺️ Arrow 2.0 further improves learning curve and removes obscure APIs. 17:41 🎯 Arrow 2.0 APIs inspired by Kotlin stdlib to feel natural. 18:52 💡 Context receivers greatly simplify FP code. 20:23 🧩 DSLs enable mixing FP concepts without wrappers. 22:33 📦 Arrow 2.0 is under 400KB, 10x smaller than before. 24:26 🛠️ Breaking changes are difficult but sometimes needed. 27:17 ↻ OpenRewrite can automate large scale refactoring. 30:05 📖 New Arrow site focuses on applied FP. Made with HARPA AI
Whenever I create a new Kotlin project, I see myself reaching for the Arrow dependency... A lot has improved since when I started using it and I believe Arrow 2.0 + Context Receivers will be the sweetest thing for a long time. Thanks @Simon, the Arrow team, Xebia (47 Degrees) and contributors for making this possible...👍🏾
I like how they went from functional programming to just use ErrorType annotations. What's the point of doing functional programming if the developer is unaware he is doing functional programming
The point is to get the benefits of FP. When I'm working on the task, I don't care if the code is functional, imperative, or object-oriented, but what I care about is that it's bug-free and easier to maintain. A lot of folks are turned by the mathematical nature of FP deviating from the domain terminology. The "stealth" approach totally makes sense in this case.
The evolution of Arrow has truly been spectacular. As a framework developer myself I can relate even more with a lot of the challenges Simon describes. Over the past years I have considered dabbling with arrow at multiple stages, and my experience has gone from being extremely overwhelmed in the pre 0.12 days to being completely wowed by how simple and idiomatic it has become post 1.x, and the 2.x is just a no-brainer for me to use. So yes, I would agree with the statement 'We've been truly able to get it right in the 2.0 version'. Congratulations to the Arrow team for achieving perfection!
I remember looking at Arrow when I first started with Kotlin and not understanding how to use it. I think I'll look into using Arrow 2.0 for rewriting one of my older Android apps in the future.
@23:00 deserved some claps.
Great surprises. And they discovered me OpenRewrite as a bonus.
My favourite tool for my favourite language
🎯 Key Takeaways for quick navigation:
00:02 ⌛️ The talk will cover the 10 year history of Arrow and the decisions made over time.
01:18 🛡️ The talk will discuss complexity of FP in Kotlin and embracing the language to build an ecosystem.
03:37 💼 The talk will cover evolving APIs in open source libraries.
04:20 📜 Arrow originally aimed to provide idiomatic FP for Kotlin.
05:15 🤔 Pre-1.0 Arrow used non-idiomatic concepts like higher kinded types from Scala.
06:39 🚀 Arrow 1.0 embraced coroutines by removing higher kinded types and adding MP support.
08:30 🏃 Arrow 1.x focused on idiomatic suspend and other FP concepts.
09:54 📚 Arrow 1.x reduced learning curve via smaller, uniform APIs.
12:03 🗺️ Arrow 2.0 further improves learning curve and removes obscure APIs.
17:41 🎯 Arrow 2.0 APIs inspired by Kotlin stdlib to feel natural.
18:52 💡 Context receivers greatly simplify FP code.
20:23 🧩 DSLs enable mixing FP concepts without wrappers.
22:33 📦 Arrow 2.0 is under 400KB, 10x smaller than before.
24:26 🛠️ Breaking changes are difficult but sometimes needed.
27:17 ↻ OpenRewrite can automate large scale refactoring.
30:05 📖 New Arrow site focuses on applied FP.
Made with HARPA AI
I didn't know Nietzsche also gave tech talks. 🔥
Whenever I create a new Kotlin project, I see myself reaching for the Arrow dependency...
A lot has improved since when I started using it and I believe Arrow 2.0 + Context Receivers will be the sweetest thing for a long time. Thanks @Simon, the Arrow team, Xebia (47 Degrees) and contributors for making this possible...👍🏾
As a library author, should you convince me to expose my library's users to Arrow 2 or should I wrap my library's public API to isolate it?
I like how they went from functional programming to just use ErrorType annotations. What's the point of doing functional programming if the developer is unaware he is doing functional programming
The point is to get the benefits of FP. When I'm working on the task, I don't care if the code is functional, imperative, or object-oriented, but what I care about is that it's bug-free and easier to maintain. A lot of folks are turned by the mathematical nature of FP deviating from the domain terminology. The "stealth" approach totally makes sense in this case.