> 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.
What 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.)
> (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.
Ergonomic sum-types, ergonomic pattern matching, hygienic macros, the ability to track the lifetime of every object, generics that have nicer (can still get messy) error messages than templates, immutability-by-default, an insanely good package manager, builitin unit and integration testing, iterators that aren't terrible, easier cross-compilation, a smaller standard library surface so everyone on your team isn't using different corners of the language, and a wonderful zero-cost implementation of linear types are just what I can think of off the top of my head. Oh, and you have complete memory safety if you don't use unsafe, and much stronger guarantees of memory safety than C++ even if you do use unsafe. Adding all this to C++ is just adding noise to an immensely bloated system, and it wouldn't be half as good as a new language, for all the simplicity and compat-breaking reasons mentioned above.
Edit: And move and copy semantics that are unarguably better than those of C++.
> Naaah, I just don't tend to be politically correct
Which combined with your actual statements sounds to me like you're saying "I don't tend to care if what I'm saying strongly is wrong because I'm comfortable espousing my opinions as overly broad assertions of fact regardless of accuracy or counterarguments." That is, to put it bluntly, just a nice way of saying "I'm an asshole, and I'm okay with that." It's not a particularly useful way to interact with people if you expect to have a productive conversation. If you aren't hoping for a productive conversation, it makes a lot more sense though.
> As I said, the amount of Rust posts here is disaproppriate to the amount of languages that are available
Which implies all languages should get equal representation. Why would that be the case?
> Somehow it reminds me to the Cambridge Analytica case, a small amount of people (bots) manipulating the public opinion. :)
Or perhaps your opinion doesn't reflect the public norm much, or at least the HN norm, or even just the selection bias you see from the exclusion of people that immediately decided an article about Rust wasn't interesting to them, so they didn't visit. Good allusion to current scary topical event though.
> 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++?
Oh, now people are supposed to take on faith you have an open mind about this, and as long as you're shown something as you consider objectively "cool", you're happy to change your opinion? I'm not sure I'm convinced.
> 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. Or completely reinvent the types using a new library/headers. Why bother wasting time and reinventing what already works (profit? ;) ), and it works great (you can use it as an former VBA developer or as a guru, same language, different skill set, different features used).
All covered many times before on HN. Here's the simple answer: Every one of those changes means you have to learn a mostly new language while also being mostly incompatible with existing hardware, so why not just go farther and get some real guarantees out of the changes instead of just slightly better usability? Guess where that ends up...
Err, I meant incompatible with existing libraries (at least to the degree your interop is the same as any other language that needs interop and supports similar types, like Rust). Not sure where I pulled hardware from...
