The Case For Kotlin In Embedded Development

Some programming languages have come and gone that aim to be a replacement to C for embedded software development yet they all fail. Easy to see that they all fail because of their intention to replace C, which is an aggressive move that isn’t likely to convince C developers to use these languages. What is even worse than this is that all of the languages focus on the issues of C rather than the real issues that all embedded developers currently face on a regular basis.

In this article a case is being put forward for Kotlin in embedded development as an alternative, and a complimentary part of C in amateur/professional embedded software projects, which don’t require real time performance and aren’t safety critical. Since many embedded software areas aren’t real-time/safety critical there is plenty of room for an alternative/complementary language.

Background

In software development history some languages have been used in areas they weren’t designed for by accident only to find they are a good fit. Java is one good example of this with server-side development. Kotlin is another example with mobile development via Android. Just because a language hasn’t been designed for a given area doesn’t mean it will automatically be a bad fit, sometimes it ends up being a good fit. The only way to find out is to try things in a pragmatic way. In the case of Kotlin with embedded development it requires porting it to a Uc (eg an ARM microcontroller) to do a simple Blinky project (embedded development’s equivalent of hello world), which is only the start.

Traditionally many languages trying to position themselves to embedded development focus on developing their own ecosystem rather than integrating with the ecosystem provided by the target platforms, which results in a significant amount of friction via wasted time and software that is far less mature. Kotlin from a historical perspective takes the opposite route (which isn’t very common) recognising that there are many good platform libraries/tools out there that are still usable/valuable, why reinvent the wheel?

Embedded Development Issues

• Significant amount of tooling that isn’t keeping up to date with current embedded development requirements (eg no refactoring, missing Unit Testing support)
• Very cumbersome to set up embedded development toolchains
• All previous alternative languages don’t focus on integrating with the embedded ecosystem
• No easy way to handle software dependencies
• Namespacing is missing
• Lack of type safety
• Learning curve for embedded software development is too high (should be significantly lower)
• Too many barriers of entry to do an embedded development software project
• Can’t use a standardised programming language (one that isn’t fragmented) across a wide variety of embedded hardware

Value Proposal

Below is a list of the benefits Kotlin would provide for embedded development:

• Has good type safety (statically typed)
• Decreases the number of serious issues relating to handling null (aka — “the billion dollar mistake”) through the type system
• Provides increased developer productivity without leaving performance as an afterthought
• Enables the use of FP (Functional Programming) without sacrificing performance
• Has builtin support for Coroutines (very low overhead concurrency)
• Can easily organise code in a way that is suitable for whatever embedded project your’e working on
• Not forced into any specific programming paradigm, can use whatever is suitable for a given project
• Allows inlining of functions and properties (has various options) for increased performance
• Forces constants and variables to be initialised which reduces the chances of introducing logic errors
• Kotlin is a versatile language (general purpose) which can be used in other areas of development (eg serverside, Android, web frontend, desktop) which might be part of some embedded projects
• Has a focus on developer productivity, readability, pragmatism, and explicitness
• Can utilise existing investment in embedded ecosystem tools and C libraries
• Performance critical code can be written in C and used in a Kotlin program
• Kotlin has a reasonably low learning curve (suitable to learn as a 2nd language)
• History of good tooling support for Kotlin (CLion supports Kotlin Native via a external plugin)
• Can use Kotlin for scripting (excels at scripting tools)
• Kotlin is licensed under the Apache 2 license which is more friendly for embedded development (for embedded developers and businesses) than GPL 2 (fewer business are using this license, some are moving away from it — eg ARM and Samsung)

Challenges

• Decreasing the size of the Kotlin standard library so there is ample room for a Kotlin program in Uc flash
• Determining what non important functionality can be safely removed from the Kotlin standard library
• Providing value types in Kotlin for performance and C interoperability without affecting reference types
• Adapting Kotlin and the standard library so that manual memory management works without major issues
• Minimising build overhead to ensure quick feedback in the software development process
• Preventing Kotlin from being fragmented while ensuring proper native integration at the same time

Conclusion

It is far better to take an approach where a language positions itself as an alternative and is complimentary to C for embedded development, which properly integrates with the embedded ecosystem. Kotlin has plenty of benefits to provide for embedded developers that would make it worth trying out for embedded development. Currently there is a process under way to port Kotlin to Ucs (ARM based ones) via Kotlin Native.