Thread: Let's talk about Rust!

Program correctness is as much an afterthought in C as the correct use of the language is in English. The rules are there, the semantics, as is a whole generation of books educating programmers in the correct use of the language. Rust will offer the exact same challenges and will be crowded by the exact same insufferable programmers for whom program correctness is an afterthought.

Your problem with the C programming language, Neo, is one of false attribution. Direct your batteries to your fellow programmers instead, and you'll quickly realize we've been blessed not with one, or two, or three, but a large number of excellent application/system programming languages.

(Pepe annoyed me very much today. The Portuguese humiliating loss at the WC. Going to watch Ghana-USA now. Go Team Africa! Sorry fellow Americans.)

Originally Posted by Yarin

But in all seriousness, he already has.

Named some points, yes, which have been shot down already. Neo speaks as if these are absolute improvements, not just in his/her opinion. Therefore, I seek some of these "other improvements" that C++11 cannot imitate in any easy way that are significant enough to warrant attention.

Originally Posted by Yarin

That's a big deal, you can't imitate that in C++.

Not good enough. Nice to have, but ultimately, in big systems, I imagine it won't mean so much. While C++ cannot fully imitate this, it comes close enough.

Sweet it may be, but it is limited to where the compiler can prove it's wrong. If it cannot prove it is wrong, it is not going to give you a compile error. So it may be nice for newbies and small projects, but for larger ones, I hardly think it will matter.

Originally Posted by Elysia

Sweet it may be, but it is limited to where the compiler can prove it's wrong. If it cannot prove it is wrong, it is not going to give you a compile error. So it may be nice for newbies and small projects, but for larger ones, I hardly think it will matter.

Indeed.

The only way to be sure all possible leaks and dangling pointers are detected without running it is to do a complete static analysis of the program and any library functions or (exploit knowledge of) compiler built-ins the program uses, and verify that all possible program states are in valid ranges.

Whole-of-program static analysis is difficult - and the reason that programs which do comprehensive static analysis are often VERY expensive, are rarely used on small programs, and novices very rarely get to use them.

Even primitive forms of static analysis are quite time consuming, because of the number of dependencies of state that can arise between functions that call (or are called by) each other - and because a program that can accept inputs (from user, from files, from whatever) has many more possible states. There are ways and means of simplifying static analysis (for example, annotations of preconditions and post conditions of functions, so the analyser doesn't have to drill down and analyse the source of every called function) but it is hardly trivial.

Built-in reference-counted smart pointers can help, but they're hardly a panacea. They're also not the only available option - there is nothing stopping a compiler vendor building in knowledge of the standard library into a compiler (there are several compilers, for a range of languages including C and C++, which exploit knowledge of the standard library to improve diagnostics or to optimise performance).

It looks like there's some confusion in this thread regarding the features of Rust.

1. Rust does not have built-in reference-counting. Nor does it use garbage collection at all, or any other form of dynamic memory management.
2. Rust guarantees memory safety at compile time, without imposing any runtime overhead whatsoever (this blew my mind when I realized that such a thing was possible). It does this by restricting the ownership of data (think of everything as being automatically marked with `const restrict`, and the compiler guaranteeing that this is correct). It has move semantics by default, and requires explicit action if you want to clone something.
3. References in Rust are first-class, and you can safely store references in data structures. If you mess up, the compiler is guaranteed to yell at you. Here's a good talk discussing how this works: https://air.mozilla.org/guaranteeing...afety-in-rust/
4. Because of all the ownership tracking that the compiler does, Rust code is guaranteed to contain no data races. That's not to say that race conditions in general are impossible, just data races. This is a pretty great feature for multithreaded programs.
5. None of this static analysis is expensive.
6. Rust doesn't require a runtime, and Rust code can expose a C-compatible interface. This means that you can write a library in Rust that can be called from any language that can call into C.

So Rust is not a silver bullet. Even though the memory management is both perfectly safe and "free" in terms of performance, it requires thinking hard about ownership of data and thus is not "free" in terms of programmer productivity. It's only intended to replace C++ for security-critical applications (such as web browsers, which is why Mozilla is backing the project), though I'm sure other people will value not having to ever deal with segfaults/null pointer dereferences/use-after-free/dangling pointers/iterator invalidation/etc.

The reason why a new language is warranted here is because C++ can't guarantee memory safety without breaking backwards compatibility with all existing C++ code. C++11/14 are doing great jobs of evolving the language towards safety, but it's still only a shadow of what you can do with a language designed around safety from the ground up.

O_o

Two new posters registering within a few hours of each other making the same points in the same thread about a language that is neither C nor C++ on a board with C in the name?

Call me crazy, but I don't believe that is in any way kosher.

Soma

This is supposed to be a discussion, not an election or popularity contest, so sockpuppets do not matter as long as they are well behaved since it is a matter of the strength of points raised, not the number of votes cast. Given that the email addresses of AlisdairO and kibwen are separate (not say, easily manufactured gmail aliases), and the IP addresses recorded are different (means almost nothing, of course, but sockpuppet masters do make mistakes), I would give the benefit of the doubt that no one here was so desperate as to create new email accounts simply to try and add supportive voices to the discussion.

Originally Posted by AlisdairO

I just got linked here from elsewhere

Where might that be? A link might be good.