Why Everyone's Switching to Rust (And Why You Shouldn't)

The Promise of Rust: Memory Safety Without Compromise [1:01]

• Rust is a systems programming language designed for memory safety without relying on a garbage collector.
• This contrasts with C/C++ where manual memory management (e.g., malloc, free) can lead to security vulnerabilities like use-after-free bugs, which account for 70% of Microsoft's security bugs.
• Languages like Java and Python use garbage collectors to manage memory, preventing these issues but introducing performance overhead and unpredictable pauses.
• Rust's solution is the "borrow checker," which enforces memory safety at compile time.
• Attempting to use memory after it's been dropped in Rust will result in a compilation error, not a runtime crash.
• The goal is to achieve performance comparable to C, safety like Java, and expressiveness like Python.

Rust solves all of this with this little thing called the borrow checker.

This section introduces Rust as a revolutionary systems programming language that tackles memory safety challenges inherent in languages like C and C++ without the performance drawbacks of garbage collectors found in languages like Java and Python. The core mechanism, the "borrow checker," is highlighted as the key innovation that shifts bug detection from runtime to compile time.

Comparative Analysis of Systems Programming Languages [2:10]

• A comparison was made by building a CLI application in C, C++, Rust, Go, and Zig.
• C offers raw speed and control but requires manual memory management, risking segfaults or memory leaks.
• C++ adds modern features like vectors and smart pointers but can be overly complex with multiple ways to achieve the same task.
• Go prioritizes simplicity and fast compilation, sacrificing some low-level control and performance.
• Zig shows potential with better tooling and compile-time safety but has a very small ecosystem and has been in beta for approximately eight to nine years.
• Zig is described as very low-level, putting the programmer in direct contact with the CPU.

C gives you raw speed and complete control, but you're managing memory manually with Malak and free. One mistake and you've got a seg fault or a memory leak.

This part of the video delves into a comparative analysis of several systems programming languages, evaluating their strengths and weaknesses in terms of speed, control, complexity, and ecosystem. It positions Rust as a language aiming to balance the benefits of these other languages.

Rust's Unique Position and Real-World Successes [4:34]

• Rust occupies a "unique sweet spot," offering C-like performance and control while enforcing memory safety at compile time via the borrow checker.
• The trade-off is an initial struggle against the compiler, often perceived as fighting endless bugs. However, this is preferred over debugging crashes later.
• Discord rewrote their read state service in Rust, achieving a 10x performance improvement and eliminating 2-minute garbage collection spikes that caused user-facing freezes.
• Dropbox spent four years rewriting their sync engine in Rust, describing it as a "force multiplier" for their team.
• Microsoft's Azure CTO suggested halting new projects in C or C++, and major Windows components have been rewritten in Rust, yielding 5-15% performance improvements and addressing security vulnerabilities.
• AWS built Firecracker for serverless computing using Rust.
• Rust is also gaining traction in web development with available frameworks and runtimes.
• CLI tools written in Rust, such as Ripgrep, FD, and Bat, are significantly faster than their Unix equivalents, changing developer workflows.

So, for all of you that just commented how much more performant Go is when I said it was up for debate, well, that example wasn't really in your favor.

This section highlights Rust's compelling advantages through concrete examples of successful implementations by major tech companies. It emphasizes the tangible benefits in performance and reliability that Rust brings to critical systems and everyday developer tools.

The Day-to-Day Experience of Writing Rust [7:20]

• The daily experience of writing Rust involves a syntax that looks familiar but with underlying complexities like generic constraints and ownership/borrowing rules verified at compile time by the borrow checker.
• Learning Rust involves a significant initial challenge of "fighting the borrow checker," where seemingly reasonable code is rejected by the compiler.
• An example given is creating a vector, getting a reference to an element, and then trying to modify the vector, which the compiler disallows due to the active reference.
• Developers need to learn about ownership and how it works to understand these compiler rejections.
• The learning curve is steep, and many developers report taking 3 to 6 months to become comfortable with the borrow checker.
• The tooling, particularly Cargo, is excellent and "just works."
• However, Cargo is very opinionated, unlike more flexible build systems like Gradle.
• Cargo's error messages are praised for being helpful and guiding users toward solutions.
• Compilation times can be slow, with even small projects taking 15-20 seconds, which can disrupt workflows, especially for those used to hot reloading.

But here's the thing is most people say that it takes 3 to 6 months just to get comfortable with the borrow checker. That's a significant investment of time.

This segment focuses on the practical aspects of coding in Rust, detailing the initial challenges related to the borrow checker and the concepts of ownership and borrowing. It acknowledges the steep learning curve but also praises the excellent tooling and helpful error messages, while noting the drawback of slow compilation times.

Challenges and Reasons for Not Adopting Rust [10:07]

• Despite Rust's advantages, not everyone is using it due to its demanding learning curve, which requires a mindset shift towards explicit ownership, borrowing, and lifetimes.
• This is a different mental model compared to garbage-collected languages.
• Some junior developers excel with Rust quickly, while senior engineers may struggle for weeks or months, indicating it's about compatibility with Rust's thinking rather than overall experience.
• The 3 to 6 month onboarding time means immediate productivity cannot be expected, creating bottlenecks.
• Integrating Rust into existing systems with significant investments in Java, .NET, or C++ can be challenging and costly.
• Rust has a complexity of concepts (ownership, borrowing, lifetimes, traits, generics, macros, async await) that, while individually sensible, collectively contribute to the steep learning curve.
• This can lead to "concept fatigue" similar to "framework fatigue" in JavaScript.
• The TypeScript team chose to port to Go instead of Rust because their goal was to use the lowest-level language possible for timely shipping.
• Porting TypeScript to Rust would have taken many years, whereas Go took about a year.
• Attempts to port TypeScript to Rust involved dropping into unsafe code or writing custom garbage collection strategies.
• Rust excels at its design goals but porting from Java is not one of them.

But simply put, if they wanted to port TypeScript to Rust, it would have taken them many years, whereas porting it to go took them about a year or so.

This part addresses why Rust, despite its merits, isn't universally adopted. It highlights the significant learning curve, the need for a specific mental model, onboarding challenges, integration difficulties with existing codebases, and the complexity of its feature set as key barriers. It also uses the TypeScript team's decision to use Go as a prime example of why Rust isn't always the best fit.

When to Use Rust and When Not To [13:17]

• Rust is excellent for performance-critical systems, security-sensitive applications, and long-running services.
• It may not be suitable for rapid prototyping, teams with tight deadlines, or projects requiring extensive legacy integration.
• The ecosystem is mature for systems programming and CLI tools but less so for GUI development and machine learning.
• Adoption is not uniform, and the choice of language depends on specific needs: Go is preferred for speed to market, and C++ for game development due to its ecosystem.
• Rust is a genuinely impressive technology that solves real problems at scale, with real performance numbers and measurable safety benefits.
• However, technology is not a zero-sum game; different problems require different solutions, and organizational context is more important than technical benchmarks.
• The question is not whether everyone should use Rust, but rather what problems are being solved and what the tradeoffs are for each language.
• Rust is not entirely hype; it's worthy of the attention it receives, but not everything needs to be rewritten in Rust.
• Rust is establishing strategic positions where its unique combination of performance, safety, and reliability provides clear business value.

But technology isn't a zero sum game. Different problems need different solutions and organizational context matters more than technical benchmarks.

This concluding section summarizes the appropriate use cases for Rust, emphasizing its strengths in performance-critical and security-focused domains while acknowledging its limitations in rapid development and certain ecosystem areas. It advocates for a pragmatic approach, considering specific project needs and organizational context over blindly following trends.