More browser code being written in a language with fewer footguns is always cause for celebration
My experience in both (10+ years for C and C++ at this point, 3+ for Rust) is the exact opposite; I can't remember the last time a C or C++ build system, test framework, documentation engine made me one tenth as happy and satisfied as `cargo` does.
To be more than a FUD, you should specify which Linux distribution and which architecture. Yes, it was bad in Rust's early days, but not anymore. I speak this as someone who worked to improve Rust support in Linux distributions and across architectures.
It is fair to say Swift support in Linux distributions is spotty, as Swift is not packaged in Debian at all, and Swift upstream is developed against its own LLVM fork, which distributions are reluctant to package. I don't think it is fair to say the same to Rust. Rust upstream takes care to support LLVM releases, precisely so that it is easier to package by Linux distributions.
Ah yes, Linux is the only OS in the world. How could I forget that?
I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.
[0]: https://bevyengine.org/learn/book/getting-started/setup/#ena...
Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions).
There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
The same can be said about c++.
On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times.
> So overall I would say it's definitely a factor, but not necessarily a showstopper.
I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
By your logic, Python is king over Go since Python doesn’t need to compile at all.
It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
I do think the quick iteration tapers off though the larger the code base gets due to the points I mentioned.
That is after all what this link is telling us. One of the main points made was "speed up development"
If it were solely about compile times that wouldn't be a major reason to use Rust here.
I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable.
Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice.
The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories.
Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not
And then even Rust is not a guarantee that an application has no vulnerabilities, as memory isn’t everything.
So please use rust if it make sense, but please also don’t force it upon every possible c++ software projects.
Obliviously if you can use Rust, it's even better but that's not always the case.