Hi everyone! We’re very concerned about how easy i...

# multiplatform

[etolstoy]

Hi everyone! We’re very concerned about how easy it is for you to use Kotlin. One of the tricky parts is the memory model in Kotlin/Native. We’ve prepared a research to understand how well people understand various aspects of memory management. Walk through 10 code snippets and tell us, if you think that the output is correct and if you understand why it behaves so. The research is designed both for experienced developers and newcomers.
Feel free to use our documentation, and thanks a lot for your participation! ❤️

https://surveys.jetbrains.com/s3/kotlin-native-memory-model-research

[Kris Wong]

in my experience it's confusing, and certain things are significantly harder to do than I would expect

[Kris Wong]

i don't have a problem with the underlying concept, but the design of the solution is awkward at times

[ian.shaun.thomas]

Are these questions translated from another language? I am genuinely unsure what is being asked here. Do I think the exception is correct or do I think you should be able to write code like that in native? Also, that increment function doesn't return, should it just for clarity sake?

[r4zzz4k]

@ian.shaun.thomas you are provided with the code and possible result of running this code. As I understand it, questions are: 1. Do you expect the same result of running the code as provided, 2. How sure are you about this.

[ian.shaun.thomas]

possibly but the few devs I sent this too they all have the same questions I do, it's unclear if we are answering the questions in the same manner as we aren't clear on what the questions are asking. Personally, I would be really suspicious of drawing any conclusions at all from this survey.

[etolstoy]

Thanks for your feedback, we’ll rephrase some of the questions.

[jimn]

i don't recognize the memory primitives. my background is some POC work in android, more than POC experiemce on mpp, and significant JVM experience. Some of these features don't even code complete in my jvm scratch kotlin.
IMHO, portability is improved if the incompatible platforms at least hold a shim {::identity} (where applicable) object tree for the unsupported features so that they get the default available models, concurrency, etc. when emitters are unsupported.
also -- I would like a lazy(soft-ref) option like in Groovy @lazy, if you want to have input on memory models.

[napperley]

Really annoying with the Kotlin Native memory model that callbacks passed through to C functions need to be converted manually, have to be top level, and can't be defined as a member of an element (eg Class).

[napperley]

With the "What platforms do you target?" question, why is Linux not included as an option? Linux is the top Kotlin Native platform target (at 78% - https://www.jetbrains.com/lp/devecosystem-2019/kotlin/ ), and Kotlin Native isn't all about mobile development.

[Dominaezzz]

Can't be helped. It's a C "problem".

[napperley]

The survey isn't well designed. For starters not everyone uses Workers for concurrency in Kotlin Native, some use Coroutines instead. Second some of the questions assume iOS development experience, which a lot of people don't have (often due to doing software development in different areas - eg Linux).

[etolstoy]

@napperley Sorry, when designing the survey we had in mind mostly mobile developers. Will include this option.