> But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad.
What? Why? I've been developing C++ for 10 years and seen firsthand the problems it causes and that are addressed by Rust. If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate.
About the rate, maybe that would be more expensive, but I'd say it's still worth it. Anyway, it's not like getting competent C++ developers is cheap either.
As for GP's message, I agree it looks unrealistic that "kid fresh out of college" would magically write performant code because they're writing rust. There is more to performance than the language, and it is particularly easy to write bad performance code in rust (and in C++ I must add). That being said, I'd still be less anxious to have a junior in a rust codebase than near a C++ one.
> If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate.
Maybe it's true for you, but I can hire a competent C++ programmer to deliver code faster for less than what you'd ask.
Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No.
> About the rate, maybe that would be more expensive, but I'd say it's still worth it.
> Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No.
I don't think the OP meant iterating on performance problems specifically, just generally iterating on code as one does when they write it.
Also, every programmer at some point iterates about performance problems, not matter their experience, or language (or implementation), or runtime that's being used.
I think the original "uni grad can write better Rust code than experience C++ dev can write C++" is a hyperbole. I don't think they meant better, but the Rust developer will need less context to implement the same feature.
The spirit of that sentence was probably "it's simpler to write performant and safe code in Rust than C++". But again, without really agreeing what "performance" means here, it's a bit silly to discuss.
Performance is such a complex that can mean so many things depending on the problem. So, I we're all nit-picking about something without even agreeing what they're specifically nit-picking about.
The default IO mode in C/C++ is buffered. Rust requires you to wrap it in `BufWriter`. For most network (or general IO, really) workloads you want buffered IO.
So sure: We could say that writing performant IO code in Rust is more difficult, if we hyper-focus on this one specific detail.
FWIW (and people who're unfamiliar with this): I think switching to buffered IO in Rust is absolutely trivial, and very well documented (in multiple places where it's relevant). In fact more so than it is to switch to unbuffered IO in C++, because you have to call `setbuf` with "special" values to disable buffering.
We can then argue that experience/wisdom diminishes most of these arguments about performance, but it diminishes them on both sides.
> I don't think the OP meant iterating on performance problems specifically, just generally iterating on code as one does when they write it. Also, every programmer at some point iterates about performance problems, not matter their experience, or language (or implementation), or runtime that's being used.
Exactly, on both accounts, thanks.
It strikes me as odd that GP would describe "iterating on performance" as "underperforming", unless GP is in a very specific domain where the performance requirements are always known in advance and where they never change. Getting the last drop of performance from code is a trade-off. It impacts the readability and maintainability of code. To get the last drop, it can depend on the shape of your expected input data, and it requires looking at the produced assembly and performance profiling results to find bottlenecks and act on them. This alone implies iteration. If you're telling me that your engineers know their compiler so well that they can tell in advance what assembly code will be generated when changing seemingly unrelated parts of the code, eg they know the inlining limits of their compiler, I call BS.
Iterating on performance takes time to develop and maintain, which is why it should be done just enough to meet the requirements, in particular in the hot loop and to reduce bottlenecks. If your developers are optimizing all the code they write to the ASM instruction, they are probably underperforming (unless specific domain where so little code is written or the target is so small that the benefit is worth the cost). Understanding that trade-off is part of seniority (aka juniors will often both "prematurely pessimize" by writing inefficient code without increasing maintenability or in the hot loop and "prematurely optimize" by avoiding allocation at all costs in CLI argument parsing).
I measured it. On multiple projects. Some I started writing in Rust, so this is not the "rewrite effect" at play. I observe x2 to x3 on development time alone, long term if we compound review, debugging and maintenance I wouldn't be surprised to see if it tends to an order of magnitude of difference.
Results will depend on the available ecosystem for each language for the task at hand. For instance I'd still choose C++ with qt for writing a GUI today.
The reasons why Rust is more productive are easy to understand and touch most of the development steps:
- building is trivial in Rust, adding dependencies also. Depending on how broken the CMake of your C++ dependency is, it can take several days to wrap it so it can be used sanely. The remaining time is dependency review, which must also be taken in C++.
- Development itself is much easier, thanks to Rust's expressive typesystem (mostly sum types and traits) and "functional-lite" iterators (C++ is getting there with ranges but today we're still far from the same ergonomy, we're still missing pattern matching, and views introduce lifetime issues). The sane error/warning demarcation allow to develop without the equivalent of "-WError" (which is hard to do sanely in C++ due to eg missing return being a warning), which allows to use these warnings to drive development (you can stub every function and when you no longer have any "unused variable/unused function" warning, you're done). More generally, Rust removes most of the boilerplate of C++: you don't need to maintain superfluous representations of your interface as headers (the documented interfaces are generated using cargo doc), you can derive `Hash` instead of opening the std namespace, functions and structs definition all start with a keyword so they're easy to grep for, the language being expression oriented means we don't have to rely on immediately invoked lambdas as soon as what we want is to bind a variable depending on an if, we don't have pure stupid boilerplate like the rule of five to enforce, and a thousand of other ergonomic improvements over C++. Rust feels like a language designed by a C++ developer tired of the flaws of C++.
- Since many errors are lifted at compile time, the feedback loop becomes much shorter. On the same library that has both a C++ and a Rust interface, we had memory errors several times due to a function that returns a view of its argument without that being clearly expressed or expected. In C++, this meant looking for what went wrong after a segfault, something that took an hour to two engineers. In Rust, the compiler told us that the particular variable was not living long enough, and went so far as to suggest the fix. Time spent on this: 10 seconds. And this comparison only hold for the memory errors that we did catch in C++...
- Test and documentation use standard tooling that is included by default. The ecosystem documentation is stored on a centralized website, meaning is a single place to look at to find documentation (that at least contains the interface of the library).
- Review is made easier with no implicit code paths due to implicit conversions or exceptions. Error handling has the right amount of noise, a single character to pass back the error (possibly adding some context), otherwise a match construct to handle each error case. The error story is not perfect, but much better than in C++. The "dangerous patterns" are made easy to spot (unsafe, unwrap, etc) and should be confined to specific parts of the code (eg hot loops where benchmarks prove that it is necessary). Rust make code review able to focus on the problem at hand rather than the many rules you have to follow to not blow your foot off in C++. In the presence of other developers (or even for myself :-)), it is really welcome.
- Maintenance time is reduced by all of the above, over time, compounded by the ease with which one can refactor Rust code compared to C++ code. If refactoring a module without unsafe there is no chance of introducing memory issues. Generally the strong type system (no implicit conversions) makes it easier to not accidentally introduce logic errors
Now, there are drawbacks to Rust: the ease of adding dependencies means that we can have deeper dependency tree, so this make reviewing dependencies a bit more tedious (thankfully code review is easier). Occasionally the borrow checker comes in and forbid some patterns (mostly when we would write code depending on iterators not being invalidated in C++), and having done less rust than C++ sometimes I need to find the correct pattern for something. On average though, the advantage is very clear.
Which is it? Barely a day ago, you said "If I start writing Rust..." Now you claim you have been writing Rust all along, on "multiple projects", keeping measurements. Forgive my skepticism.
Sorry for not being clear. Should have written "when I start writing Rust" at this point. I have been using Rust personally since 2016, and professionally since 2019. Most of our codebase is naturally still in C++ (we're not aiming at "rewriting the world"), so I can frequently feel the difference between the two languages, which is why my preference is so clear-cut.
What? Why? I've been developing C++ for 10 years and seen firsthand the problems it causes and that are addressed by Rust. If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate.
About the rate, maybe that would be more expensive, but I'd say it's still worth it. Anyway, it's not like getting competent C++ developers is cheap either.
As for GP's message, I agree it looks unrealistic that "kid fresh out of college" would magically write performant code because they're writing rust. There is more to performance than the language, and it is particularly easy to write bad performance code in rust (and in C++ I must add). That being said, I'd still be less anxious to have a junior in a rust codebase than near a C++ one.