(no title)
dureuill | 1 year ago
"Easy to learn" and "easy to hire for" are an advantage in the first few weeks. Besides, we now have data indicating that ramp up time in Rust is not longer than in other languages.
On the other hand, serving millions of users with a language that isn't even v1 doesn't seem very reasonable. The advantages of a language that is memory safe in practice and also heavily favors correctness in general boosts productivity tenfold in the long term.
I'm speaking from experience, I switched from C++ to Rust professionally and I'm still not over how more productive and "lovable" the language in general is. A language like zig isn't bringing much to the table in comparison (in particular with the user-hurting decisions around "all warnings are errors, period")
jpc0|1 year ago
As someone who has some large projects in C++ and co tribute to OSS C++ projects I find this isn't true. The big "productivity" boost I saw when using rust for some projects was that there were good rust wrappers for common libraries or they were rewritten in rust.
In C++ using the C API directly is "good enough" but because there is no nice wrapper development is slower than it should be and writing the wrapper would be significantly slower unless you expect it to be a decades long project.
When I'm not needing to build my own abstractions above a C library in C++ I find it just as productive as rust and the moment I need to touch a C library in Rust I feel even less productive than C++.
There is definitely an argument to be made about correctness in large teams being beneficial in the long run but clearly very large projects are able to keep some sanity around keeping developers in check but this is the one metric where rust has a leg up on C++ and big backers of C++ agree that it's the place C++ is sorely lacking. Every other metric isn't worth discussing unless this is fixed.
dureuill|1 year ago
Well, that goes contrary to my personal experience (professional dev in C++11 and up for a decade), and also to the data recently shared by Google[1] ("Rust teams are twice as productive as C++ teams"). Either your Rust is slower than average, or your C++ is faster than average. Perhaps both.
The reasons for being more productive are easy to understand. Build system and easiness to tap into the ecosystem are good reasons, but tend to diminish as the project matures. However, the comparative lack of boilerplate (compare specializing std to add a hash implementation in C++, and deriving it in Rust, rule of five, header maintenance and so on), proper sum types (let's don't talk about std::variant :(), exhaustive pattern matching, exhaustive destructuring and restructuring makes for much easier maintenance, so much that I think it tends to an order of magnitude more productivity as the project matures. On the ecosystem side, the easy access to an ecosystem wide serialization framework is also very useful. The absence of UB makes for simpler reviews.
[1]: https://www.reddit.com/r/rust/comments/1bpwmud/media_lars_be...
incrudible|1 year ago
Does it though? There are many languages that fit this description, you would choose Rust if for some reason you also need good performance. However, if you heavily interop with C/C++ safety goes out the window anyway, and it probably never mattered much in the first place.
dureuill|1 year ago
I find that in practice not, especially if you further limit that to imperative languages. Note that I mentioned memory safe AND heavily favors correctness. In that regard, Rust is uniquely placed due to its shared XOR mutable paradigm. One has to look at functional languages that completely disable mutation to find comparable tools for correctness. Allegedly, they're more niche.
> However, if you heavily interop with C/C++ safety goes out the window anyway
I find this to be incorrect. The way you would do this is by (re)writing modules of the application in Rust. Firefox did that for its parallel CSS rendering engine. I did it for the software at my previous job. The software at my current job relies on a C database, we didn't have a memory safety issue in years (never had one since I joined, actually). We have abstracted talking to the DB with a mostly safe wrapper (there are some unsafe functions, but most of them are safe), the very big majority of our code is safe Rust.
> it probably never mattered much in the first place
It does matter. First, for security reasons. Second, because debugging memory issues is not fun and a waste of time when alternatives that fix this class of errors exist.