> And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now.
Sorry. In hindsight, and out of the context like this,
i think i picked up harsher words than i should. I dont meant to be disrespectful to all the great
and valuable work that is going on the Rust community.
> There is not a single large-scale network-facing widely attacked piece of software I'm aware of in C++ that has not fallen to some memory safety problem. Memory safety issues frequently produce RCE.
Sure, Rust will be better at this. No doubt. But lets not forget that a lang like C++ needed to evolve while still working, so how much of those security issues are there given the use of ancient code practices of the past? software coded in the 90's even the 80's. I guess we at least should wait for when Rust has millions of tools, and billions of line of codes running in production, to see what sort of issues might plague Rust code the most. But Rust will need to get there first. So lets not forget that its a language created in the 70's and that is responsible for great tool, and is still being used to build big project, with millions of LOC and with many devs working in groups in some very sophisticated
pieces of software, and this is no small feat.
What i meant to say, earlier, that maybe is not so clear, is the choice is not as unidimensional, by just cherry picking one point of view
when you need to decide what kind of tech, fits the best for a given scenario. Im trying to point out
that other languages like C++ or even C, still can be good bets, when you look into more vectors
of influence, not only in the security aspect, or what language have more FP idioms in it. In the real life, is not as easy
as some Rust evangelists imply it is.
C++ its not as good as Rust in the security aspect, theres no doubt about it, but the modern C++ is fine when you sum the vectors of what language will fit the best for a given scenario. I mean, you can be explicit about ownership, and make the api clear about ownership and lifetime. Of course Rust choose to be more pedantic about it. But as a C++ dev i have no issues with lifetime or owership management just by using smart pointers, std::move, etc.. (even in a multi-threaded environment)
But i dont think is as easy, as the Rust community is implying, that is to "just use Rust"
for a project, where C++ may also be a good fit.
Even for new, clean room projects, i think C++ may be a better fit for certain scenarios,
and im glad that theres also Rust as a choice. But i think sometimes this zealot type of evangelism
sometimes more based in spreading fear, than by selling Rust for its own virtues, can hurt more than
it looks like.
I guess by now, Rust doesnt even need to be compared to anything else, thanks to great hackers like you
its already showing its own virtues. Im just trying to say that by now it probably reached a peak
of users that can use the language in more low-level scenarios, and it probably should aim to get more
of the Ruby, Python, PHP, NodeJS crowd, to fill its army.
Because from now on it would be harsher for Rust to get more adoption, without a big ecosystem backing it up (Like Swift has with Apple, Java with Android and C and C++ has with Unix)