The decision to rewrite the Mender client from Go to C++ was purely strategic. The main reason is to expand the number of platforms our Mender client can support going forward and increase compatibility with platforms aimed at the embedded market. These include the common real-time operating system (RTOS) platforms: QNX, Zephyr, FreeRTOS, and VxWorks. Any concerns about code quality, maintainability, or security do not drive it.
The Mender server will remain developed in Go, so this change only affects the Mender client (and will not affect add-ons, such as Troubleshoot or Configure, at this time).
What does our decision to use C++ and the rewrite mean for you as a user or contributor? You can find answers to your questions in the following Q&A. If you have any additional questions, contact us in the Mender community.
Rewriting the client is required to enable the Mender community to use a broader set of devices and platforms. Because of Go language incompatibility, it is practically impossible to keep using Go while allowing support for real-time operating systems (RTOSes) and lower-footprint hardware, like microcontrollers.
Due to compatibility, only two realistic options exist: C or C++. Of the two, C++ is more robust against programming errors and has features that speed up development.
We rejected Ada because of its low market penetration and Rust because it is not available on all of the aforementioned embedded platforms.
One codebase allows development and maintenance focus, enabling faster feature releases and a more stable, robust, and secure client. One client also means all contributions can benefit everyone instead of just a subset of the users.
No. At this time, the existing services providing the add-ons will remain developed in the original written languages. For example, Remote Terminal is an add-on provided by the service mender-connect, not mender-client, so it will be unchanged. New additions might be written in C++, depending on the requirements.
The quality of the code and security have always been essential; this is unchanged. In fact, using the same existing tests and test infrastructure ensures the C++ client and existing Go client are equally thoroughly tested. All the same security practices applied to the Go client apply to the C++ client.
Yes.
It's possible to write robust code in any language. Some of the features offered by C++ make it easier to write robust code, such as strict ownership of resources, const correctness, type safety, and garbage collection. Modern C++ includes many more robust concepts built in than earlier versions of C++. Additionally, our experience writing professional production code in C++ ensures the same level of robustness as the Go client.
The "rootfs-image" update type is no longer built-in but exists as an installable Update Module. For example, it is now possible to customize or uninstall it and use Mender only for application updates. Functionally, it behaves the same, and only the installation is affected.
The C++ client removes support for Artifact format version 2. (The Go client also planned to remove the Artifact format version 2.)
Except for Update Control Maps (the ability to synchronize updates), the C++ client preserves all other features, ensuring high compatibility between the existing Go client and the C++ client.
No. Performance remains the same for the C++ client and the Go client.
The C++ client forbids raw C pointers, the biggest source of memory leaks, except in specialized instances. Instead, the C++ client uses smart pointers in all cases, with almost the same memory leak protection guarantees as Go's garbage collection.
The first version of the C++ client will not run on Zephyr. However, Zephyr support is currently in progress.
The first version of the C++ client will not run on FreeRTOS. However, the transition to C++ makes a port to FreeRTOS possible.
The first version of the C++ client will not run on QNX. However, QNX support is also in progress.
The Go client is currently in maintenance mode. The Go client will continue to receive bug fixes. However, most new features will not be applied with the possible exception of very small scopes or strong justifications to include them quickly. To future-proof projects, using the C++ client is strongly recommended. It is also recommended that existing projects plan to migrate to the C++ client.
From a feature perspective, both the Go and C++ clients are quite mature. Going forward, the focus is on extending server functionality and other client components, such as mender-connect, mender-configure, mender-binary-delta, meta-mender, and mender-convert. The server and these features are under further development today, including new, related features.
Depending on the exact setup, the build environment requires some small changes.
On the device, the binary is a drop-in replacement. It provides all the necessary requirements in current Yocto recipes and Debian packages, so most users are not affected (unless a specialized setup is used). There are only minor differences from a typical upgrade process. To most users, the change is unnoticeable.
For details, see the Debian and Yocto sections on client upgrades.
It depends on the exact functionality and behavior being used. The main difference is the split of the single mender binary into various functionally orthogonal components, such as mender-auth, mender-update, and more.
For details, see the migration document.
The C++ client supports all build and OS environments currently supported for the Go client.
Note: Third-party community members maintain buildroot and upstream Debian support. Support for these is at the discretion of their respective maintainers. However, there is no reason buildroot and upstream Debian cannot be adapted.
The C++ client uses the same license as the Go client, Apache 2.0.
Going forward, all new contributions should target the C++ client.
Go client contributions will only be accepted if it targets critical bugs or security fixes.
The Go client will fall under the normal release cycle as described in the Mender documentation.