Hey all :wave:, My talk "Unlocking the Power of A...

# arrow

[simon.vergauwen]

Hey all 👋,

My talk "Unlocking the Power of Arrow 2.0: A Comprehensive Guide" was accepted for KotlinConf 🥳 I was planning to talk a lot about everything non-error related 😄 There is already so much content on error handling.

I have a lot of ideas, but I am curious what do you all want to hear in this talk from KotlinConf? (live-streamed, and recorded for those not attending).

Please leave all your thoughts, and feedback ❤️ arrow intensifies

[Daniel TIefenauer]

Personally I would be most interested in the Resilience part and also Pre- and post-conditions.
Looking forward to meeting you at KotlinConf!

[dave08]

Also optics is a subject that seems less documented than it could be as to practical every day use (and when NOT to use it...), and how/when to adapt it to make custom lenses, etc... also with respect to the coming changes in 2.0

[simon.vergauwen]

I'm planning to talk about Optics, but probably won't be able to go so deep to custom optics due to time constraints.

[dave08]

Yeah, I guess another time... but it's already good if you'd "raise" awareness on this subject, and how 2.0 will improve on the current implementation. Also, maybe the future of Optics? Is it planned to make it more optimised when doing multiple changes on an object (current AFAIK it all the hierarchy gets copied for each change in copy { ... }?

[simon.vergauwen]

We've been hoping to implement that, but it's a bit wait-and-see what'll be possible with compiler plugins. The biggest issue at the moment is that IDEA wouldn't understand the code we generate, and it'd result in red lines 😞

[simon.vergauwen]

You're absolutely right though. Optics deserve more ❤️

[Davio]

Speaking as a developer who completely removed Arrow from their project since it was used only for error handling and did not do a very good job at that (maybe we'll look into that once we get something stable with context parameters) I'd like to know what specific use cases Arrow provides a good solution for and how a non-Arrow solution and an Arrow solution compare

[simon.vergauwen]

Hey @Davio,
Sad to hear that, sadly it does happen too much when introducing new paradigms into projects. Many libraries, in many languages had this issue. Feel free to DM me any feedback, or experience. I'd love to hear that, and see how we could improve Arrow, or the documentation to prevent that. Also, depending on the version you used at that time it might be better now. We aimed to solve a lot of pain-points over the years. I.e. Guice, RxJava, Guava, etc

Perhaps I should also include a section on what to use when, and highlight that in the documentation. What I've often see is overuse of such tools. Like using Either everywhere, where a simple ? might have been sufficient.

Making comparison between non-Arrow, and Arrow solutions is a great idea though! Going to keep that in mind. Our ultimate goal was to allow pick-and-play with the DSLs, so I was planning to show a lot of that as well.

[dave08]

Perhaps I should also include a section on what to use when, and highlight that in the documentation. What I've often see is overuse of such tools. Like using Either everywhere, where a simple ? might have been sufficient.

That's a very good idea...! I was too trigger happy in the beginning... I could see how that could lead to not really appreciating Arrow when it IS properly used...

[dave08]

Same for Optics...

[simon.vergauwen]

I was too trigger happy in the beginning...

This is a common problem in general when learning something new. It's natural to experiment where it fits, and where not but when doing so in a production project is always tricky.

Making mistakes is almost necessary when learning something new, so I typically do so in low profile projects, prototypes, hobby projects, or similar. Not learning, and experimenting with new things is also not beneficial IMO.

[simon.vergauwen]

I did the same thing.

[dave08]

One of the contexts I liked Optics in was Unit testing... it makes it pretty easy and clear to alter fixtures for testing different situations with the same complex setup...

[dave08]

I did have a few more situations in the actual production code... like in Android's MVI flow to alter the current state of the UI to send to the compose view in a StateFlow... where changes are to a very specific element in the whole state as a reaction to user events...

I wonder if there's any other places where people use them?

[dave08]

I'm saying, that presenting such cases in the speech might be very nice to tempt people to use it properly...

[dave08]

Showing how code in those situations look with/and without Arrow

[simon.vergauwen]

Optics is very nice in MVI, but I don't do any serious front-end anymore 😞

[simon.vergauwen]

I'd be happy to work together with people from the Arrow community to workout a Compose example, and talk about it as well in my talk.

We'd love to add it to the website, with a proper example

[Kev]

It would be great to see how Arrow can be used bridging the gap between application code and framework code (like, Arrow + SpringBoot / Arrow + ktor) from a more real world scenario point of view using sensible design patterns / idioms and what not.

[dave08]

@Kev There was a video already made by Simon for Ktor apps with a sample in Github.

[Kev]

Sweet

[dave08]

I think it's this one

https://www.youtube.com/watch?v=g79A6HmbW5M▾

[Kev]

I must of missed this. Thanks @dave08

[Davio]

Overall, I always like a pragmatic approach. Not "here's a new framework, let's use it with everything", but "here's a problem, this could be a solution". I think that may help convince more people. People have problems and can relate to problems. So you could always identify a problem, show a non-Arrow solution and then show how that problem is 'solved' by using Arrow 😄

[simon.vergauwen]

I think there is more to be said, but in this talk I am not going to talk about a specific framework. I send in 2 other talks on those topics, and those didn't get accepted.

But "sensible design patterns / idioms" can also fall within a non-framework mindset.

[simon.vergauwen]

@Davio that is my idea going into the talk, we also re-oriented the documentation and website as much as possible into that direction.

[simon.vergauwen]

Thanks all so far already for the feedback 🙏 Keep it coming 😁

[Davio]

I'll be going to Copenhagen so I might attend this one in person, even though we currently don't use Arrow, I'm sure there are things it can help me with, so just imagine you're doing this presentation only to convince me 😄

[simon.vergauwen]

Cool, looking forward to meeting you 👍 I don't like convincing, as it feels to me like pushing solutions on people but I do want to spread a positive message about what problems can be solved how with Arrow 😉

[Davio]

Yeah I'm the same way, maybe my choice of words was not the best, I meant that I'm always open to new ways to solve old problems. That's one of the main reasons I enjoy what I do, so if you can present these problems and show new and improved solutions, then I'll be able to convince myself 🙂