<It's confirmed> that multi-platform context receivers won't be available before Kotlin 2.0.

# arrow

[CLOVIS]

It's confirmed that multi-platform context receivers won't be available before Kotlin 2.0.

[Javier]

Yeah, it was confirmed some time ago

[Javier]

Finish K2 and then context receivers

[CLOVIS]

There was a discussion last week (can't remember if it was in this channel or another one) where people thought it would be for 1.9, so I just wanted to share the confirmation

[Javier]

Oh, I just didn't read it 😕

[Javier]

I think Context Receivers will not be even on 2.0, but the before after that

[CLOVIS]

Yeah, I think it's likely it'll be 2.1

[Javier]

I bet that too, 2.1 beta and 2.2 stable

[CLOVIS]

it seems the be the big feature everyone is waiting for, they probably don't want to mix it up with 2.0 which is supposed to be a massive refactor

[simon.vergauwen]

Yes, someone on Twitter was claiming last week it was confirmed for 1,9, but I also thought it was confirmed some time ago it wouldn't land before 2.0 and not together with 2.0

[simon.vergauwen]

Let's hope it's soon, if it's 2.2 then it's probably 12+ months away 😭

[CLOVIS]

Ah, it was on Twitter? I remember I saw your name so I thought it was here.

[Javier]

Simon stops fake news

[Javier]

🙃

[phldavies]

I can’t say I’d be surprised if they waited for 2.1 for beta and 2.2 for stable, although I doubt it being beta will stop many of us…

[CLOVIS]

Ahah it definitely won't

[simon.vergauwen]

Well Kotlin being quite conservative with these labels beta translates to "please use it in production, and let us know if you encounter issues" 😛

[phldavies]

I thought that’s what “experimental” meant 😄

[simon.vergauwen]

I mean how long has kotlin.time been Experimental and FlowPreview? 😄

[CLOVIS]

…I've read the KEEP so many times I have internalized a lot of the new concepts, I'm constantly writing code that I feel should work but doesn't because they're not here yet 😅

[Javier]

I still have the FlowPreview optIn on Gradle

[CLOVIS]

Remember for how long @OptIn required an opt-in itself? 🙃

[phldavies]

My work’s going to be cut out on persuading any next role I land to move to Arrow, let alone embrace context receivers. Seems most companies are still focused on kotlin+spring-boot. So I have time yet for them to get the ball rolling again with context receivers.

[CLOVIS]

Ahah. We're Kotlin+Http4k here, I'm trying to convince them coroutines are worth it. Then Arrow. Then Compose Web instead of Angular.

[phldavies]

It would be great if they could at least resolve a few of the front-end issues with context-receivers before dropping progress, but they’re not the biggest team so fully understand the need to pioritise.

[CLOVIS]

CRs?

[phldavies]

context-receives (updated)

[CLOVIS]

All my projects are JVM+JS 😭

[phldavies]

I had too much fun recently with introducing Kotlin to a scala team based on cats-effect - it’s surprising how similar you can get with Arrow’s resources and ktor/coroutines.

[simon.vergauwen]

I hope to contribute into that area after 2.0. Building more examples, content, integration libs, working in some spaces outside of Spring to OSS some of internal solutions.

[simon.vergauwen]

@phldavies super curious to hear more about that!

[Javier]

@simon.vergauwen is there any sample about spring + raise + context receivers?

[Javier]

I have a project in which I didn't see a lot of value in using ktor as it is gRPC and there is a Gradle plugin for Spring + gRPC

[simon.vergauwen]

We're working one, Spring & Arrow. https://github.com/47deg/gh-alerts-subscriptions-kotlin-spring (Without CR)

[Javier]

AFAIK, it wouldn't be possible to do anything with context receivers on Spring until they support them?

[Javier]

Well, I think their current injection framework should support them as CR are just syntax sugar and if they do DI on Java then they are just passed as constructor parameters

[phldavies]

Interesting - I didn’t notice you’d two versions of the app. I’ll have to take a look later 🙂

[phldavies]

If I recall correctly, spring does have some level of kotlin-aware introspection in order to support default parameters and the like - so it may well be that direct support for context receivers is required. However you can likely provide lightweight bridging methods as required to circumvent any restrictions.

[simon.vergauwen]

The app is still in WIP, and the same colleague is also working on a more modern Spring app using the Spring "functional" DSLs.

Indeed I think some kind-of bridging could be provided, perhaps just something like:

@Controller class MyController(
  depA: DepA,
  depB: DepB
): DepA by depA, depB by DepB {
  // can call context(DepA, DepB)
}

[phldavies]

I'd certainly be interested in seeing a Spring DSL focused example service as stepping back to the annotation-driven world is the one thing I'm not looking forward to.

[simon.vergauwen]

IMO you're still better off with Ktor if you can, but if offers a good middle ground if you're for some reason stuck to Spring.

The reasons for being stuck to Spring are typically either, some custom Spring coupled internal frameworks or large teams being "knowledge stuck" to Spring. In both cases moving to annotation-less Spring has the same hurdles as adopting Ktor.

[phldavies]

All depends on the company/team I end up joining. 🤞 I'm not stuck in a spring-only monolith... 😂

[Javier]

@simon.vergauwen problem with ktor I don't see any benefit with gRPC even I created the grpc engine manually. Profiles and so on...

[simon.vergauwen]

Are you using grpc with Spring, or directly the grpc servers from Google? I would just use the latter.

[Javier]

https://github.com/yidongnan/grpc-spring-boot-starter

[thanh]

I used context receiver in my previous company and I love it,

[thanh]

combine with Arrow family, that made even working with Spring is a pleasure!