Thread: Let's talk about Rust!

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

Originally Posted by kibwen

...without anyone actually bothering to look at Rust at all, or understanding the problems that it's attempting to solve.

You have mischaracterized the thread. Several posters have, in fact, explored Rust in a meaningful way, and don't see it as a meaningful improvement over existing languages. I agree with Soma here. You were both obviously "tipped off" to come to this thread, to shore up the failing arguments of the OP. I don't buy that you were just passing by, and happened to read a seven-page thread at random, only to wade in with your own "correction of misinformation." The point I made in my very first reply to this thread remains valid:

Originally Posted by Elkvis

The idea that this could replace a language that's been used to great success for more than 40 years seems a little far-fetched.

The barrier to entry in the systems programming language market is just too impenetrable, due to the entrenched tools we already have.

Just like generation-Y kids don't like to be advertised to, programmers generally don't like to be proselytized. We're (mostly) quite happy with the tools we have, despite, and in some cases, because of their idiosyncrasies.

Originally Posted by kibwen

C++11 has already begun evolving in this direction with unique_ptr and move semantics (which allow you to approximate linear types), and I have hopes that this evolution will continue once Rust proves how useful region analysis is.

unique_ptr, must be said, isn't new (pun aside). It evolved from old and well know patterns. You and I were managing unique and shared pointers in C++ with well established patterns long before Rust. unique_ptr and shared_ptr are simply answers the old problem of compile time checking. Rust must not feel the need to prove what we always knew.

Instead Rust design goal is to support these C++ idiomatic patterns while enforcing their safety. Contrary to C or C++, whose design goals will never be to enforce code safety.

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.

No offense was intended - I don't mean to denigrate C++ or troll - I just got linked here from elsewhere and thought I'd try to clear up some confusion in the thread.

O_o

You have no need to hedge an apology or anything. I simply found the timing suspicious. If you are different people, you are different people.

I can easily see multiple fans of Rust popping in after a post on the Rust "subreddit".

As long as you and other "redditors" keep your defense of Rust confined I see no problems.

[Edit]
Of course, the linked thread isn't doing you any favors. Many of the posts do nothing other than speculate about the posters here dismissing Rust due to ignorance.
[/Edit]

[Edit]
To be fair, many of the posters also clearly understand that the presentation was flawed, and that the onus is on Rust fans to present arguments.
[/Edit]

Soma

Poor Neo1: linked to the Rust home page in the introductory post, but still gets the comment that "No one linked the home page"... unless "No one" was a typo for "Neo1"

And I really like the answers from the reddit people who seem to have migrated here.

O_o

As far as that goes, so do I.

This kibwen seems to understand that the onus is on Rust fans to proselytize better.

Soma