With the new atomic types in the stdlib, is it sti...

# stdlib

[Javier]

With the new atomic types in the stdlib, is it still necessary to apply the atomicfu plugin? I guess the one from kotlin and not the one from Kotlinx is still necessary.

[Youssef Shoaib [MOD]]

There's something about it improving performance I think by inlining some of the fields. The plan is to eventually integrate that into the compiler or something

[Filipp Zhinkin]

Currently, common atomic types provided by the stdlib in 2.1.20 and kotlinx-atomicfu plugin are two different beasts. There‘s a plan to integrate AFU with common atomic types in future, but for now, if your goal is achieving the peak performance, AFU with the plugin is still a better choice.
If an analogy with Java atomic types and APIs makes sense for you, common atomics are boxed atomic types from java.util.concurrent.atomic and AFU with the plugin are atomic field updaters / var handles applied to primitive volatile fields.