For the native to succeed, memory management will be a tough challenge. Not just on implementation grounds but on adoption as well.

From the discussion forum I'm aware that Kotlin is going with a gc. Was arc considered? (Besides potential language keyword additions) what were the considerations?

Has anyone listened to Chris lattner's chat? https://secure-hwcdn.libsyn.com/p/4/5/d/45d0420e392363cf/atp205.mp3?c_id=13910379&expiration=1484923047&hwt=d6d13f47fc71b2a5f77e009d1c0c33e5

http://atp.fm/episodes/205 here's the proper one

Actually there's been no proper open discussions on the native part yet. I'm not sure about these things

@nimtiazm stay tuned, hopefully you will be pleased wrt memory management

it's not a classical GC, while hopefully better than classical RC

Any inspiration from golang?

is it impossible to satisfy both, people who want a gc and people who don't, with a customizable solution?

Imho ARC is the only way to go in a modern language, and putting memory-management keywords in the language adds confusion, unnecessary complexity, and incompatibility.

Those viewpoints of mine might be contradictory, but it's where I stand.

@benleggiero I'm confused by this statement. Is it pro-ARC or anti-ARC? To clarify, ARC is "Automatic Reference Counting". Its most well-known implementation is Swift and it does require adding a lot of memory management keywords into the language (

weak

,

unowned

, etc). On the other hand GC is "Garbage Collection" (like in Java or Go) and it does not require any keywords in the language.

Like I said, my stance might contradict itself, but it's my stance. I'm mostly thinking about efficiency with ARC, and Java/JS compatibility with keywords. For instance,

weak

and

unowned

are nonsense in Java/JS. On the other hand, being able to compete with C++ and Swift on speed and smoothness is a huge win. I'm sure there's some middle ground to be struck. P.S. I don't think it needs to be said that using manual reference counting is out of the question XD

to give a bit of a spoiler, our design is around compile time escape analysis, automatic reference counting as primary collection algorithm and automated cycle collection as needed

sounds very cool, can't wait to try, and smooth kotlin--kotlin-native interrop i assume😉

That sounds hella awesome

@olonho well that sounds a lot more exciting. I honestly believe that the entire Kotlin compiler team is doing a really great job. Native runtime will open up a lot of avenues for Kotlin that are left outside the JVM. I hope you guys will release something soon. Sooner than many of us can take 😄

@olonho needless to say, if you guys ever decide for an alpha release or dev preview, you can find a lot of volunteer here to try things out and submit the reports/long-running-tests etc etc

Though I’m not @olonho, I would say the most helpful thing community can do right now is help collecting use cases in a rather specific form. E.g. @stepango mentions "kotlin--kotlin-native interrop” without telling explicitly what does it mean, what use case, etc. A better variant would be:

I’m looking into using kotlin-native for my high-performance low level CUDA calculations engine, but I’d like to make it interoperable with some Java libraries

@orangy i mean replacement for jni

@orangy sure that’ll be cool. i have been thinking about those cases for a couple of days but i’m not sure what can be done by JB team for that

for example i have a lot of small memory footprint processes that talk to Rabbitmq through AMQP protocol. Currently I have those written in Java being migrated to Kotlin. But that’ll be on JVM. They’ll be better off running natively. but usually Rabbitmq’s core team write the driver for in-demand langauges

also, a native (non-jdbc) mysql/postgres database connector that’ll be way more useful for mine and a lot of applications i’m sure

another almost-always used library would be net/http and json parsing and of course spek-like testing lib with a native test runner.

these are things that I do the most and would want to migrate to the native kotlin.

besides other stuff like Spring/web which i’d rather keep on JVM for now because various practical reasons

what’s the benefit of native compared to JVM for you?

from where I see/require it, #1) very low memory footprint, #2) fast boot-time and #3) sometimes critical performance

not to mention the script-like work for which I have to end up using python (and not rather bash)

specific examples of the most recent script-like work, #1) talk to a 3rd party server hitting it almost 500 times (because of their awkward API) and read/delete the profiles in database