A modern programming language that makes developers happier.

kotlinlang

I’m curious, why couldn’t Kotlin/native get the performance numbers it was expecting with ARC? Swift uses ARC and gets solid performance with LLVM.

What unmet performance expectation are you referring to <@U1ZQ36CJD>? Citation?

If you're talking about the need for JB to develop the new Kotlin/Native memory model; this was not motivated by performance.  I thought going to GC it is expected to _reduce_ performance, but gain consistent behaviour with Kotlin/JVM, which has been deemed more important.

It was from the <https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/|original announcement >to move over more than a year ago I believe.

&gt;  As the Kotlin/Native project matured and became more widely adopted, the limitations of such a reference counting-based automated memory management scheme started to become more apparent. For one thing, it’s hard to get high throughput for memory allocation-intensive applications. But while performance is important, it is not the sole factor in Kotlin’s design.
&gt; The limitations become worse, though, when you throw multithreading and concurrency into the mix. In all the ecosystems where fully automated reference-counting memory management is successfully used (most notably in Python), concurrency is severely restricted via something like the “Global interpreter lock” mechanism. This approach is not an option for Kotlin. It is imperative for mobile applications to be able to offload CPU-intensive operations into background threads that run in parallel with the main thread.

That's interesting - I honestly thought reference counting would be a very performant approach, especially having implemented it manually in early iOS programming for a number of years.

Then again, the kind of reference counting iOS uses demands to have a notional parent/child in circular references; which helps to keep those cases simpler.  Kotlin doesn't have this so maybe it makes the flavour of reference counting used, more complex?

I recall somewhere Roman Elizarov saying that the first iteration of the K/N GC would have worse performance as it would be a simple implementation demanding 'stop the world' across all threads; but that they had ideas to make it more sophisticated later.  I wonder how that has panned a year or more later with this preview release...