TFA actually mentions

Not that hard in Rust either:

let badref: &u32 = unsafe { std::mem::transmute(0 as *const u32)};

But doing this trick is UB in both C++ and Rust, so it's not really fair to hold it against either language. Having said that, one advantage of Rust would be that it is impossible to create such a bad reference without using an unsafe block, while in C++ it seems much easier to do so by mistake.

But C++ does not allow references to references, arrays of references, and pointers to references. Rust has all these things, while still being able to ensure that the references are valid.

I ignored the AC because, well, AC. But you repeated the claim of 'a ton of bugs', so replying to you seemed worth it at the time.

Do those smart pointers also solve iterator invalidation? :)

The issue tracker in Rust is used not only for bugs in the compiler, but also for tracking the standard library, new features, enhancements, some infrastructure, documentation, lints, etc. Assuming that 1900 open issues means there are 1900 bugs is ridiculous. If you look at the labels used on the issues tracker, you'll find that the label I-crash has 19 open issues. Of course not all bugs will be labelled correctly, so no doubt there will be more defects, but hardly the number that the 'worried' anon suggests. Also note that the language has changed significantly over the years, until it reached the current design. To look at some of the older bugs and conclude that the current version of the language can't be very good is silly because the rust of two or three years ago might as well have been a completely different language. As for servo, looking again at the label I-crash, I see (at this time) 39 open issues, which sounds much more reasonable than 800.

> What will the performance penalties be to optimized C or C++ code? Some of the guarantees that the Rust type-system provides could theoretically allow better optimization than C/C++. For instance, when you have an immutable reference (&something)to a object of a type that does not have internal mutability (that means the vast majority), that object is guaranteed to be immutable for as long as your reference is alive (note that this guarantee is stronger than that offered by a const *). And when you have a mutable reference (&mut something) your pointer is guaranteed not to alias, so once again your object is immutable except for the changes that you choose to make. You could say that all &mut T references are T *restrict. In addition, references in Rust are guaranteed to be non-null. All this extra information offers opportunities for optimization. Note that (AFAIK) not all this information is being communicated to the LLVM back-end at this time. In short, I do not expect performance penalties.

You can do whatever you want with pointers (although the things that are UB in C will tend to be UB in Rust also), you just need to do so in an unsafe{ .. } block. The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.

High speed internet is a relatively new thing. I think it's safe to say that there was barely any online movie piracy twenty or thirty years ago. Were movie tickets $3 back then (or really $1.95 / $1.38, when we adjust for inflation)?

Sure, disable javascript. Alternatively, run Firefox + NoScript and distrust everything by default.

It's not really a useful general purpose computer that you can carry around unless the keyboard, mouse, required usb-hub, cables, and screen also fit in your pocket. Whenever you get to a location where all that stuff is present, then there is probably already a computer present (otherwise why would all that stuff be lying around?). Now compare with a good usb memory stick: you don't have to connect all those cables, and it has much more storage for the same price.

Here in the Netherlands the government isn't even in the capital... :-)

No, because it would take some time for the far galaxy to interact with the mid-way galaxy, and it would take some time for the mid-way galaxy to interact with our galaxy, and if we add those times we find that while we were waiting the mid-way galaxy has also moved out of our range.

The Rust language is intended to reach version 1.0 soon (either before the end of the year or early 2015), which comes with the promise of being backwards compatible. However the Rust standard library is still undergoing stabilization and parts of it may still change for a while. Right now a lot of work is being done in that area, to stabilize the most important bits.

Mozilla is also working on Servo, a research-project to develop a browser engine in Rust. The goal is to experiment with more parallelization in the browser, and Rust is supposed to help by making it easier to write correct multithreaded code. To do this Rust has a strong focus on ownership of data.

Rust can run without a runtime and the standard library is split up into several parts (which is not invisible to users of the standard library) that can be used separately when you choose to compile without the standard library. The advantage is that when you target, say, a platform that does not support dynamic memory allocation, you can still use the parts of the standard library that do not require allocation (liballoc). Or you can go without libc bindings. So it is relatively easy to run Rust on bare metal. You could write an operating system in Rust if you wanted to (and I think some people are trying to do just that, but I haven't heard from them for a while).

I very much doubt that is true. For instance, I think Rust can also make that claim.