Kotlin Native For IoT
When Kotlin Native was first released the platform was originally designed to cover iOS, desktop, tooling, and infrastructure development. Since then Kotlin Native has been used in other areas like embedded development, however there has been no big push for IoT (Internet of Things) development. The IoT market is estimated to be worth around 212 billion USD by the end of 2019, which shows a LARGE market with plenty of opportunities for Kotliners. Also in the latest Kotlin developer survey 7% of apps are IoT based, and it is likely the IoT development will become a major software development area for Kotlin within a year. As the survey mentions Kotlin Native opens up IoT opportunities for Kotliners (“… Opening the way to IoT for Kotlin developers”).
There are some key findings from the Eclipse 2019 IoT survey. Much of the IoT growth is fuelled by industrial markets. The main IoT industry focus areas are Platform (34%), Home Automation (27%), and Industrial Automation (26%). Forty percent of IoT developers develop IoT solutions at work.
Linux
Linux provides a few opportunities for Kotliners especially in IoT. If there is one constant in IoT development it is that Linux is the dominant OS (covers edge devices, gateways, IoT desktops, and Single Board Computers). In the 2019 Eclipse IoT survey Linux is used on 76% of all edge devices/gateways. The top Linux distributions used are Ubuntu (#1), Raspbian (#2), and Debian (#3). More and more constrained devices are using Linux instead of not using a OS (bare metal). According to the Eclipse 2019 IoT survey only 11% of constrained devices aren’t using a OS (a significant drop from 20% in the previous year).
Considering that Linux is the top Kotlin Native target platform (at 74% according to the JetBrains 2019 Kotlin survey) the Kotlin Native team need to re-prioritise target platforms. One wonders why the Kotlin Native team is placing a higher priority on iOS than Linux considering that iOS isn’t the biggest target platform (at 28% which is below Android, MacOS, and Windows). It is very likely that someone will be asking the Kotlin Native team during Kotlin Conf Q&A the awkward question of why Linux isn’t a higher priority than iOS.
Benefits
Kotlin Native has plenty of benefits to offer Kotliners for IoT development. Security is ranked as the top concern by IoT developers (at 38%) in the 2019 Eclipse IoT survey. Kotlin Native has some features that make it easier to develop safer/secure IoT apps which include the following:
- Safe transfer of data between threads via Workers
- Memory scoping to safely manage memory when interacting with C APIs (decreased likelihood of encountering memory issues like segmentation faults)
- Built in bounds checking with collections, and strings (prevents sensitive data from being leaked)
- Non blocking concurrency via Coroutines which aids in developing applications that are resistant to DoS attacks
- Dynamic linking of system libraries (reduced attack surface, automatically gain security fixes via system updates)
The next concern for IoT developers is connectivity (at 21%). In the Kotlin ecosystem there are Kotlin Native libraries available that cover [serialization](https://github.com/Kotlin/kotlinx.serialization), and [web clients](https://ktor.io/clients/http-client/multiplatform.html).
Performance is the fourth concern (at 18%, is the fastest growing concern) for IoT developers which shouldn't be overlooked/underestimated. Kotlin Native unlike the other Kotlin development platforms has a big focus on performance, and provides a few features that make it easier to develop high performing applications. Some of these features include the following:
- Variable width data types (reduced memory consumption)
- [ARC](https://en.wikipedia.org/wiki/Automatic_Reference_Counting) memory model (more responsive applications that are very unlikely to pause like GC based applications)
- Dynamic linking, and dead code optimization (smaller binaries)
- Pass by value (in some cases there are no additional memory allocations)
- Access to unsigned data types (reduced memory consumption)
Currently Kotlin Native has a partial GC (cyclic collector) which manages cyclic references, and can’t be turned off. Once the option to turn off the cyclic collector is available then Kotlin Native can provide some soft real time performance guarantees.
Issues
By far the biggest issue for Kotlin Native is to have a viable ecosystem that covers the essentials, and a solid C interop system that is compatible with around 90–95% of all C libraries. Tooling is lacking in some key areas (missing visual memory analyser for Kotlin Native apps, cannot easily browse the source of a KLib, no visual KLib documentation browser etc). Compilation speed of Kotlin Native programs via Konan is way too slow, and needs to match the speed of the Kotlin JVM, and Kotlin JS compilers.
Believe it or not perception of Kotlin Native is a issue with many people thinking that Kotlin Native is only for mobile development. This isn’t true yet the issue still persists and needs to be nipped in the bud.
Bit manipulation is very common with Iot projects. Kotlin doesn’t have a easy way to do bit manipulation since it is missing many essential bit manipulation operators (a top Kotlin issue for many Kotliners). With Kotlin 1.4 being about a month or two away from release it seems unlikely that bit manipulation operators will be added, therefore many Kotliners will continue to endure the pain (torture) of a failed Kotlin language experiment (bit manipulation via infix functions).
Competitors
In the IoT space Kotlin Native has two big competitors (GraalVM and Go lang). With performance Kotlin Native has an important edge with memory usage and responsiveness via ARC, which is especially important for client based applications, and applications running on constrained devices like a SBC (Single Board Computer). Many IoT development situations require deep level platform integration (especially when there is control of both the software and hardware) that can be done safely with minimal effort (aka automatic mapping generation of type safe system APIs), which both GraalVM and Go lack.
Even though GraalVM allows self contained binaries to be generated for JVM applications the following saying is applicable, “You can take the application out of the JVM, however you cannot take the JVM out of the application”. In other words some of the JVM downsides will still be present in a JVM application that is packaged as a binary (reliance on GC memory model, large program size, dependency on JVM reflection etc).
Some people may say that Kotlin Native needs a large ecosystem to compete with GraalVM and Go, however that isn’t necessary since Kotlin is heavily reliant on its interop system which means quality is more important than quantity. If the interop system isn’t solid then that is a much bigger concern that hinders Kotlin’s adoption.
Conclusion
Kotlin Native needs to make a big push for IoT ASAP while the market is still in its infancy (IoT is like the PC market in the 70’s — there are dozens of platforms available which resembles a jungle), before the competitors become entrenched by which time it is too late. JetBrains can help out by expanding the Kotlin ecosystem to cover more of the essentials that Kotliners need especially with security (eg encryption, data validation), which is the top concern for IoT developers. Also JetBrains should be reaching out and establishing industry partnerships with Eclipse Foundation, Apache Software Foundation, and Linux Foundation who have enormous influence in the IoT market.