# Two Years With Rust

DevFeed: [Two Years With Rust](<https://devfeed.tech/articles/two-years-with-rust-12493.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2020/03/22/rust.html>)

Author: Marc Brooker

Published: 2020-03-22T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Memory Safety](<https://devfeed.tech/topics/memory-safety.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Go](<https://devfeed.tech/topics/go.md>), [Firecracker](<https://devfeed.tech/topics/firecracker.md>)

## AI overview

A developer reflects on two years of using Rust for security-sensitive, performance-focused systems work. The article compares Rust with Go, C, and C++, emphasizing Rust's suitability for command-line tools, high-performance services, and system-level code.

## Source excerpt

Two Years With Rust I like it. I hope it's going to be big. It's been just over two years since I started learning Rust. Since then, I've used it heavily at my day job, including work in the Firecracker code base, and a number of other projects. Rust is a great fit for the systems-level work I've been doing over the last few years: often performance- and density-sensitive, always security-sensitive. I find the type system, object life cycle, and threading model both well-suited to this kind of work and fairly intuitive. Like most people, I still fight with the compiler from time-to-time, but we mostly get on now. Rust has also mostly replaced Go as my go-to language for writing small performance-sensitive programs, like the numerical simulators I use a lot. Go replaced C in that role for me, and joined R and Python as my day-to-day go-to tools. I've found that I still spend more time writing a Rust program than I do Go, and more than C (except where C is held back by a lack of sane data structures and string handling). I've also found that programs seem more likely to work on their first run, but haven't made any effort to quantify that. Over my career, I've done for-pay work in C, C++, Java, Python, Ruby, Go, Rust, Scheme, Basic, Perl, Bash, TLA+, Delphi, Matlab, ARM and x86 assembly, and R (probably forgetting a few). There's likely some of my code in each of those languages still running somewhere. I've also learned a bunch of other languages, because it's something I enjoy doing. Recently, for example, I've been loving playing with Frink. I don't tend to be highly opinionated about languages. However, in some cases I steer colleagues and teams away from particular choices. C and C++, for example, seem to be difficult and expensive to use in a way that avoids dangerous memory-safety bugs, and users need to be willing to invest deeply in their code if these bugs matter to them. It's possible to write great safe C, but the path there requires a challenging blend of