Announcing the rewrite of the Mender client to C++

We have taken the decision to rewrite the Mender client from Go to C++. Read about the reasoning for this decision below, and find answers to your questions in the Q&A.

The decision is purely strategic. It is not driven by any concerns about code quality, maintainability or security. The main reason is to expand the number of platforms our Mender client can support, to increase compatibility with platforms aimed at the embedded market. These include the common RTOS platforms: QNX, Zephyr, FreeRTOS, and VxWorks.

The Mender server will remain developed in Go, so this change only affects the Mender client (and will not affect add-ons such as Remote Terminal or Configure).



What does our decision to use C++ and the rewrite mean for you as a user or contributor? Find answers in the Q&A below, or contact us if you have any additional questions.




Rewriting the client is a step required to enable the Mender community to use a broader set of devices and platforms. Because of language incompatibility, it is practically impossible to keep using Go while enabling support for real-time operating systems and lower footprint hardware like microcontrollers.


Due to compatibility there were only two realistic options, C or C++. We chose C++ as it is more robust against programming errors and has features which make development speed a lot faster.

We rejected Ada because of its low market penetration. Rust was rejected because it is not available on all of the aforementioned embedded platforms.

Rather than having two codebases to look after, we want to focus our efforts on only one so that we can make it as stable, robust, and secure as we possibly can. It also means that all contributions will benefit everyone instead of just a subset of the users.



How will the new client differ?


No, the services providing the add-ons will remain developed in the same languages they were started with. For example, Remote Terminal is an add-on provided by the service mender-connect, not mender-client, so will be unchanged.

Quality of the code and security have always been essential, and we are not planning to lower the bar. In fact, we intend to reuse our existing tests and test infrastructure to ensure the C++ client will be as thoroughly tested as the existing Go client. We plan to use all the same security practices as we apply to the Go client.

Yes, we plan to reuse the same tests, which should give the same, very high test coverage.

It's possible to write robust code in any language. Some of the features offered by C++ make it easier to write robust code - like strict ownership of resources, const correctness, type safety, and garbage collection. Modern C++ has a lot more of those concepts built into it than the early versions of C++. With our experience writing professional production code in C++, we believe we will achieve the same level of robustness as the Go code.

The "rootfs-image" update type will no longer be built-in, but rather it will be an installable Update Module. This means it will be possible to uninstall this module and use Mender only for application updates, for example. Functionally it will behave the same, and it is only the installation that is affected.

Support for Artifact format version 2 will be removed (this was already planned for the Go client).

We will preserve all other features as they are and ensure full compatibility between the existing Go client and the new one written in C++.

No, we expect performance to remain the same for the C++ client as it is for the Go client.

Raw C pointers, which are by far the biggest source of memory leaks, will be forbidden in the new client, except possibly in specialized instances. Instead, the client will use smart pointers everywhere, which have almost the same memory leak protection guarantees as Go's garbage collection.

Not the first version. But the transition to C++ will bring us to a position where we can consider a port to Zephyr.

Not the first version. But the transition to C++ will bring us to a position where we can consider a port to FreeRTOS.

This depends on customer demand. It's possible that the first version will not run on QNX, but QNX is the highest priority of new platforms to support. As a result, QNX support will most likely be one of the first C++-only features to be implemented.



Client development


Yes, multiple people in the project have done professional programming in C++ for years.

Development of the Go client will continue at least until the C++ client is 100% feature compatible and during a stabilization period. However, there might be restrictions on the type of development. Bug fixes will continue throughout the whole period. Features will generally be rejected unless they are very small or there is a strong incentive to include them right away.

We can not guarantee to add a lot of new functionalities to the existing Go client, but all the changes introduced to the server will be supported by the Go client during the development of C++ one. There might be a lack of new client-only features while the rewrite work is ongoing.

Feature-wise, the client is pretty complete, and we are planning to focus on extending server functionality and other client components, such as mender-connect, mender-configure, mender-binary-delta, meta-mender, and mender-convert. Those will keep being developed like today, including new features.



Upgrading to the C++ client


Depending on the exact setup, there may be small changes needed to the build environment. On the device, the binary will be a drop-in replacement. will provide all the necessary fixes in our Yocto recipes and Debian packages, so most people should not be affected unless they use a very specialized setup. Most likely, there will be only minor differences from a typical upgrade process, perhaps none at all. Our goal is that users should not even notice the change.

No, they will continue to function as today.

The C++ client will support all existing build/OS environments that are supported for the Go client. Note that third-party community members maintain buildroot and upstream Debian support, so support for those is up to these maintainers. We see no reason that they could not adapt, though.



Community and how to contribute


The same license as the Go client, Apache 2.0.

There will be a point where will cease maintenance of the Go Mender client. At that point, we will stop accepting all contributions. However, anyone can clone and maintain the Go code if they want to, according to the Apache 2.0 license.

Absolutely! We will also provide updates on the progress of the development.

They have not been developed yet, but will be made available as soon as they are ready.





We guarantee support for the Go client at least until the C++ client is at 100% feature parity plus at least one LTS release cycle duration in addition. The release cycle is described in the Mender documentation.



C++ client launch


It is a big project, so it might be too early to give a timeframe for this. If you have a project which can benefit from the C++ client, please contact us to discuss timelines and potential acceleration.

Before advising to replace the current Go client with the new C++ client in production environments, we will thoroughly test it internally and with our users. The likely replacement for the production systems will be the second or third iteration, although we are expecting the first one to be a perfectly stable production-ready version.