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

Some notes on Rust

lambda-the-ultimate.org

Post reply on HN
Print view View original

21–30 of 113 posts

Re: Some notes on Rust

#21

Post by hendzen »

pjmlp wrote: post #16
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

Only if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

The issue holding most serious projects back is MSVC's historic lack of support for C++11 (and now 14/17) features. Thankfully, it looks like this is starting to change with MSVC 15 [0].

As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks.

[0] - http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...

Re: Some notes on Rust

#22

Post by JoshTriplett »

Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

> What? C++11/14 solves these issues.

Sure, it solves some of those problems if you use exclusively smart pointers and vectors, and never use the built-in language pointers and arrays. What forces you to do so, when '*' and "new" and [] are right there?

Rust pushes you towards the right solution by requiring an "unsafe" block if you use raw pointers or arrays. That doesn't prevent you from using them (such as in the implementations of higher-level constructs or FFI calls), but it does hint that they're the wrong solution for everyday programming.

Re: Some notes on Rust

#23

Post by azakai »

unfamiliar wrote: post #9
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

Care to elaborate? I don't see how it does.

Yes, in particular, iterator invalidation (problem 2 in that list) seems unsolvable in C++, as far as I can see.

I've hit iterator invalidation in a new c++11 codebase. Perhaps c++14 offers something to help it that I'm not aware of?

edit: "unsolvable" in the sense of the language making it impossible,

Re: Some notes on Rust

#24

Post by [deleted] »

scott_s wrote: post #20
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

No; modern C++ provides the tools for which disciplined use solves these issues. The problem is that one can silently subvert that discipline, and still introduce memory errors. Rust enforces memory safety at the language level. C++ itself does not "know" about memory safety. This difference, to me, is huge. You can still opt out of memory safety in Rust through unsafe regions, but the fact that Rust provides memory…

[deleted]

Re: Some notes on Rust

#25

Post by Q6T46nT668w6i3m »

pjmlp wrote: post #19
Q6T46nT668w6i3m wrote: post #17

Earlier quoted context omitted.

> I like C++, but I don't see the opportunity where to use C++14 outside hobby projects. Sure, but I’ve encountered some notable exceptions: LLVM projects (C++11), Playstation 4 games (C++11/14), QT5 (C++11) projects, et al.

None of those are the typical corporation code that most of us are exposed to.

Maybe? I was addressing your “I don’t see the opportunity where to use C++14 outside hobby projects.”

Compilers, games, and operating system components are archetypical systems software.

Re: Some notes on Rust

#26

Post by Q6T46nT668w6i3m »

azakai wrote: post #23
unfamiliar wrote: post #9

Earlier quoted context omitted.

Care to elaborate? I don't see how it does.

Yes, in particular, iterator invalidation (problem 2 in that list) seems unsolvable in C++, as far as I can see. I've hit iterator invalidation in a new c++11 codebase. Perhaps c++14 offers something to help it that I'm not aware of? edit: "unsolvable" in the sense of the language making it impossible,

Yeah. It isn’t enforced, but it’s easier to mitigate.

Re: Some notes on Rust

#27

Post by burntsushi »

falcolas wrote: post #11
gcv wrote: post #4

Rust's error handling looks like the Maybe monad. That seems pretty reasonable in Haskell. I'm a little surprised by the criticism in the article — is the author saying there isn't enough syntactic sugar?

My experience mirrors the author's: it results in a lot of use of macros and case statements. These create a fair bit of cognitive overhead to discern what the program flow will end up being, and special syntax for unpacking values. The broad use of case statements leads to one more odd problem - knowing when, and when not, to use a `;`. Explicit returns are frowned upon, they prefer the "results from the last expres…

Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this:

    fn foo() -> bool {
        true
    }
is preferred over

    fn foo() -> bool {
        return true
    }
But that's more of a style issue.

As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

Re: Some notes on Rust

#28

Post by zerr »

hendzen wrote: post #21
pjmlp wrote: post #16

Earlier quoted context omitted.

Only if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

The issue holding most serious projects back is MSVC's historic lack of support for C++11 (and now 14/17) features. Thankfully, it looks like this is starting to change with MSVC 15 [0]. As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks. [0] - http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...

May I ask you where do you work?

Re: Some notes on Rust

#30

Post by zanny »

pcwalton wrote: post #10
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

> What? C++11/14 solves these issues. You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data. I would also argue that Rust is a better s…

My simplification of matters is that while C++ can now do everything right, it still easily lets you do everything wrong.

Rust compels correctness, so for any project where you can't trust your coworkers aptitude towards correctness (and that is to say you even trust your own) Rust is an insane productivity booster. We could have avoided millions of hours of work and thousands of zero day and system destroying bugs if we had OS cores written in a language like Rust.

Post reply on HN