Somebody was telling me that ArrowKt changes a lot...
# functional
d
Somebody was telling me that ArrowKt changes a lot... (maybe that was a conclusion he made having used it in previous, less stable versions?) does that mean there are often breaking changes? Is Arrow now stable in it's api? I know that there's always a will to improve as long as the language itself doesn't support all of the features a functional language would need...
r
Hi Dave, Arrow gained this reputation in the 0.x series as we removed most of the type classes and abstractions we used when the lib originated. Since the 1.x series it's stable and new features are frequently back-ported to older versions.
s
0.x series
To put some more perspective, Arrow 1.x was release almost 2021 and Arrow 2.x is being released later this year. Within 1.x.x there were no breaking changes, and the last version of 1.x.x will be source compatible with 2.x.x. 1.x.x -> 2.x.x will remove some obscure APIs, and further clean-up some old legacy things that are not being used.
d
Thanks for the answers! So the new 2.x.x API will be stable and it's all already in 1.x.x? Is some of it expected to be deprecated if, say, new features in the language would be added?
s
We're deprecating everything in 1.x.x before effectively removing it in 2.x.x, and almost everything is back-ported. The next minor version will be the last 1.x.x release (1.2.x), and all non-deprecated methods will be source-compatible in 2.0.0. It'll be released soon-ish with a "migration guide" to fix all deprecated methods. 2.x.x (and 1.2.x) is build with new language features (context receivers) in mind, so if 3.x.x is released in the future it'll be with very minimal changes.
very minimal changes
This can be done in a binary compatible way, so we might just stick to 2.x.x even when context receivers land into the language.
If you're interested in using 1.2.x already, you can use
1.1.6-alpha.26
and check the PRs for all remaining work that is still to be merged before the
1.2.x.
release ☺️
The alpha release are stable, and are also binary compatible with everything in 1.x.x
d
I'm starting to grasp the value of Arrow now, I might try it in a new service... you said the Alpha is stable, but is it production-ready? (I'd suppose not -- but you used it in your video...) Also, even if not, maybe it would be possible to have a release with a bunch of typealiases with the new names to avoid new projects having to migrate?
s
is stable, but is it production-ready?
Yes, it's production-ready.
Also, even if not, maybe it would be possible to have a release with a bunch of typealiases with the new names to avoid new projects having to migrate?
This is already the case, current
1.1.6-alpha.x
is what will be released as
1.2.x
in 2-3 weeks and all non-deprecated code will be source and binary-compatible with
2.x.x
.
1.2.x
is
1.1.x
+ everything from
2.x.x
back-ported.
@Deprecated
if it will be removed from
1.x.x
->
2.x.x
and all non-deprecated code will remain unchanged. We're still figuring out how to deprecate
Validated
nicely, and plan a migration plan. This can potentially be partially be automated as well. We want everything to be as automatic, and as painless as possible.
Hope that makes sense, and exciting that you'll give Arrow a shot. Be sure to ask any questions if you have any and there is also #arrow which is a bit more active if you're interested. It's a gem of information, and a great place to search.