It's finally here!! :partying_face: <https://githu...
# arrow
s
arrow intensifies 24
🎉 31
🦜 1
c
Nice! Time to upgrade everything 🙂
s
Doesn't seem like the "arrow-fx-resilience" package has been made available in maven yet?
a
at the end we named it arrow-resilience directly, you can find it here https://central.sonatype.com/artifact/io.arrow-kt/arrow-resilience/1.2.0
s
Ah! Thanks
s
Just a feedback @simon.vergauwen Before my team was small. And I being a big fan of arrow, I have been migrating, transforming, and implementing patterns introduced by Arrow since 0.0.6. So they haven’t felt the weight of it so much. But since 0.13.0, team grew quite a bit. With ~500 deprecation warnings per git repo from 1.1.3 to 1.2.0 (We were actually on 1.1.5, so we already had a little accumulation, and before 1.1.3, we had zero arrow warnings in our projects ), team has become shaky about using arrow. But hopefully, with 1.2.0, things should calm down a bit, since, library is quite aligned with Kotlin lan principles. • It is worth while spending time on how such deprecations in the future, especially the one that are popular (previous example filterOrElse, filterOrOther, these were quite handy because of functions chaining pattern). • For whatever reason deprecations come, and have the potential to spin out of control, they should come with a migration script, so we spend a lot less time on them, or they are delayed until migration scripts are ready (ofcourse, exception is when migration is not trivial). I know the second one can been seen a bit unreasonable, but we have missed such script a lot during all these years.
But again, no love lost in the team so far 🙂
That sounded a bit negative, but I actually really appreciate all the work done by you and the team. (Text communications take away the expressions and emotions)
s
Hey @Satyam Agarwal, Thanks for the feedback ☺️ I am aware, and feel stress/bad about it 😅 I understand and feel your pain as well. It's been a very difficult and long road for me personally. Most of the things that were deprecated were added in the library before I even joined those project, and those who added those methods had since then long left... I've tried very hard to keep all breaking things to a minimal, by providing
ReplaceWith
and using OpenRewrite but OpenRewrite doesn't seem quite there yet to provide complete automatic refactoring. I've asked around, and looked for all kinds of different solutions but nothing is available without leaving the project in a broken state that still required manual fixing. I don't find it unreasonable, but there is nothing out there to build upon and regex based scripts just aren't powerful enough. That being said, I don't expect anything like this to happen again in Arrow. You can actually say that the journey from 0.10.x to 2.x.x was a single journey but broken up into multiple steps and 2.x.x is where we actually wanted to land. In hindsight, might've almost been better to write a new library from scratch but that might've also resulted in more defragmentation so who can say what is the best in the end 😅
c
I've seen many libraries and APIs become extremely confusing to use because of added features without ever removing old stuff (Java dates, CSS, Gradle APIs...). The fact that arrow was able to do a large cleanup, with great communication from the maintainers, is for me a great success, and gives me a lot of trust for Arrow's future
s
It's a double edged sword, and there is probably a very thin line in between. I did my best to approach that line, and tried to ask for feedback as much as I could but of course there is also always a lot of people you cannot reach and cannot collect feedback from. Anyway, from my side there is a 100% intention to not repeat this ever again in the future.
(Text communications take away the expressions and emotions)
No worries @Satyam Agarwal. I know it's meant well, and I always appreciated the feedback ☺️
s
I completely concur with the you both. Especially when we you have seen the library grow and shrink over the years, and all the thoughts put into it. Its just that, in practice, and especially with the developers churn within in the teams, it becomes a bit difficult to make them see the rationale. Not everyone understands, or simply has the patience or the will. But amazing work Simon. Like Ivan mentioned,
The fact that arrow was able to do a large cleanup, with great communication from the maintainers, is for me a great success, and gives me a lot of trust for Arrow’s future.
is the reason for my faith too.