If you want to see Kotlin as an option for Embedde...

# announcements

[napperley]

If you want to see Kotlin as an option for Embedded development (and as a high priority item on the Kotlin Roadmap - https://kotlinlang.org/roadmap.html ) then please vote for this issue: https://youtrack.jetbrains.com/issue/KT-44498

[Nir]

Bold. You'd be surprised how many C++ devs have trouble convincing embedded peeps just to use C++ instead of C

[napperley]

Python is being touted as a significant marketing point for the Raspberry Pi Pico ( https://www.raspberrypi.org/products/raspberry-pi-pico/ ). It wouldn't be too difficult to convince the Raspberry Pi Foundation to officially support Kotlin for the Pico, which would be another significant marketing point, however the Kotlin team ( @Artyom Degtyarev [JB] ) would need to get onboard with the idea/strategy, and promote the use of Kotlin Native far beyond iOS/Mobile development. There is plenty of room for a third officially supported programming language for the Raspberry Pi Pico; I advocate for Kotlin to be the next officially supported language. Stranger things have happened in the Embedded development space.

[napperley]

Presumably if the Kotlin team were to add the Raspberry Pi Pico as a new Kotlin Native target it would be reasonably straightforward to do (little effort required), and take no more than three months to complete (also includes basic testing with a real Raspberry Pi Pico), which is well within the Kotlin Roadmap time frame (a six month session). The Kotlin team might be able to squeeze in a sample or two as an extra bonus 😄 .

[Nir]

Yeah, that's a fair point, though it's worth noting this is mostly hobby programming

[Nir]

it's very visible online, on reddit, talked about, etc, but embedded is kind of an iceberg in that regard, and 95% of embedded happening at actual companies at least is still happening in C

[Nir]

(okay, maybe less than 95%, but C + C++ is at least that)

[Nir]

Obviously there's no downside to having Kotlin as an officially supported language, it would definitely make me more likely to get one 🙂 But I guess it's a question how much resources the kotlin team wants to put into that though, given the nature of the platform.

[napperley]

True however there will be some limited professional Embedded development that would in theory be doable with Kotlin. The fact that C dominates Embedded development isn't going to be an issue with getting Kotlin to work Bare Metal on some uC's. Kotlin is more complimentary to C, rather than being an adversary.

[napperley]

What greatly concerns me is that the Kotlin team don't see the golden once in a lifetime opportunity that would give Kotlin a foot in the door for Embedded development, that the Raspberry Pi Pico provides. Is the Kotlin team willing to take this very valuable opportunity seriously?

[Animesh Sahu]

Kotlin/Native seems to be immature at the moment. They're currently working on the memory model for K/N as of the multiplatform survey happened recently got it at maximum requests. its not so easy to manage concurrency, and recursive freezing had a large impact on performance as I understood in previous version...

[Animesh Sahu]

They'd probably gonna look at it after the beta/ or it gets stable.

[napperley]

The Kotlin team are better off getting started on adding the new Kotlin Native target sooner rather than later. Do it too late (eg after the K/N Beta) and the opportunity is lost forever. Kotlin Native's current memory model isn't going to prevent the adding the new target, and getting it working (at least to Blinky level which is the basic test for ensuring a uC works). When your are just toggling some LEDs concurrency isn't a big issue. There are a lot of things that can be done in Embedded development where concurrency isn't a big issue (aka not a major concern). Don't mistake Mobile development issues for Embedded development issues.

[Nir]

I think it's good to get native working better but my initial reaction would be that embedded is not the main driver for native

[Nir]

but, I could be quite wrong

[napperley]

Although Embedded development isn't the main driver Kotlin Native does have an image problem. Many people think Kotlin Native can only be used for Mobile development, and the Kotlin Native priorities aren't helping matters. Almost all of the platform specific priorities are tied to Apple platforms (mainly the iOS ones) which shows prioritisation is being done in the wrong places.

Is it right that, "Support producing binaries that run on Apple Silicon without Rosetta 2" (aka Mac ARM a new platform) is made a high priority for Kotlin Native when Embedded Linux (eg Linux on ARM) is a significantly larger, and more mature platform (has been around for over 20 years)? The answer should be no to this question, yet the Kotlin team are busy chasing trends without looking at what already exists, and is mature that can provide opportunities for Kotlin Native to grow in a short space of time.

[napperley]

Currently I am in contact with the largest contributor (kilograham, aka Graham Sanderson - https://github.com/kilograham ) to the official Raspberry Pi Pico C SDK ( https://github.com/raspberrypi/pico-sdk ). Graham is willing to provide some assistance with adding the Raspberry Pi Pico ( https://www.raspberrypi.org/products/raspberry-pi-pico/ ) as a new Kotlin Native target. It would be much better (less awkward) if the Kotlin team were to provide some assistance as well.

[Nir]

I dunno, I don't know if the answer should be no or not, it really depends what the Kotlin's teams goals are. If their goals are adoption by companies (i.e., for their software to be used more in professional settings), and most of the commercial, embedded linux market is just not accessible e.g. to any non-GC language, then maybe it does make sense

[napperley]

Just to let everyone know that a Engineer from the Raspberry Pi Foundation is now involved with the effort to add the Raspberry Pi Pico as a new Kotlin Native target.

[msink]

I guess main showstopper here would be same as in Zephyr two years ago - Pi SDK is based on gcc, while Kotlin - on llvm, and there are some subtle differences in their ABI.

[napperley]

According to Graham Sanderson (the biggest contributor to the official Raspberry Pi Pico SDK - https://github.com/raspberrypi/pico-sdk/graphs/contributors ) the use of LLVM shouldn't cause any major compatibility issues with the SDK.

[Nir]

i would have been shocked if LLVM could not target raspberry pi

[Nir]

And I'm not sure I know what it means for the SDK to be based on a compiler