My teammates said that I can’t use `callbackFlow` ...
# coroutines
n
My teammates said that I can’t use
callbackFlow
and
flatMapMerge
because they are marked as
@FlowPreview
and
@ExperimentalCoroutinesApi
. Does anyone have any idea when we can expect these to become stable?
t
Only issue that I know of in using it is that it might be renamed or changed in a new release. All of the
ExperimentalCoroutinesApi
and
FlowPreview
that I've used have been perfectly stable. The worst thing that I know that can happen is your build breaks when you upgrade the lib.
j
If you're building an application there's no reason not to use them. Educate your team.
👍 1
☝️ 2
r
@jw we have the same ruling in our codebase. I guess the basic fear is since there marked experimental, or preview a breaking change could happen , which would call for a massive regression in a large codebase.
I do wish that they wouldn't use the "NewApi" annotation rather than experimental. Because the term "experimental" carries a lot stigmatize when trying to introduce it to a team😅. But the reality is anytime you use any library things could always change
the next iteration
j
Yes. And you control when you upgrade anyway, it's not like it changes on a whim. We enable all experiential API in all libraries in our codebase. Same for obsolete even
r
Yea def agree with you when it comes to experimental and obsolete. Because even if there is a replacement , the old implementation will be there for a while . However FlowPreview might be alittle more scary. because the kdoc says "Flow preview has no backward compatibility guarantees, including both binary and source compatibility 👻" .
But regardless its a hard sell for big companies. because , to the masses "experimental" == "Hey do you like to gamble" 😂
l
I opted-in to
@ExperimentalCoroutinesApi
in the whole codebase (not library codebase), but for
@FlowPreview
, I'd never do it and just propagate it until the right place to show the
@OptIn
annotation. I still recall
flowViaChannel
being badly broken for a relase as they were moving fast towards `callbackFlow`/`channelFlow`.
n
Because of the fear that the API’s could change in the future, and they question the stability, I am not allowed to use anything marked as
@FlowPreview
and
@ExperimentalCoroutinesApi
. I put up a good argument, but it still got shut down.
l
I'd leave the company if I was forbidden to use
@ExperimentalCoroutinesApi
in application code.
😂 4
☝️ 1
👍 3
😅 2
t
the apis change w/ that beautiful deprecated tag(thanks for that amazing feature BTW) that lets intellij automatically alt-enter fix it. I bet you could do that with one project level inspection/auto fix too. 🙂
l
Yes, you just have to not update from version 1.0 to version 11.3 straight away without incrementally upgrading. Same for 0.x to 1.0+
r
hahah @louiscad not if that company is paying you the right price 😂
To me I don't see the big deal. Any library can change at any time. The worst migrations I have been thru were Android X and Robolectric, and neaither one had a experimental annotation 😂
m
Sometimes I find that having @jw's opinion indirectly favor a decision can be enough to convince team members. So you can hit 'em with https://kotlinlang.slack.com/archives/C1CFAFJSK/p1600990580014800?thread_ts=1600980877.014400&cid=C1CFAFJSK 😄
n
@Marcelo Hernandez I did. I threw every argument out there that I could. They said JW doesn’t have stake in the company and that they don’t bow to everything celebrities say.
It’s frustrating because this company currently harnesses the old android annotations library yet they are rejecting something because it could change in the future. It’s 3 v 1 right now and I do agree that something that is marked as experimental sounded scary at first, but once you read what it actually means you understand it’s not ask risky as people think. when my coworker said “do you accept the risk”. I said yes, then another person heard “risk” freaked out and then noped the idea.
m
Sorry to hear that. We literally just added the compiler args 2 days ago to opt in to the experimental APIs because we were using them everywhere. Less noise now 😌
n
I think if I would have added those arguments a month ago they wouldn’t have noticed!
I’m jealous!
l
@rkeazor https://kotlinlang.slack.com/archives/C1CFAFJSK/p1601078031035900?thread_ts=1600980877.014400&cid=C1CFAFJSK That's not how it works. I'll happily leave a team that focuses on the words rather than their contextual meaning and is afraid to take risks, even if I take a pay cut. More money is good for you, but time and how I spend it is more important and is worth more.
r
@louiscad so your saying that if a company was like they will pay you 500k a month and all you had to do was not use experimental features you would leave lol. Bruh for the right price I might write android code using a Turbo Assembler 🤣🤣. Because let's be real, companies will always favor business over tech. So there will always some kind of compromise somewhere that you wont like...And alot of times those compromises trickle down to the code as and how it is...For instance I have worked in companies that focus on fast delivery to there consumers, and when you look at the code it shows , because it looks like it was written in a rush lol.Like things like that are super common in our industry. That's just the reality of things
👍 1
l
@rkeazor Using these experimental APIs can save you time and help give feedback to shape these APIs better if needed. Also, find that company giving 500K € per month, I'm curious what's their business, how they can afford that. Let's find if that's the reality of things as you say.
n
@louiscad and @jw, the team was impossible to be educated. I put my two weeks in. yayy. my next job i’m putting it as a requirement that they understand what
experimental
means.
🎯 1
l
Not surprised it was only the tip of the iceberg. Regarding the real meaning of "experimental"… it depends. Generally speaking, words are always a mere approximation of what one wants to communicate.
👍 1