Kotlin’s Porting Problems

Porting isn’t one of Kotlin’s strong suits. Throughout Kotlin’s lifetime a number of different porting problems have been encountered, from a fragile porting system to lacklustre support for supported platforms. Some programming languages like Go and C have a good porting track record, where many platforms are not only supported but receive proper support/maintenance.

Porting System

If there is one thing to say about Kotlin’s porting system, it is fragile and is built on flimsy foundations; the system is a Swamp Castle. Official documentation is non existent, with sparse reference documentation in the Kotlin code base providing vague hints on the porting process. This is akin to looking for Easter eggs in a video game. Source code for the porting system changes constantly in the Kotlin code base making it near impossible to port Kotlin to another platform; hence the Swamp Castle reference. When a change is made to the code base it is likely that any porting efforts either have to be redone, or significant changes need to be made.

Very little in the way of examples are available on how to port Kotlin to another platform. Some attempts have been made by the Kotlin community to port Kotlin which have all resulted in failure. With the uC (Micro Controller) platforms the Kotlin team would prefer the community to do the porting, rather then get involved themselves. Considering the way things are going with the porting system it will be up to the Kotlin team to do the porting, which isn’t an ideal situation when aiming to get Kotlin ported in a reasonable time frame without too much difficulty.

Currently there is an issue in the Kotlin Issue Tracker on more flexible cross compilation in Kotlin Native. It remains to be seen if the Kotlin team will follow through to improve the porting situation based on the feedback that has been provided. Submitting use cases will provide additional information for improving the porting system, however that won’t be enough to sort out the porting system’s issues.

Support

At times the support provided by the Kotlin team for various supported platforms is all over the place. To make matters worse some supported platforms have ended up in such a bad support situation, that they are considered dead by many in the Kotlin community yet the Kotlin team considers them alive (”its just waiting for some maintenance to bring it back to life again”) and kicking even though they are not; the ”parrot’s not dead” situation. A classic example of this is the WASM platform via the Kotlin Native wasm32 target, which for a while was around but not receiving much maintenance (if any) from the Kotlin team, before being declared deprecated many months later.

Some targets like the Linux ARM targets aren’t receiving the proper support that they need despite the fact that the platform is very mature, and has a large ecosystem behind it. Removing the Linux MIPS targets would free up resources to provide the proper support (for some targets) since they are ”dead parrot” targets. It is very likely that no business relies on the Linux MIPS targets, and very little of the Kotlin ecosystem supports these targets, therefore the targets can be safely deprecated.

One does have to wonder how the Kotlin team are prioritising supported platforms. Is there any reasoning applied by the Kotlin team to determine which platforms to support? If one looks at the platform prioritisation with Go it did use a tier system for a while. First tier platforms are officially supported, second tier platforms have limited official support, third tier platforms aren’t officially supported however Go can be used on these platforms. Now Go has gone with a simplified first class ports list that consists of platform/CPU architecture pairs, which are officially supported by the Go team. It should be noted that Go is available on some uC platforms, however these platforms aren’t first class ports although some members of the Go team (from Google) are contributing to the porting efforts (including support).

Kotlin doesn’t have anything similar to first class ports. With the Linux platform Go has gone a step further with only supporting the Glib C library. All other C standard libraries (eg Musl Lib C) aren’t officially supported. Kotlin should have something similar to Go’s first class ports. One would add that a decision needs to made with the Linux/Embedded Linux platform support on whether or not the C standard library support will remain Glib C only, or if some C standard libraries will be supported as well.

Ecosystem

Porting isn’t limited to the porting system and the corresponding support it entails. One has to take into account the ecosystem, “so much of programming is not the language itself, its the infrastructure that surrounds it” (a quote from John Carmack). If it is difficult to port a library to another platform then maintenance suffers, and many software projects depending on the porting will stall. One prime example of this is the KotlinX Coroutines library not being ported to the Kotlin Native Linux ARM targets. There is an issue covering this which has been around for over three years with no resolution in sight! A significant number of Kotlin projects (Ktor, Ko Test, KotlinX IO etc) cannot support the Linux ARM targets due to this issue.

The situation with this issue is so bad that there is a very tense standoff between the Kotlin team and the community. On the Kotlin team side they are not moving forward due to issues with the internal JetBrains build system not working on Linux ARM, which the team have **no intention** of fixing. With the Kotlin community side unofficial builds have been created which prove that building the library for the Linux ARM targets works fine. As such the community is getting increasingly frustrated with the Kotlin team dragging their heels on this issue.

Why is the platform prioritisation of core Kotlin libraries (KotlinX Serialization, Ktor, Exposed etc) maintained by JetBrains inconsistent? Would it not make sense to have a standard platform support policy in place to ensure prioritisation is kept consistent (simple). How does the libraries part of the Kotlin team operate when it comes to supporting multiple targets in regards to porting?

Tooling

Another area of porting that shouldn’t be overlooked is tooling. Having the proper tooling for a platform can make or break porting efforts. With some platforms it makes sense to use that platform as a host platform for development. Some platforms like Linux have so much crossover between multiple CPU architectures that it makes sense to designate ALL widely used platforms as host platforms, and provide the development tooling to make it happen.

Providing tooling to make Linux ARMv8 (linuxARM64 target) a host platform should be done to ensure consistency (Linux ARMv7 isn’t powerful enough as a host platform. After all the MacOS targets are host platforms, why isn’t the same thing being done for Linux (incl Embedded Linux)? Embedded Linux is widely used on many ARM based devices. Some of these devices (eg Raspberry Pi 4 Model B — 8 GB RAM version) are powerful enough to be used like a software development PC. Languages like Go and C already support using Linux ARM devices as development hosts, and have the tooling in place to support it. Limiting the Linux development host support to X64 only doesn’t make any sense.

Various parts of Kotlin tooling are needed for a host platform:

1. IDE
2. Kotlin IDE plugin
3. Kotlin compiler
4. Build system
5. Kotlin build plugin

If any of these parts are missing then Kotlin development cannot be done on the host platform. Using Linux ARMv8 as an example only parts 1 and 4 are available. Linux X64 has all of the necessary parts, and wouldn’t need too many changes to adapt the parts to cover the missing ones that Linux ARMv8 lacks.

Conclusion

Kotlin’s intense focus on porting to mobile/Apple platforms has come at the expense of other supported platforms that badly need proper support. Porting Kotlin to additional platforms needs to be standardised, and be a straightforward process as much as possible. If the porting problems continue to persist then the doors will remain closed to the Kotlin community on porting Kotlin to additional platforms, without the Kotlin team doing the leg work themselves.