Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One year of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

91–100 of 110 posts

Re: One year of Rust

#91

Post by Rusky »

lossolo wrote: post #90
Rusky wrote: post #85

Earlier quoted context omitted.

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 writ…

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…

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.

Re: One year of Rust

#92

Post by lossolo »

Rusky wrote: post #91
lossolo wrote: post #90

Earlier quoted context omitted.

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…

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 se…

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++.

Re: One year of Rust

#93

Post by Manishearth »

Lewisham wrote: post #42
steveklabnik wrote: post #38

Earlier quoted context omitted.

If you (or anyone really) has specific thoughts here, that'd be super great. Rustdoc's output could use a lot of love, but we haven't figured out exactly what we want to do with it. And having worked with it daily for a few years now, I'm personally a bit blind to its shortcomings.

Specific thought: Trait implementation pages like http://static.rust-lang.org/doc/master/std/collections/hash_... should output the first paragraph of the documentation text. That way you can easily scan/Ctrl+F through the documentation that's right next to the struct you're interested in. Reduce the number of clicks and context switches. It's just a pretty terrifying way to output right now.

Made a PR: https://github.com/rust-lang/rust/pull/33679

Re: One year of Rust

#94

Post by pcwalton »

lossolo wrote: post #90
Rusky wrote: post #85

Earlier quoted context omitted.

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 writ…

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…

> 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.

Re: One year of Rust

#95

Post by pcwalton »

lossolo wrote: post #92
Rusky wrote: post #91

Earlier quoted context omitted.

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 se…

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.

Re: One year of Rust

#96

Post by russellbeattie »

steveklabnik wrote: post #6
grenoire wrote: post #2

One year since stable? It feels like five years for the level of maturity they have achieved.

Rust has been in development for almost a decade at this point; but the language changed significantly many times before 1.0. It's been one year since the 1.0 release, which is the language we know today as "Rust". All those older languages are dead and gone now. I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.

So maybe you know why it's called 'rust'? I can't find any reference to it. Such a horrible name for a new programming language.

Re: One year of Rust

#97

Post by lossolo »

pcwalton wrote: post #95
lossolo wrote: post #92

Earlier quoted context omitted.

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.

Re: One year of Rust

#98

Post by lossolo »

pcwalton wrote: post #94
lossolo wrote: post #90

Earlier quoted context omitted.

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…

> 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 probabl…

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.

Re: One year of Rust

#99

Post by the_why_of_y »

lossolo wrote: post #97
pcwalton wrote: post #95

Earlier quoted context omitted.

> 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...

Re: One year of Rust

#100

Post by the_why_of_y »

lossolo wrote: post #98
pcwalton wrote: post #94

Earlier quoted context omitted.

> 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 probabl…

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 wri…

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?

Post reply on HN