4 ms·
> But please, I am more then happy if you show me, I am wrong, what is so cool in Rust, that you can't pull with c++? Anything that is possible in one Turing-c
by chc 9y ago
> But please, I am more then happy if you show me, I am wrong, what is so cool in Rust, that you can't pull with c++?
Anything that is possible in one Turing-complete language is possible in another Turing-complete language, so this question isn't framed in a way that's readily answerable.
A better question is what the language actively enables and what it prevents rather than just what you can and can't do in it. Rust makes guarantees that C++ doesn't. Unexpected nulls are possible by default in C++; they are impossible by default in Rust. Use-after-free bugs are possible by default in C++; they are impossible by default in Rust. Buffer overflows are possible by default in C++; they are impossible by default in Rust. Data races are possible by default in C++; they are impossible by default in Rust.
Is it possible to write C++ code that doesn't have these problems? Sure, lots of examples exist. But C++ leaves the door open for these things in a way that Rust doesn't. You have to actively avoid them.
> And if you can't give a reasonable answer, why inventing a new language? Rather write it as a new conding standard. Or create new stl with your new paradigm.
A coding standard is just a set of suggestions, and lacks the guarantees and sane defaults a language can offer. A new STL is a just a library. Basically, you're comparing compiler guarantees with human effort. Surely you can see why guarantees have value.
- _o_ 9y agoBut let me return to the basics, what prevents you from coding like this (with preventing the "horrible" nulls by #define NULL CNull) in C++? I can see another language emerging which is giving the value (if I understood you correctly) by giving you less flexibility (for the value of beeing type safe, which is perfectly acomplishable in c++ too - it reminds me of java and destructors, where they used a bunch of workarounds, coz "we don't need destructors, we have garbage colector") while on the other hand same thing can be accomplished with the existing language having huge platform support not to mention that the new language is using it to actually even exist. doesn't it make it a better choice to create librust (or even rust*.hpp) instead of creating something completely new? (again downvoted by 4 :D :D What a coincidence :D :D guys, you are seriously having a problem :D :D :D)
- chc 9y agoWhat prevents us from coding like this in C++? As far as I can tell, human fallibility. C++ has been around for decades and we still keep running into the same bugs over and over. That is my point — "What can I do in this language?" is the wrong question. Anything that is possible in C++ is also possible in C, or even in assembly. But you can see why you'd use C++ over those. That's the Blub paradox — you can see how Blub's facilities are an improvement over less powerful languages even though they can write functionally equivalent programs, but when you look at more powerful languages, you find yourself thinking, "Why couldn't you just write that in Blub?" (Also, I'm not sure what #define NULL CNull does, but I'm pretty sure it doesn't enable static checking of pointer nullability.)
- DougBTX 9y ago> (again downvoted by 4 :D :D What a coincidence :D :D guys, you are seriously having a problem :D :D :D) Minus four is the minimum points, it doesn’t indicate exactly how many downvotes a comment has. My guess is to discourage people from attempting to get the “most negative” number of points for a post. https://github.com/minimaxir/hacker-news-undocumented/blob/master/README.md https://github.com/minimaxir/hacker-news-undocumented/blob/m...