5 ms·

As someone who uses a fair bit of Rust in production, here are my rules of thumb: - Rust is strongest where you need high performance, low latency, or low memo

by ekidd 4y ago

As someone who uses a fair bit of Rust in production, here are my rules of thumb: - Rust is strongest where you need high performance, low latency, or low memory usage. If you're spinning up 20 machines to run a single data-crunching job, or if you care about your 99th percentile tail latency, Rust is great. This is where Rust shines compared to GCed languages. - Rust also shines where programs need to transform large, complex data structures correctly. It's fantastic for anything resembling a compiler, even if the output isn't executable code. This is where Rust shines compared to languages without Rust's fancy "enum" and "match" (aka union types) and without Rust's strict null handling. - Rust is strongest for CLI tools and for microservices with a small API. - Rust is weakest for rapidly-changing business logic. This is because most companies have few Rust programmers, but they have many people familiar with scripting languages. In these circumstances, putting the business logic in a typed scripting language will make it accessible to more developers, and easier to change. - Rust's closest competitor is C++. Rust has better tooling out of the box, it's arguably easier to master, and it has many fewer ways to shoot yourself in the foot. But in many problem domains, including games and native desktop GUIs, C++ will have far more mature libraries. In my experience, the best way to introduce Rust to a company is to pick a project which is exceptionally well-suited to Rust's strengths, ask for permission to build a prototype in Rust, and do a really compelling job.

fakedang 4y ago
Thank you for the very comprehensive answer. You're right - the team sold me on the idea by starting out with a low-latency requirement use case for which most of our code base was written in C++. We are almost 50% through with replacing our code base from C++ to Rust. What I can really appreciate are the significant improvements in code execution due to the aforementioned reasons.
- ekidd 4y ago
  As someone with over a decade of professional C++ experience, here are some things your company might experience during this migration: - A dramatic reduction in runtime crashes, and a ~70% reduction in security vulnerabilities (based on Microsoft's analysis of security bugs, but also personal fuzz-testing experience). - Much better out-of-the-box tooling. You can set up cargo, VS Code and rust-analyzer in 5 minutes. "Maintaining the build system" will typically become a thing of the past. Rust also provides many verification features for free that would require setting up static analyzers for C++. - A much easier time integrating third-party libraries. But you may loose access to certain domain-specific libraries, depending on your problem domain. - Safer use of complex threading and/or async, if you need them for performance. Look at the Mozilla experience converting complex concurrent C++ modules to Rust. They've written a lot about it and it has almost always been a giant win. - Hiring is a tradeoff: Depending on where your company is located, you may have more local C++ programmers. But if you do remote hiring, the Rust talent pool can be fantastic. - It's easier to train people from scratch. Rust is not a small language, but it's a lot smaller than knowing the entire history of C++ gotchas and idioms. Also, Rust provides much better guardrails for novice Rust developers. It's feasible to take a strong junior developer, train 'em up, and turn 'em loose. A migration like the one you describe makes the most sense if 3 things are true: 1. Your C++ codebase is small enough to incrementally rewrite (and your team knows how to manage an incremental rewrite without too much loss of velocity). 2. Your problem domain does not rely on major C++ libraries with no Rust equivalents. 3. Your developers are enthusiastic about Rust. If any of those three factors were missing, however, then I would normally advise against a rewrite.
- synergy20 4y ago
  why is rust 'faster' then c++? I can understand it might be safer, but I think c++ never had a bad reputation for execution speed.
  - fakedang 4y ago
    I believe it has to do with garbage collection. C++ garbage collection is a bit of a mess (and that's an understatement although I won't disrespect the language). Rust doesn't use GC as a general measure - memory is freed as variables go out of scope. Also if you want to GC, it has the provision to do so.
ecshafer 4y ago
I've tried some game development in Rust (but not a professional game dev), and its really not a great language for it I think. The strengths of Rust of knowing that its correct are not great for games, which is basically just rapidly changing and refactoring constantly. I could see doing base level libraries in Rust, so you know they are memory safe, but I wouldn't want to develop a full game in it, even though games otherwise fit most of the other requirements rust does well.
drogus 4y ago
I think the business logic point would have some people disagreeing. I talked to a VP of Engineering of a company using Rust and Elixir and he said their heuristic of when to choose Rust is "will the requirements change a lot over time?". If they expect a lot of changes they would go with Rust, cause with all of the compile type checks refactorings are easier for them. They are in a web apps space, btw. I haven't worked on any bigger production projects in Rust, so how to say if it would be a common experience, but sounds interesting

by ekidd 4y ago

fakedang 4y ago

Thank you for the very comprehensive answer. You're right - the team sold me on the idea by starting out with a low-latency requirement use case for which most of our code base was written in C++. We are almost 50% through with replacing our code base from C++ to Rust. What I can really appreciate are the significant improvements in code execution due to the aforementioned reasons.

ekidd 4y ago
As someone with over a decade of professional C++ experience, here are some things your company might experience during this migration: - A dramatic reduction in runtime crashes, and a ~70% reduction in security vulnerabilities (based on Microsoft's analysis of security bugs, but also personal fuzz-testing experience). - Much better out-of-the-box tooling. You can set up cargo, VS Code and rust-analyzer in 5 minutes. "Maintaining the build system" will typically become a thing of the past. Rust also provides many verification features for free that would require setting up static analyzers for C++. - A much easier time integrating third-party libraries. But you may loose access to certain domain-specific libraries, depending on your problem domain. - Safer use of complex threading and/or async, if you need them for performance. Look at the Mozilla experience converting complex concurrent C++ modules to Rust. They've written a lot about it and it has almost always been a giant win. - Hiring is a tradeoff: Depending on where your company is located, you may have more local C++ programmers. But if you do remote hiring, the Rust talent pool can be fantastic. - It's easier to train people from scratch. Rust is not a small language, but it's a lot smaller than knowing the entire history of C++ gotchas and idioms. Also, Rust provides much better guardrails for novice Rust developers. It's feasible to take a strong junior developer, train 'em up, and turn 'em loose. A migration like the one you describe makes the most sense if 3 things are true: 1. Your C++ codebase is small enough to incrementally rewrite (and your team knows how to manage an incremental rewrite without too much loss of velocity). 2. Your problem domain does not rely on major C++ libraries with no Rust equivalents. 3. Your developers are enthusiastic about Rust. If any of those three factors were missing, however, then I would normally advise against a rewrite.
synergy20 4y ago
why is rust 'faster' then c++? I can understand it might be safer, but I think c++ never had a bad reputation for execution speed.
- fakedang 4y ago
  I believe it has to do with garbage collection. C++ garbage collection is a bit of a mess (and that's an understatement although I won't disrespect the language). Rust doesn't use GC as a general measure - memory is freed as variables go out of scope. Also if you want to GC, it has the provision to do so.

ecshafer 4y ago

I've tried some game development in Rust (but not a professional game dev), and its really not a great language for it I think. The strengths of Rust of knowing that its correct are not great for games, which is basically just rapidly changing and refactoring constantly. I could see doing base level libraries in Rust, so you know they are memory safe, but I wouldn't want to develop a full game in it, even though games otherwise fit most of the other requirements rust does well.

drogus 4y ago

I think the business logic point would have some people disagreeing. I talked to a VP of Engineering of a company using Rust and Elixir and he said their heuristic of when to choose Rust is "will the requirements change a lot over time?". If they expect a lot of changes they would go with Rust, cause with all of the compile type checks refactorings are easier for them. They are in a web apps space, btw. I haven't worked on any bigger production projects in Rust, so how to say if it would be a common experience, but sounds interesting