Systems programming remains a broad field spanning operating systems, embedded software, developer tools, games, servers, and hardware-oriented applications. The 2024 measurements below show strong activity around C and C++, growing interest in Rust, and persistent attention to build complexity, compiler choice, and safety practice.
Contents
- Open-source activity and ecosystem signals
- Rust adoption and workplace use
- Where C++ systems programming is used
- Build, dependency, and cloud workflow measurements
- C++ standards modernization and safety practice
- Adjacent skills and compiler choices
Open-source activity and ecosystem signals
GitHub’s Octoverse 2024 report recorded more than 5.2 billion contributions to over 518 million public, private, and open-source projects during 2024. The same report counted 108 million new repositories created during the year. These figures describe activity on GitHub, rather than the total installed base of software or every systems programmer worldwide.
The platform’s 2024 language ranking placed C++ sixth among the most-used programming languages and C ninth. Rust ranked seventh among GitHub’s ten fastest-growing programming languages. GitHub’s ranking aggregates commits, issues, pull requests, comments, discussions, pushes, and reviews, so it is best read as a measure of platform activity across those actions rather than as a direct measure of language ownership, deployment, or runtime prevalence.
The wider software environment is also distributed across multiple execution targets. In the JetBrains 2024 State of Developer Ecosystem Report, 58% of respondents said their code ran on browser platforms, while 53% said it ran on desktop platforms. JetBrains reports weighted survey results from 23,262 developers worldwide, measured in May and June 2024. Browser and desktop figures are not mutually exclusive, and they do not isolate systems-language projects.
Together, these observations place systems programming inside a much larger development ecosystem. A C or C++ component may support a desktop application, a browser-facing product, a server, or a hardware device, while the surrounding project uses several other languages and tools.
Rust adoption and workplace use
The 2024 State of Rust Survey results provide a community-level view of Rust adoption in December 2024. About 92% of respondents self-identified as Rust users. Among current Rust users, 53% reported using Rust daily or nearly daily, and 38% said Rust represented the majority of their coding at work.
The survey also measured organizational use. Forty-five percent said their organization made non-trivial use of Rust. Among Rust-at-work respondents, 21% said they used Rust because they already knew it and it was their default choice. A larger 82% reported that Rust helped their company achieve its goals. These results indicate positive reported workplace value, but they are not a population estimate for all software organizations.
Interest in Rust was not limited to current users. Among former Rust users surveyed in 2024, 63% said they would consider using Rust again if an opportunity arose. At the same time, about 31% of non-Rust users cited perceived difficulty as their primary reason for not using it. Only 7% of respondents preferred Rust to slow down or completely stop adding new features.
The survey’s geography also matters. The United States accounted for 22% of respondents. Because the Rust figures come from a Rust-community survey, they describe the participating respondent population and should not be treated as a neutral estimate of global language share. They are nevertheless useful for understanding how current users describe frequency, organizational adoption, perceived value, and barriers to entry.
Where C++ systems programming is used
The 2024 Annual C++ Developer Survey “Lite” shows that C++ remains closely tied to professional systems-oriented work. Among 1,262 respondents, 91.05% reported using C++ at work, while 67.59% reported using it for personal-time or hobby projects.
The project categories show several overlapping use cases. Engineering projects were selected by 31.51% of 1,260 respondents, and hardware or IoT projects by 29.92%. Developer tools accounted for 27.38%, while gaming projects accounted for 20.87%. These are selections from a survey question, so they should not be added together as if each respondent belonged to only one category.
Target platforms reinforce the breadth of C++ systems work:
| Target platform | Share of respondents | Question denominator |
|---|---|---|
| Windows desktop | 60.56% | 1,260 |
| Linux server | 57.30% | 1,260 |
| Linux desktop | 56.75% | 1,260 |
| Embedded systems | 32.22% | 1,260 |
The platform figures are self-reported and overlap. A single C++ project can target more than one operating system or deployment environment, and a developer can work across desktop, server, and embedded targets. The measurements therefore describe the range of reported targets rather than a ranking of exclusive market segments.
Build, dependency, and cloud workflow measurements
Build and dependency management were prominent pain points in the 2024 C++ survey. Managing application libraries was a major pain point for 45.43% of 1,257 respondents. Build times were a major pain point for 42.86% of 1,253 respondents. Setting up a continuous-integration pipeline was a major pain point for 30.35% of 1,239 respondents, while CMake project management was a major pain point for 30.38% of 1,241 respondents.
The reported dependency arrangements help explain why these issues persist. Source code for dependencies was part of the build for 68.54% of 1,246 respondents. Separate compilation of libraries using their own instructions was reported by 48.48%, and system package managers such as apt or brew were used by 37.80%. These approaches can coexist within one project, so the percentages are not alternatives in a single-choice distribution.
CMake was used as a build tool by 83.24% of 1,253 respondents. That figure shows how central CMake was among this survey population, while the separate pain-point result shows that widespread use does not eliminate configuration or project-management friction. Build-system adoption and build-system satisfaction are different measurements.
For systems programmers, the practical implication is that language choice is only one part of delivery. Libraries, source integration, package managers, reproducible builds, continuous integration, and platform-specific instructions all shape the cost of maintaining a C++ codebase. The survey provides measured signals for each of these areas, but it does not establish causal relationships between a particular tool and a particular pain point.
C++ standards modernization and safety practice
The 2024 C++ survey also measured how broadly different language standards were allowed. C++11 was allowed with pretty much all features by 90.81% of 1,164 respondents, and C++17 by 77.79% of 1,211 respondents. The corresponding figures were 31.61% for C++20 among 1,196 respondents and 20.02% for C++23 among 1,164 respondents.
These results show a substantial difference between older widely permitted standards and newer standards. They do not mean that every feature in an allowed standard is used, nor that projects rejecting “pretty much all features” cannot use selected features. The wording measures the policy reported by respondents for their projects.
There was also evidence of planned modernization. More use of newer C++ standard features within the following 12 months was planned by 53.92% of 1,250 respondents. Production use of C++20 concepts within the next 12 months was planned by 60.45% of 1,191 respondents. Both measurements refer to plans reported in 2024, not completed adoption or a forecast independently validated after the survey.
Safety-related practice was mixed. Sanitizers or fuzzing were part of the normal development and release cycle for 48.68% of 1,251 respondents. A further 45.08% said their project did not use sanitizers or fuzzing in its normal cycle. The remaining responses are not characterized by the supplied measurement, so these two figures should not be treated as a complete partition of all practice.
For a C programmer moving toward larger systems projects, these figures highlight two separate decisions: which standard features a project permits and which testing or analysis practices are routine. Modernization does not automatically imply sanitizer or fuzzing adoption, and the survey does not claim that either practice alone guarantees software safety.
Adjacent skills and compiler choices
Systems programming is often multilingual. In the C++ survey, Python was used alongside C++ by 72.82% of 1,225 respondents. C was used alongside C++ by 53.06%, Rust by 18.37%, and Assembly by 17.96%. The results suggest that C++ work frequently sits in a toolchain containing scripting, lower-level compatibility, newer systems-language, and machine-oriented skills.
Compiler selection was similarly distributed across respondent groups. GCC was the primary C++ compiler for 67.45% of 1,100 compiler respondents. MSVC was the primary compiler for 64.21% of 799 compiler respondents. The different denominators matter: these are not directly comparable shares from one identical question population, and the figures do not show that GCC and MSVC are mutually exclusive across all projects.
Taken together, the 2024 evidence describes systems programming as a field with durable C and C++ activity, meaningful Rust adoption signals, and a broad set of platforms and adjacent tools. The strongest measurements are descriptive: they show what participating GitHub users, JetBrains respondents, Rust survey participants, and C++ developers reported during 2024. Their populations and denominators should remain separate when interpreting the numbers.