Some Kotlin Native targets are set to be deprecate...

# embedded-kotlin

[napperley]

Some Kotlin Native targets are set to be deprecated. One of the deprecated targets is linuxArm32Hfp. If you want to prevent the linuxArm32Hfp target from being deprecated then leave a comment in this Kotlin blog post: https://blog.jetbrains.com/kotlin/2023/02/update-regarding-kotlin-native-targets/

Do note that the list of supported targets is not set in stone (is subject to change), and there is a chance to prevent the linuxArm32Hfp target from being deprecated. If no objections are raised then the Kotlin team will do this unopposed.

[elizarov]

ARM v7 is, indeed, a popular architecture for embedded devices. Given the memory restrictions however, it is traditionally developed on using systems languages that are designed with a different mindset. While it certainly is possible to create embedded software with Kotlin which uses GC and targets a machine with limited resources, it isn’t something that we believe would have a large market and therefore it is not viable for us to try and target it, especially taking into account that the ARM v8 is and will be supported by Kotlin/Native. This is a market we see great potential in and we’re committed to supporting it

[andylamax]

Does this mean even if we comment on the blog post, we won't be able to stop the deprecation?? as in the team has already decided to depricate it and there is nothing we can do??

[elizarov]

Once it is deprecated it does not mean it cannot be supported in the future. We are currently working to expand the Kotlin Foundation and create a process where more parties interested in Kotlin future can contribute and support the growth of Kotlin ecosystem. Maybe somebody with a real stake in embedded could take the burden of maintenance in the future or maybe we’ll change our assessment for the market potential in that niche in the future. Who knows.

[elizarov]

We sincerely have no resources to properly support it ourselves right now. Just “throwing the code out there” without any proper quality assurance is not the level of support we’d like to get associated with Kotlin.

[andylamax]

Thanks @elizarov I think I fully understand the reasoning, the motive, and the direction the kotlin team has decided to take on this