4 ms·

This feels very shortsighted to me. "Easy to learn" and "easy to hire for" are an advantage in the first few weeks. Besides, we now have data indicating that r

This feels very shortsighted to me. "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")

incrudible 2y ago
> 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. 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 2y ago
  > There are many languages that fit this description 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.
  - jpc0 2y ago
    Memory safety isn't a defining feature of rust in any way and with very very simple rules in C++ (no raw loops and not raw pointer access) you can actually just get rid of memory issues in C++. There are also pretty easy solutions to indexing issues (reading past the end of a array for instance) which you can use at compile time or just by enabling a compiler flag to have that at least hard crash instead of memory corruption. That takes a lot of RCE vulns to simply DOS vulns which is a significant increase in "security". Memory safety isn't the reason to use Rust. That's already available in well written C++, and many other languages. Doing it easily with a large group of people I would say is an argument for using rust. But then you need to argue why not swift or java or kotlin or golang a or any of the crop of languages coming out that also offers easy to code memory safety.
    - dureuill 2y ago
      > no raw loops and not raw pointer access - Do these rules allow iterators? - Under the "no raw pointer" rule, how do you express view objects? For instance, is `std::string_view` forbidden under your rules? If no, then you cannot get rid of memory issues in C++. If yes, then that's a fair bit more than "no raw pointer access", and then how do you take a slice of a string? deep copy? shared_ptr? Both of these solutions are bad for performance, they mean a lot of copies or having all objects reference-counted (which invites atomic increment/decrements overhead, cycles, etc). Compare to the `&str` that Rust affords you. - What about multithreading? Is that forbidden as well? If it is allowed, what are the simple rules to avoid memory issues such as data races? > That's already available in well written C++ Where are the projects in well-written C++ that don't have memory-safety CVEs?
      - jpc0 2y ago
        You are actually just arguing for the sake of arguing here. Rust bases all their data structures on pointers just like C++ does, just because you cannot look behind the curtian doesn't mean they aren't there with the same issues. Use the abstractions within the rules and you won't get issues, use compiler flags and analyzers on CI and you don't even need to remember the rules. And of the billions of lines of code are you really going to try to argue you won't find a single project without a memory safety CVE? You will likely find more than there are rust projects in total, or are we going to shift the goalposts and say they have to be popular, then define popular and prove you won't have a memory safety issue in a similarly sized Rust project. Shift the goalposts again and say "in safe rust" but then why can I not say "in safe C++" and define safe C++ in whatever way I want since the "safe" implementation of rust is defined by the Rust compiler and not a standard or specification and can change from version to version. I've agreed already that Rust has decent use cases and if you fall into them then and want to use Rust then use Rust. That doesn't mean rust is the only option or even the best one by some measure of best.
jpc0 2y ago
> 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 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 2y ago
  > As someone who has some large projects in C++ and co tribute to OSS C++ projects I find this isn't true. 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_bergstrom_google_director_of/ https://www.reddit.com/r/rust/comments/1bpwmud/media_lars_be...

incrudible 2y ago

> 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. 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 2y ago
> There are many languages that fit this description 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.
- jpc0 2y ago
  Memory safety isn't a defining feature of rust in any way and with very very simple rules in C++ (no raw loops and not raw pointer access) you can actually just get rid of memory issues in C++. There are also pretty easy solutions to indexing issues (reading past the end of a array for instance) which you can use at compile time or just by enabling a compiler flag to have that at least hard crash instead of memory corruption. That takes a lot of RCE vulns to simply DOS vulns which is a significant increase in "security". Memory safety isn't the reason to use Rust. That's already available in well written C++, and many other languages. Doing it easily with a large group of people I would say is an argument for using rust. But then you need to argue why not swift or java or kotlin or golang a or any of the crop of languages coming out that also offers easy to code memory safety.
  - dureuill 2y ago
    > no raw loops and not raw pointer access - Do these rules allow iterators? - Under the "no raw pointer" rule, how do you express view objects? For instance, is `std::string_view` forbidden under your rules? If no, then you cannot get rid of memory issues in C++. If yes, then that's a fair bit more than "no raw pointer access", and then how do you take a slice of a string? deep copy? shared_ptr? Both of these solutions are bad for performance, they mean a lot of copies or having all objects reference-counted (which invites atomic increment/decrements overhead, cycles, etc). Compare to the `&str` that Rust affords you. - What about multithreading? Is that forbidden as well? If it is allowed, what are the simple rules to avoid memory issues such as data races? > That's already available in well written C++ Where are the projects in well-written C++ that don't have memory-safety CVEs?
    - jpc0 2y ago
      You are actually just arguing for the sake of arguing here. Rust bases all their data structures on pointers just like C++ does, just because you cannot look behind the curtian doesn't mean they aren't there with the same issues. Use the abstractions within the rules and you won't get issues, use compiler flags and analyzers on CI and you don't even need to remember the rules. And of the billions of lines of code are you really going to try to argue you won't find a single project without a memory safety CVE? You will likely find more than there are rust projects in total, or are we going to shift the goalposts and say they have to be popular, then define popular and prove you won't have a memory safety issue in a similarly sized Rust project. Shift the goalposts again and say "in safe rust" but then why can I not say "in safe C++" and define safe C++ in whatever way I want since the "safe" implementation of rust is defined by the Rust compiler and not a standard or specification and can change from version to version. I've agreed already that Rust has decent use cases and if you fall into them then and want to use Rust then use Rust. That doesn't mean rust is the only option or even the best one by some measure of best.

jpc0 2y ago

> 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 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 2y ago
> As someone who has some large projects in C++ and co tribute to OSS C++ projects I find this isn't true. 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_bergstrom_google_director_of/ https://www.reddit.com/r/rust/comments/1bpwmud/media_lars_be...