Do you have reasons why it's going too far, or is that just an emotional reaction? Consider that these pointer types map exactly to the pointer-type templates provide by C++11: unique_ptr, shared_ptr and weak_ptr: http://en.cppreference.com/w/cpp/memory
In the interest of starting discussion and not just stating facts, I will take the position that I think Rust's adoption of these concepts into the language is a Good Idea. Many pointer-based codes have these pointer types, but they are enforced through convention alone. C++11's templates are a step in the right direction, as they make explicit what convention assumes, but the compiler does not know about them. Yes, because they are template classes, there are certain things one can and cannot do with, say, a unique_ptr, but the compiler cannot do any analysis on the usage, because the concept has no representation in the language semantics. (Ben references a blog post by Niko Matsakis about some of the analysis Rust does: http://smallcultfollowing.com/babysteps/blog/2012/07/19/yet-...)
I agree they're good to put into the language semantics, but as a side point on C++11, couldn't the compiler actually assume a bunch of things about those templates, since their behavior is specified? GCC, at least, assumes many things about even C stdlib functions, because it "knows" what they do, so rather than treating them as just regular functions, it can make stronger assumptions about them when optimizing, and/or generate code to implement their functionality internally, rather than linking the library implementation.
You can, but the difficulty, I think, is that this clean separation of pointer types exists along with naked pointers, including void*. That is, C++11 still carries the legacy of C's free-for-all, so the kinds of guarantees that one could get from a C++ compiler - even with baked in knowledge of unique_ptr, shared_ptr and weak_ptr - are going to be limited.
A lot of the productivity gain in higher-level languages comes from not having to manage memory. Having three different incompatible, differently allocated pointer types to fool around with slows you down. The creators of Rust are hoping that the speedup from not having to do global garbage collection in most scenarios will balance out the loss of productivity.
Personally, I'm skeptical. Azul showed us that pauseless GC was possible, even for Java. Android and .NET showed us that even without pauseless GC, the performance of GC'ed languages was adequate to build attractive user interfaecs. A lot of Rust's design choices mean that it's not really suitable as a web development or scripting language, and those two communities have shown themselves the most receptive to new languages.
Mozilla has tried to rewrite their core product in a different language before. Look up "Javagator." It did not end well. But, who knows. Maybe this time really will be different.
It's not impossible to build attractive user interfaces with garbage collection, but it is significantly harder, both for users and developers of the system. Android system apps go to great effort to avoid using the GC during critical animations, while in iOS this is much easier. Implementing a good garbage collector is a lot of work, and it's very difficult to tune; even the JVM, which has had an enormous amount of man-hours put into it, struggles with GC pressure under some loads.
Additionally, the applications we want Rust to be suitable for aren't competing with GC'd languages. They are competing against applications written in C++, with manual memory management and no automatic storage reclamation. They will be put head-to-head in benchmarks with them. We don't take performance regressions, and relying on global GC would be a significant risk. The Javagator is, in fact, an excellent example here!
(As an aside, the pointer types are not all incompatible; all pointers can become &T, and the vast majority of functions take & pointers.)
It's a little misleading to say that GC makes "attractive user interfaces... significantly harder." For any business application, for example, using GC is a no-brainer. That's why I mentioned .NET in my response.
Android games have been known to struggle with GC sometimes. However, garbage collection has gotten a LOT better on Android over the years. I wrote a small game in Android 1.1, back when GC pauses were anywhere from 100ms-250ms, and avoiding allocations was VERY important. Nowadays, most pauses are less than 5 ms, and the NDK is always available if you want to write native code and avoid GC altogether.
In general, the game industry seems to be moving towards a model where you have "engines" and "level packs." The physics, graphics, etc. engines are developed by a small group of people in C or C++, and the level packs are in whatever scripty language you want.
The development of the web reflects a similar split. You have the C/C++ engine, and the HTML/CSS/ECMAScript content. C and C++ have low programmer productivity and a lot of odd quirks, but nobody cares because the bulk of the development has moved higher up the stack. So attempts to replace C or C++ get a "if it's not broke, don't fix it" type response.
This is one reason why golang, for example, has seen more users come in from the scripting and web development community than from the C++ community. C++ projects tend to be old, conservative projects that are at the bottom of some giant stack-- like Google's infrastructure, for example.
Rust has some interesting ideas. The typestate concept in particular is interesting. I also do kind of get what they're going for with the 3 different memory types. I guess we'll see how it all works out.
Some tasks - such as implementing kernels - are poorly suited for garbage collection. And while there do exist garbage collectors that can be used in hard real-time scenarios (http://queue.acm.org/detail.cfm?id=1217268), that's not the norm.
I think there will always be a place, at the lowest levels, for manual memory management. Providing abstractions to make that as safe and manageable as possible is a Good Thing.
Some tasks - such as implementing kernels - are poorly suited for garbage collection
Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications.
Of course there's a bunch of different definitions of "hard realtime" floating around, and rust would probably be suitable for some of them. I fully expect that someone will reply to this with something like, "Well MY definition of hard realtime is playing movies, and Rust is suitable for that." :) But when I think of hard realtime, I think of applications where you must have absolute determinism.
Let's not judge the intentions of the Golang authors by what the intentions of the C++ authors were.
Golang is a higher level language than C. It will not be suitable for non-GC'ed environments, and the Golang authors are perfectly well aware of that. It's ok to make a language that solves many problems really well, without trying to solve every problem in the world in one bloated language.
In the interest of starting discussion and not just stating facts, I will take the position that I think Rust's adoption of these concepts into the language is a Good Idea. Many pointer-based codes have these pointer types, but they are enforced through convention alone. C++11's templates are a step in the right direction, as they make explicit what convention assumes, but the compiler does not know about them. Yes, because they are template classes, there are certain things one can and cannot do with, say, a unique_ptr, but the compiler cannot do any analysis on the usage, because the concept has no representation in the language semantics. (Ben references a blog post by Niko Matsakis about some of the analysis Rust does: http://smallcultfollowing.com/babysteps/blog/2012/07/19/yet-...)