5 ms·

> I didn’t want to talk about Go because it’s simply not what I was passionate about. I also didn’t want to put down Go users in the company. I just wanted to e

> I didn’t want to talk about Go because it’s simply not what I was passionate about. I also didn’t want to put down Go users in the company. I just wanted to extol the benefits of Rust and see if anyone was interested in trying it out. > Yet, it made me sad to look up articles on the language just to, in effect, bash it. I’m not generally in the business of discouraging people from coding, regardless of what their favorite programming language was. While this level of self reflection shows a lot of maturity, if your judgement is clouded by excitement and you're searching for evidence to support your plan, this is _exactly the wrong_ time to attempt to shift your organization's direction. You're on tilt. Worse, others are likely to recognize that you're on tilt, and discount otherwise rational arguments that you're making. It won't be clear to you why you're not making progress. I've introduced Rust to an organization for a specific project, and it wasn't a decision taken lightly. It fit the problem domain well. I'll likely advocate against Rust for the next greenfield project that's on the horizon - as it's not nearly as much of a fit. These are tools and there is no silver bullet. This doesn't apply (as other commenters have said) to quitting and getting a job elsewhere that already uses Rust. Indulge in your passion without engaging in a sisyphean battle that'll burn you out and harm the business.

fakedang 4y ago
As a sort-of-dev-outsider in a firm that's slowly moving into Rust, I would like to know what kinds of projects is Rust suitable for, and the reasons why you might advocate against it.
- code_biologist 4y ago
  In the absence of Rust, would C or C++ be top contenders for a given project? Then Rust might be a good fit. If the contender language is Go, think carefully before using Rust. If the contender language is Python, think very carefully before using Rust.
  - fakedang 4y ago
    Lol, that's pretty much the heuristic I have been going by. Rust to replace C++ and Julia to potentially replace Python as it matures.
    - MaulingMonkey 4y ago
      This was roughly my own intention, although I've ended up going all in on Rust and using it even for that which it isn't particularly suited for. Web frontend dev? Stay in JS-land instead of distracting yourself with a WASM sideshow like I do (unless you really need the clientside perf.) Throwaway scripts? Creating a cargo package is a bit overkill, although I do so anyways. The standard APIs can be a little less ergonomic, but that's nothing wrappers can't help with. Rust does an excellent job of providing fairly comprehensive opt-out safety, compared to C++'s hodgepodge of incomplete, edge case laden, compiler and tool specific, opt-in static analysis and annotations. Even a C++ skeptic like myself can learn a lot about how terrible the language is, by trying to write the same code in Rust and learning exactly why the borrow checker is complaining. But it's also a very front-loaded knowledge bomb, with a nasty learning curve. It took me a good month or two to stop fighting the borrow checker and embrace clones and RefCells. Perhaps a less painful learning curve than debugging C++ gone wrong, but certainly more painful than a lot of other non-systems languages - I doubt it'd make a good 1st programming language. Arrogance means you'll shoot yourself in the foot with `unsafe { ... }` escape hatches as well, and end up debugging memory issues anyways. Web and gamedev ecosystems are still weak for my tastes, although improving. I want a nice existing successful fun game to contribute to, that's written in Rust, so I don't have to find the motivation to RIIR an existing one or write my own. Also little point in statically proving to the compiler that your code is totally fine and safe if your bugs are already shallow through testing. I feel little desire to rewrite a typical C# codebase in Rust - what the borrow checker can catch, so too can proper unit tests, for the most part. Maybe invest in some code coverage analysis for CI instead. Unless those GC pauses are actually causing problems... or you have enough data races from missing mutexes in your multithreading code...
  - yangcheng 4y ago
    Dropbox did rewrite their python codebase with rust. Not sure if that considered as a contender
    - pclmulqdq 4y ago
      Dropbox's use of python was a very weird choice. At the time, other distributed filesystems were written in C++. It makes a lot of sense to move to rust.
- nindalf 4y ago
  I think Rust shines anywhere performance and correctness are critical. Some examples - infra projects. - Resource constrained environment (depends on the hardware) - Command line program - WebAssembly for a complicated webapp (like Figma) - Anywhere security is a concern Whereas a web service that reads from a database and supports some CRUD operations? Many languages specialise in this problem. If the business domain is complicated and needs a good type system to express that domain - yeah maybe Rust is a good fit. But you're probably better off with Python or Ruby or Go. I could revisit this opinion in a couple of years if the Rust ergonomics initiatives succeed. Video games - it's very early days for Rust. There's a lot of ongoing work (like Bevy) that could bear fruit in a couple of years but C++ is much better today.
- 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.

fakedang 4y ago

As a sort-of-dev-outsider in a firm that's slowly moving into Rust, I would like to know what kinds of projects is Rust suitable for, and the reasons why you might advocate against it.

code_biologist 4y ago
In the absence of Rust, would C or C++ be top contenders for a given project? Then Rust might be a good fit. If the contender language is Go, think carefully before using Rust. If the contender language is Python, think very carefully before using Rust.
- fakedang 4y ago
  Lol, that's pretty much the heuristic I have been going by. Rust to replace C++ and Julia to potentially replace Python as it matures.
  - MaulingMonkey 4y ago
    This was roughly my own intention, although I've ended up going all in on Rust and using it even for that which it isn't particularly suited for. Web frontend dev? Stay in JS-land instead of distracting yourself with a WASM sideshow like I do (unless you really need the clientside perf.) Throwaway scripts? Creating a cargo package is a bit overkill, although I do so anyways. The standard APIs can be a little less ergonomic, but that's nothing wrappers can't help with. Rust does an excellent job of providing fairly comprehensive opt-out safety, compared to C++'s hodgepodge of incomplete, edge case laden, compiler and tool specific, opt-in static analysis and annotations. Even a C++ skeptic like myself can learn a lot about how terrible the language is, by trying to write the same code in Rust and learning exactly why the borrow checker is complaining. But it's also a very front-loaded knowledge bomb, with a nasty learning curve. It took me a good month or two to stop fighting the borrow checker and embrace clones and RefCells. Perhaps a less painful learning curve than debugging C++ gone wrong, but certainly more painful than a lot of other non-systems languages - I doubt it'd make a good 1st programming language. Arrogance means you'll shoot yourself in the foot with `unsafe { ... }` escape hatches as well, and end up debugging memory issues anyways. Web and gamedev ecosystems are still weak for my tastes, although improving. I want a nice existing successful fun game to contribute to, that's written in Rust, so I don't have to find the motivation to RIIR an existing one or write my own. Also little point in statically proving to the compiler that your code is totally fine and safe if your bugs are already shallow through testing. I feel little desire to rewrite a typical C# codebase in Rust - what the borrow checker can catch, so too can proper unit tests, for the most part. Maybe invest in some code coverage analysis for CI instead. Unless those GC pauses are actually causing problems... or you have enough data races from missing mutexes in your multithreading code...
- yangcheng 4y ago
  Dropbox did rewrite their python codebase with rust. Not sure if that considered as a contender
  - pclmulqdq 4y ago
    Dropbox's use of python was a very weird choice. At the time, other distributed filesystems were written in C++. It makes a lot of sense to move to rust.
nindalf 4y ago
I think Rust shines anywhere performance and correctness are critical. Some examples - infra projects. - Resource constrained environment (depends on the hardware) - Command line program - WebAssembly for a complicated webapp (like Figma) - Anywhere security is a concern Whereas a web service that reads from a database and supports some CRUD operations? Many languages specialise in this problem. If the business domain is complicated and needs a good type system to express that domain - yeah maybe Rust is a good fit. But you're probably better off with Python or Ruby or Go. I could revisit this opinion in a couple of years if the Rust ergonomics initiatives succeed. Video games - it's very early days for Rust. There's a lot of ongoing work (like Bevy) that could bear fruit in a couple of years but C++ is much better today.
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.