A modern programming language that makes developers happier.

kotlinlang

<https://kotlinlang.slack.com/archives/C8UK6RTHU/p1761128492869479>

Is the new optics gradle plugin documented somewhere (new features/caveats...)?

Not yet. In short, it’s just a Gradle plugin that at the same time applies the KSP one and adds companion objects if needed (so you don’t have to do it manually)

…and the new Racing DSL? Any documentation?

the docs are not written yet since the API is still (slightly) in flux

<https://github.com/arrow-kt/arrow/pull/3684>

<@U05KM2Z3468> if you're curious about the Racing DSL, here are the WIP docs <https://github.com/arrow-kt/arrow-website/blob/110b696f7e74904719d1ea8f86295acaa7f21864/content/docs/learn/coroutines/racing.md>

So, if the fastest computation fails, you still expect the second one to see if it succeeds and return its value?

you actually decide per-computation. If you use `race`, that means you only "take it" if the cimputation succeeds, but you also have `raiseOrFail`, which is purely decided on the fastest

The default behavior on asynchronous libraries like Cats Effect or Zio in Scala is to return the first result, whether it's a failure or a success 

in this DSL you can mix and match
```racing {
  raceOrFail { /* allow for exception or raise as result */ }
  race { /* only if successful (no exception or raise) */ }
  race(condition) { /* as bove + condition must be true */ }
}```
so one computation may be OK to fail, but others not

They also offer the possibility to return the first successful result

What if somebody put some code inside the `racing` block that doesn't belong to any `race` task?

that's fine, you can consider it the "configuration" phase of the racing. But the _result_ of the racing block is always coming from the race tasks

I like the syntax. It's very close to the Accumulation DSL :clap: