So why is Kotlin/native moving away from ARC? It seems like Swift gets good enough performance, and ...

# kotlin-native

[spierce7]

So why is Kotlin/native moving away from ARC? It seems like Swift gets good enough performance, and having a cycle collector on top of it surely isn’t a dramatic hinderance. In my companies performance benchmarks for real-world mobile tasks, we were seeing Kotlin and Swift perform within 1X of each-other.

[basher]

it never used ARC

[basher]

https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/?utm_source=twitter&utm_medium=blog&utm_campaign=kotlin_native_memory

I assume you're talking about:

Still, the reference-counting memory manager was easy to write to get the Kotlin/Native project started, and a cyclic garbage collector based on a trial-deletion algorithm was added to provide the kind of development experience that Kotlin programmers expect.

[basher]

That's really ARC-ish, but it's GC. To some degree, GC is ARC-ish. But ARC, is compile-time generated retain/release statements (+ autorelease)

[basher]

What K/N is/was doing was runtime reference counting and then using a GC to cleanup, which afaict just generally describes GC

[spierce7]

ic - I guess I assumed reference counting and automatic reference counting were the same

[basher]

Yeah the terminology is confusing because they could be referring to:
• general concept of reference counting, which is typically manual
• somehow automatically tracking references and using a count to do that
• Apple's ARC
etc.
🤷

[gildor]

Strictly speaking ARC also a type of garbage collector 😅

[basher]

I guess if you go by dictionary definition sure, but in the Apple world, where there once was (briefly) garbage collection, ARC is not considered garbage collection