kzhukov

Well, for some people loading an arbitrary binary code without possibility to check what's inside it is a critical security issue as well.

That were just the examples when Rust is not really suitable as a drop-in replacement for C/C++. Of course, if your platform is well-supported by Rust compiler and you don't have to write safety critical applications, then using Rust is just a matter of choice.

I don't argue whether it's good or bad language. It's a quite interesting one with its own pros and cons. If it fits you, then it's great, but you should know its limitations.

> safety-critical applications

Nope, Rust is also not suitable for these tasks since it doesn't have a certified toolchain (e.g. ISO26262 for automotive or DO-178 for aerospace).

> embedded

Current LLVM-based compiler lacks support for some platforms (e.g. Xtensa for some ESP32 MCUs).

Security is not a feature of the language or tool. Neither Rust nor C++ are fully secured even though the former could find more memory safety problems at compile time (but not all of them).

Security is the process. It contains continuous risk assessment, penetration testing, fuzzing and using various other tools throughout the product development to eliminate attack vectors. Only then you could build a secured product. Just rewriting everything in Rust won't make it.

What I don't really like in cargo is its' overcentralized and author-centric approach. What if some of your dependencies relies on the crate, which author doesn't support anymore and doesn't even accept patches? You will basically have to maintain a fork either with a different name (because you can't push it to crates.io) or have a patched version which you also can't push and have to manually update every Cargo.toml of every dependency in your project to use your fork. And what if you have not only one Rust project in your complex system? You will have to update or vendor everything. This is a real maintenance hell.

While in C/C++ I can just build a fork as dynamic library and put it to the system image or to the own package manager repo.

I mean for sure Cargo is great for small hobby projects, but for the big complicated enterprise projects it's not really suitable. Even Google doesn't use Cargo in Fuchsia and vendors everything.

There are fields such as automotive and aerospace where absence of Rust's standard is a showstopper for using Rust. Those areas require that all tools that are being used to build software must be certified (ISO 26262 for automotive for example) to ensure that software is safe to use and doesn't kill anybody. And nobody would do that for a language that adds new features every 6 weeks, because such certification is a long expensive process which you have repeat every time when the tool changes.

It's not possible for open source project to do such certifications by themselves. In C/C++ world there are companies that implement certified compilers. Usually, these are pretty shitty compilers that implement only previous standards like C++14.

And here is the problem for Rust. If there is no standard for the language and library, how such companies could implement an alternative compiler? Current Rust editions is not an option because they feel like a bottom line and don't answer the question to what extent the compiler has to be implemented to be called "compliant with Rust 2015".

And those fields aren't small. Usually hundreds of million lines of C/C++ power modern vehicle.

I find it's pretty funny that language, which positions itself as safe replacement for C/C++, can't be used in safety critical applications.