C/++ faggots say that their language could have done Rust's safety features, so why didn't they?
Why did they allow years of shit and unsafe and bugged code to happen and force a company like Mozilla to come up with a not-retarded systems programming language?
Also before some cunt screams SJW, explain to me how a language being SJW affects what I can write with it?
>>58450650
>>58450684
Not so fast, retard. That implies you can't write fast code in Rust but you can in c++. But that's bullshit.
>>58450714
Nothing so dramatic. What I was implying was that with C++ you can get hurt. Hence, adrenaline and a reason to improve.
>>58450714
>implying minibikes aren't fast
>>58450684
Does something like on the left actually exist? It doesn't seem to make sense...
>>58450650
>C/++ faggots say that their language could have done Rust's safety features, so why didn't they?
Who told you that ?
C was designed as a basic close-to-the-metal procedural language, I don't think safety was the main concern of Ritchie and Thompson.
C++ is a monster with plenty of features added on top of C basically, and, maybe it could have added some of Rust's safety features, but...what exactly ?
I don't know much things about Rust, but to ease memory management in C++, you have references, as well as unique_ptr and shared_ptr. I don't think they can get away null pointers though since it's a core component of C.
You can also use static analyzers and valgrind to have an equivalent of some of the Rust compiler features, I've heard.
>Why did they allow years of shit and unsafe and bugged code to happen and force a company like Mozilla to come up with a not-retarded systems programming language?
Because of its C roots and the fact that it's an older thing than the vast majority of the people browsing this board (myself included). That's my guess.
Btw, I've heard that Rust really shines for complex programs with a lot of memory management, but isn't necessarily better for some areas were it's still slower than C and C++, like audio processing.
And Rust can't compete to the C/C++ ecosystem of libraries and tools yet.
>>58450952
>it could have added
A language standard can't add features to itself, sorry about that.
>>58450952
>yet
Key word right there
Also there's Corrode, a C->Rust converter, which should make those libraries appear much faster than writing shit from scratch.
>>58451057
Corrode converts code to Rust as it is. I doubt it'll be very useful.
>>58451076
That's exactly what makes it useful
>>58450650
Nobody cared enough?
Rust is a solution to a problem that most people aren't actively trying to solve. And by its nature it can only be slower and more difficult to implement than C, so it's already failed for embedded. It might eventually displace C++ though.
>>58451138
Tell that to the Openssl devs
>>58451090
Why? It's far from idomatic Rust with unnecessary muts and unsafe blocks.
>>58451138
It's not necessarily slower than C. No reason it can't be as fast. Rust doesn't add hidden costs.
I'm not a big C++ guy but idiomatic Rust is probably faster than "idiomatic" C++. It discourages dynamic dispatch and encourages the use of union types with its enums.
>>58451230
>Rust doesn't add hidden costs.
what is runtime array bounds checking
>>58451289
That is added if it CAN happen. Besides accessing arrays with indices is usually not the idiomatic way of doing things.
It SHOULD check it when it can't prove it's safe instead of going into undefined behavior like in C/C++. It's fixing your code for you.
I work at a company that works with embedded linux and we use C 99% of the time. People got burned before so now they add NULL and boundary checks even when it's not needed because "just in case". Rust doesn't have this headache.
>>58451289
>what is bounds-checking elimination
>what are iterators