Hacker News new | past | comments | ask | show | jobs | submit login

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code base where ownership is encapsulated inside smart pointers. I think Rust is great and would have a lot more attention and adoption if version 1.0 would ship in 2009. I think Rust is too late into the game. That's why probably only mozilla is really using it and dropbox for really small part of their infrastructure from known players. From what i researched big part of "friends" that use Rust in production are using it because of hype? I am not sure exactly why but some of their use cases for sure not need systems programming language. Maybe it will not end up like D which tried to solve similar problem.

EDIT: It's funny how people down vote my personal feelings about the language without any anti-argument or comment. It seems having other opinion than "Rust is GREAT" is not desirable here.




Probably getting downvoted because the assertion that modern C++ solves memory leaks is getting kind of tired as far as Rust discussions go, and is also missing the point.

Rust doesn't solve memory leaks, it solves memory unsafety- things like use-after-free and iterator invalidation that modern C++ does virtually nothing to help with, and that vulnerability statistics show are still huge problems with programs written in C++.


I wrote something on the memory leak vs. memory unsafety confusion a while ago, for those interested in exploring it more: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...


I don't see usage of new/free without encapsulation, this is not modern c++ which invalidates your point. Using naked new/free is depreciated in modern c++ and is problem of C not modern C++. What kind of statistics? Can you give any links that support what you wrote? All memory leaks/buffer overflows that i saw lately are associated with C (openssl, libc etc) not with C++. For iterator invalidation there are couple of simple rules to remember or for example you can use std::insert_iterator that will not be invalidated even if relocation occurs. You could use static analyzer and would avoid most of the problems.

EDIT: My point is that i have nothing to gain from rust when knowing c++ and memory management rules + i got good static analyzer. But probably for someone that do not know C++ at all Rust could be a better choice.


Sticking the free in a destructor doesn't help you at all with memory safety, it just makes it easier to avoid leaks.

Simple rules are, again according to the evidence, not good enough. There are simple rules you can follow in C as well. The benefit of Rust (as far as memory safety goes) is that the compiler enforces those rules.

In fact, the mechanism by which it does this (lifetimes) is typically what makes Rust seem more complicated to beginners. But the fact is, that complication is still there in C and C++, the compiler just lets you deal with it all on your own.


Yes i understand what your point is. I do not need to know/remember certain rules because compiler is doing this for me in Rust, my point is that if someone knows those rules in C++ and have good static analyzer he can get similar safety.

I will try third time with Rust, i just feel sometimes like in shackles in Rust, i would like to say to compiler hey i know what i am doing, like i can do in C++.


> my point is that if someone knows those rules in C++ and have good static analyzer he can get similar safety.

No. The entire history of large-scale security-critical applications in C++ disagrees with you.

> I will try third time with Rust, i just feel sometimes like in shackles in Rust, i would like to say to compiler hey i know what i am doing, like i can do in C++.

That's precisely what unsafe is for.


Once again show me something that proves what you wrote, where is your history of modern C++ that proves that? No one provided any link.


Here's Mozilla Firefox, search for "use-after-free", "memory safety hazard".

https://www.mozilla.org/en-US/security/known-vulnerabilities...

Here's Google Chrome, search for "buffer overflow", "Use after free", "out-of-bounds":

http://googlechromereleases.blogspot.com/search/label/Stable...

Edit: Chromium bug tracker talks to me now, query for "use-after-free" has 2157 results:

https://bugs.chromium.org/p/chromium/issues/list?can=1&q=typ...


Once again, show me ONLY modern c++ code base. Those are mixed with old C++ code base.

Still waiting.

And read how chromium use C++11... (https://chromium-cpp.appspot.com/) + google style guide that is prehistory and NOT considered good in community.

Maybe try with proxygen, rocksdb, folly from facebook ?


> Once again, show me ONLY modern c++ code base. Those are mixed with old C++ code base.

These security flaws are in code that has used smart pointers for years and years.

> And read how chromium use C++11... (https://chromium-cpp.appspot.com/) + google style guide that is prehistory and NOT considered good in community.

It doesn't matter from a security perspective. In fact, I think C++11 is actually less safe than C++03 with custom smart pointers, because use-after-move is a hazard and lambdas make it very easy to have dangling references.

Chromium security engineers are some of the most competent engineers in their field. If using more C++11 features made their code more secure, they would do so. They don't, because C++11 doesn't make their code more secure.

Ultimately, these debates are really premised on something absurd: "assume modern C++ is completely memory safe unless proved otherwise". This is completely backwards and leads to endless "no true Scotsman" games. You need to show why C++ is supposedly memory safe. You won't be able to, because C++ is not.

> Maybe try with proxygen, rocksdb, folly from facebook ?

Those codebases aren't being attacked the same way browsers are.

But I can easily find use-after-free in them too with Google: http://code.metager.de/source/history/facebook/folly/folly/i...


Indeed you have found ONE, Good job.. I didn't say modern c++ is memory safe, did I? I've said couple of times that someone can use modern c++ with good static analyzer in safe way if his application is properly designed.

Tell me then if it's such a huge problem that rust solves ( that people have with memory safety) why whole world didn't switched to Rust for NEW projects? It's stable already.


> What kind of statistics? Can you give any links that support what you wrote?

Why yes, I can!

https://bugzilla.mozilla.org/buglist.cgi?o5=substring&o13=su...

Before you object, this is largely modern C++.

> You could use static analyzer and would avoid most of the problems.

> EDIT: My point is that i have nothing to gain from rust when knowing c++ and memory management rules + i got good static analyzer. But probably for someone that do not know C++ at all Rust could be a better choice.

Yes, you do. Empirically, programmers consistently make the same game-over mistakes in C++ over and over again.


Every large code base in history of the world has bugs, doesn't matter which language. What you provided proves nothing. I don't know what kind of "programmers" you are talking about maybe some from mozilla (they are known for making same shitty mistakes over and over again, i will not mention exploits over the years in firefox, breach into unfixed bug/exploit internal system etc.) but i know programmers that can write good C++ without making any memory problems and Rust has nothing to offer for them. You are just biased.


Of course every large code base has bugs, that's why we should be very concerned about what the consequences of such bugs are for users.

Please see my reply in the other sub-thread about very similar story of exploitable memory safety bugs in Google Chrome fixed in every release; do you want to continue your line of argument with a claim that Chromium developers are all incompetent too?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: