Scaling Rust in the Enterprise: What Changes When Rust Gets Big
In a Nutshell
Rust adoption in large organizations creates critical build bottlenecks as codebases grow, with 46% of developers reporting rebuild delays and CI performance blocking releases. Standard Cargo builds struggle with sequential dependencies and limited parallelism, especially in multilingual environments like Android where Rust now represents 61% more compilation tasks than two years ago. Incredibuild solves this through distributed task execution across networks, shared caching that reduces 9-minute builds to 30 seconds, and integration with RustRover that maintains developer workflow while accelerating background builds.
These notes were generated by AI and may contain inaccuracies.
Orhon Parmaxes, Rust developer and advocate at JetBrains, hosts the webinar with Incredibuild. Joining as special guests are Neris Stern, Vice President of Product at Incredibuild, and Dori Exterman, Senior Advocate at Incredibuild. The session focuses on Rust adoption in organizations, specifically addressing challenges that emerge when Rust moves into larger teams and multilingual software databases. Construction, testing, and integration times can pose serious problems at enterprise scale. The webinar will examine Incredibuild as a solution for these issues, discuss RustRover, and provide tips for maintaining continuous Rust development at enterprise scale.
Dori Exterman, chief advocate for Incredibuild, clarifies that this is not a presentation about Incredibuild itself, though the product will be touched on briefly. Rather, the focus is on demonstrating how Rust is used widely in organizations, defined as large work teams and complex software development rather than large banks specifically. Drawing on Incredibuild's extensive experience with the world's largest and most sophisticated leading development teams, the presentation shares challenges and opportunities that Rust language usage presents in large-scale development organizations.
Over the past three years, Rust has passed a significant operational milestone, moving from being a promising experimental language to a core back-end server infrastructure. Multiple teams working on one warehouse, a critically important production engine—all of that now exists in production. When Rust expands into institutions, the expansion occurs in three dimensions. First, the increasing use of the Rust language among engineering teams, the huge number of people working on the same projects, and the complexity of the projects themselves and their software databases, which are becoming more complex and larger. Secondly, how Rust interacts with other languages and tools that existed before Rust came along, which applies to large projects. While there are projects that rely solely on Rust, this is rare when it comes to large organizations.
Rust has officially moved from being a niche programming language to a standard for enterprise infrastructure. According to a recent survey by JetBrains, there are now more than two million active Rust developers worldwide, with nearly 50% of surveyed development organizations reporting that they run complex Rust workloads in production environments. These are huge adoption figures. Production safety data from Android system data at Google shows that after Google systematically migrated its memory-sensitive subsystems to Rust, the density of security vulnerabilities decreased by a factor of 1000, dropping to just 0.2 security vulnerabilities per million lines of code. This resulted in a fourfold decrease in production downtime and a 25% reduction in code review times.
AWS built Firecracker using pure Rust language to run Lambda and Fargate. This provides uptime for small virtual machines as low as approximately 100 milliseconds with less than 5 MB of additional memory per instance, allowing for a massive density of infrastructure. These are Rust's promises such as parallelism and critical safety.
Rust's value proposition is being adopted across different sectors and use cases. One of Rust's core values is security and the safe execution of code, which has always been the main reason for Rust's existence. In automotive and embedded systems, as well as in the gaming industry, these capabilities are extremely important. The challenge here is not limited to writing separate Rust code, but extends to integrating decades of native software development kits (SDKs) for the C and C++ languages. By encapsulating these insecure C calls within the strict boundaries of the Rust API, teams are able to update the platforms without any compromise to memory integrity.
Another crucial aspect of Rust is its predictable and secure real-time performance. This means significant growth in the financial technology, peripheral technology, and communications sectors, especially in financial technology and trading. The goal here is to eliminate unexpected data collection latency and sudden spikes that occur below peak load. By using lock-free synchronization and zero-copy data processing, the teams achieve P99's stringent sub-thousandth-second response time targets with Rust.
In artificial intelligence infrastructure, developer tools, and software as a service (SaaS), high-level programming languages such as Python face limitations in multithreading. The ideal solution is to have an asynchronous Rust core wrapped with user-friendly APIs for developers, which other languages can use.
At Microsoft, teams are gradually replacing legacy C and C++ code within the Windows operating system kernel and Azure subsystems. This directly addresses the root cause of memory security errors, which historically have caused about 70% of Windows vulnerabilities.
Cloudflare developed Bingora, a framework dedicated to Rust asynchronous proxies, replacing the popular X engine. Bingora handles more than 40 million HTTP requests per second at the edge without any memory failures or downtime.
1Password built a single Rust kernel without a graphical interface, compiled natively for Windows, macOS, Linux, as well as iOS, Android, and WebAssembly. This provides 100% common encryption logic across six different client platforms.
As Rust databases have grown from very small services to multi-team single repositories, delayed response from developers has become a serious point of friction. According to a recent JetBrains survey about the Rust ecosystem, 46% of developers reported that rebuilding every minor change is a big problem. One in five developers waits more than a minute every time they make a simple edit. 25% of engineering organizations see Continuous Integration Building (CI) performance as a major obstacle to software release. These bottlenecks are exacerbated by the increasing size of Rust code databases and by the significantly increased frequency of code replication as a result of automated programming.
When a developer or AI agent waits more than approximately two minutes to perform a Cargo check or test after changing a single line of code, the context switch begins. Changing the context is the developer's responsibility, while the artificial intelligence remains in a dormant state. At the organizational level, delayed response is not just a minor inconvenience, but becomes a real burden on the entire engineering system, especially with the shift to automated software factories.
The reason Cargo Build has difficulty at the enterprise level lies in the mechanism for building trust and the way it is built. The three main stages in the Rust build process are highly interdependent and somewhat sequential. The nature of these bottlenecks limits parallelism, both on the local machine and on software distributions. This challenge requires customized strategies, especially when the software databases are large, and particularly when they are heterogeneous and include languages other than Rust.
Improving enterprise architecture requires moving from vague command-line logs to real-time architecture visualization. Each green bar in the visualization represents a process that is carried out as part of the Rust building process. The visualization provides much more information than simply reviewing the records. It is not possible to distribute and run many tasks in parallel for the entire duration of an 8-minute Rust project, meaning that even dedicating a machine with 128 cores would only finish in 8 minutes. Caching is the best way to handle sequential tasks.
The Android operating system is a great example of how the Rust language can be used in large and complex projects. Rust is an integral part of Android and has been around for several versions, with its role increasing in the Android Open Source Project (AOSP). Rust has stringent requirements for secure implementation, performance, and scalability. AOSP 17, the latest version recently released by Google, demonstrates the development of massive databases for critical infrastructure used on phones, cars, televisions, and everywhere.
Rust is rarely grouped in isolation in enterprise environments. In a production environment like Android, Rust C falls within a very complex implementation scheme containing over 80,000 clang calls, plus Java and Kotlin compilers, bytecode optimizations such as R8, and over 20,000 custom AIDL code generators. This is a huge and varied building blueprint consisting of approximately 20 different tools and 120,000 quest summons. In this massive building scheme, Rust comes in second place after C++. Compilation processes of C++ are remarkably parallel, whereas Rust is much less parallel. Sequential tasks and overlapping dependencies play a crucial role in the performance and speed of construction.
There was a 61% increase in Rust assembly callbacks between AOSP 15 and AOSP 17, meaning Rust is rapidly taking over older C and C++ subsystems. If build acceleration tools only understand Cargo, they are ignoring 80% of the AOSP build scheme. If they only understand C++, they are ignoring the other critical bottleneck of the remaining 80 tools introduced in AOSP. Accelerating Rust on a large scale requires a complete understanding of the multilingual system, not just how Rust or C++ works.
Measuring the performance of the AOSP 17 multilingual scheme on a standard 32-core workstation shows that without acceleration, building AOSP 17 takes more than two hours. If only C++ language is accelerated, the time decreases to 70 minutes. After accelerating C++ language, there are approximately 17 additional tools including Java, Kotlin, and IDL included in AOSP 17 release. If everything except Rust is accelerated, the build time drops to 27 minutes. When Rust acceleration is added, the build time drops to 19 minutes. The additional eight minutes provided by Rust makes a big difference, improving performance by 30%.
Speeding up the assembly process is not enough. To achieve true speed, a three-part strategy is required. First, a comprehensive view is needed to map the critical path, dependencies, sequential tasks, execution frequency, and what is executed when anything changes. Visual display tools are required, and construction processes and workflows must be queryable intuitively. Log files cannot be analyzed to gain a comprehensive view. Second, distribution and parallelism are needed to utilize all processor cores. With Incredibuild, tasks can be distributed to devices on the network or in the cloud, and hundreds or thousands of tasks can run in parallel. Third, smart shared caching is the most important element, and the direction the world is taking today.
Shared caching is always much faster and more economical to reuse vetted building materials between work teams rather than re-running them. It is always faster and cheaper not to turn anything on than to turn it on quickly. Especially when working in the cloud, fetching data from the cache greatly reduces cloud consumption costs. When talking about large-scale development, this becomes a huge cost saving. Shared caching means that if the Continuous Integration (CI) system makes a change, developers can use it, and other CI nodes can use it as well. General caching means it is not for one purpose only—it can use a caching system for any specific task, meaning that any input, as long as it does not change, will result in the same output.
Generative artificial intelligence is the latest multiplier driving enterprise code size. According to a JetBrains survey, 78% of Rust developers effectively use AI programming assistants. Programs such as Upper Tractor use Logical Learning Models (LLMs) coupled with formal program analysis to automatically translate massive legacy C code databases into safe Rust code with high precision and speed.
Artificial intelligence presents a tremendous opportunity to migrate old code written in C, C++ and other languages to Rust. However, AI creates an operational challenge where it generates thousands of lines of extremely complex, fast, generic Rust code and code modules in seconds. This greatly expands the Rust library structure, but Rust still requires performance checks, type checks, and other operations on every single line of code generated by AI. The result is that AI doubles the size of code, which doubles the workload for the compiler and tester. AI also writes the tests, resulting in a large accumulation of different test implementations in each project.
Local central processing units reach their maximum capacity. IDE background tasks slow down and CI build queues get crowded. AI speeds up the writing process, but workflows must be developed to meet AI requirements to fully utilize the speed potential that generative AI provides. This becomes extremely important in the context of the transition to fully autonomous software manufacturing.
Technology managers and enterprise teams worldwide are making efforts to resolve operational bottlenecks caused by generative programming. A leading automotive company expects their build-up operations to increase by 500% in 2026 alone, requiring complete reconsideration of production line speed and structure.
RustRover contains an AI chat database that understands code and can generate code from within. When combined with Incredibuild, this provides incredible speed. The Incredibuild add-on system in RustRover includes operations such as building, rebuilding, and stopping builds, with configuration options to modify build tasks.
In the Incredibuild settings, the number of parallel tasks can be adjusted, with the demo showing 300 parallel tasks. The add-on serves as a layer on top of RustRover that integrates well with the IDE, allowing users to build using the plugin while maintaining normal workflow.
Testing with Bevy (an open-source Rust project for games and graphics) on a four-core Windows device showed a build time of approximately 9 minutes without Incredibuild acceleration. The full build view revealed that despite the local device having only four cores, acceleration potential through distribution was limited due to several very long tasks that depend on each other.
When adding distribution with a more powerful 12-core device, build time improved slightly to approximately 8 minutes. However, the benefit was not truly meaningful due to long sequential tasks at the end of the build. The full build view provides valuable information about potential improvements even without Incredibuild.
Shared caching provides remarkable acceleration, reducing build time from 9 minutes to 30 seconds (over 90% improvement) after the cache was filled. The full construction overview showed this was due to limited tasks being carried out, with cache memory usage rate at 98%. When rebuilding after code changes including simulated teammate modifications, the build took only 44 seconds despite changes being made.
The key advantage is that the cache is not only local but shared by everyone, with every team member benefiting from the cache filled by the CI system or other team members. This differs from incremental builds, where you must rebuild all other code changes when merging the latest repository version.
Even when builds fail, acceleration provides significant benefits by enabling faster feedback and problem resolution. Incredibuild provides unique information about the build plan, all tasks performed, dependencies, and changes made, enabling useful analysis of why builds fail. An AI agent can analyze problems and identify root causes, with complete recommendations on how to fix issues that can be copied into the AI agent.
The system is working on showing differences between various build processes, allowing comparison between successful and failed versions to clarify what changes might have caused failures.
When using incremental versioning, the built-in system examines changed code and builds only that code. However, when merging code and building with the latest repository version, especially with AI-generated code, the build process may take very long. The shared cache benefit is that all elements built on new code are already in the cache from other developers or CI systems.
During construction, the mechanism first checks local cache, then shared cache if not found locally. This applies to feature branches where developers want to create and maintain multiple branches, and to CI environments with temporary devices that always rebuild from scratch.
Caching stores not just final output but intermediate output created by each task within the build process. Benchmarks like Google show 93% success rate for caching across projects. A bulk cache service can be configured that all developers can access, with local copies for fastest access. The process begins with local memory access, then transfers to shared memory if files are not located locally.
Companies can adopt strategies where the CI system fills shared memory while developers only read from it. The CI system builds code periodically while developers consume most changes. When performing full extraction, developers will likely ensure access to all files in shared memory.
When distributing tasks as part of a RustRover build to another machine, it is not necessary to install RustRover on the remote machine or copy the project to it. The remote machine can be a virtual machine ready to use directly without any software. Incredibuild features unique virtualization technologies similar to containers and runtime environments that enable running tasks on remote machines and simulating everything required.
The cache memory mechanism maintains a record of everything that contributed to file creation, including source code, environment variables, compiler version, and other factors that may affect the final file. Based on this record, the system checks the cache and determines if the file created using that record exists. If it exists, the file can be used; if not, the file must be created from scratch.
Incredibuild's most important feature is that users don't have to choose between optimization techniques. The system automatically selects the best approach during build. Caching is always the best option when data exists in cache memory, being faster and more cost-effective. For sequential tasks where parallelization isn't possible, caching provides the only viable acceleration option.
If no data exists in cache, Incredibuild automatically runs tasks in parallel across the network on the local machine or other devices according to the strategy used. By default, it occupies as many tasks as possible according to available cores in the Incredibuild network. Clients run hundreds of tasks in parallel on multiple devices.
When developers want to continue working on RustRover IDE while building code in the background, Incredibuild distributes all tasks across other devices, freeing up resources from the local machine. This allows developers to continue working on other tasks or with RustRover while builds continue in the background on other devices without burdening their laptops.
This benefit amplifies for CI servers, allowing increased throughput and more builds per CI server. When CI queue accumulation is the main problem rather than build length, caching and distribution enable grouping more builds and running them in parallel, making build backlogs resolve faster and less expensively in the cloud.
Developers can access the Incredibuild plugin for RustRover by visiting incredibuild.com to obtain a free 30-day unlimited trial period that includes all distribution and caching functions. The website provides instructions on operating utilities, installation procedures, running on multiple devices, and setting up caching. A link to the appendix is available in the documentation, with plans to add it to the RustRover store soon.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
