Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Rust, as a core language, has a lot more concepts to grok compared to Go or even Java.
As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and Go is an order of magnitude better there than Rust. That said, despite the recent 1.0, the language is also heavily worked upon in several aspects (internals etc) and it doesn't seem that it's a "complete" offering that just happens to do incremental improvements, but a "we got an 1.0 out of the door, but we've got work to do to make it more mature".
> Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages.
Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the space Rust is playing in (and which those other languages are not playing in) is complex.
> As for incomplete, I mostly refered to the tooling and the available library ecosystem.
I've never found Rust lacking in tooling, with the notable exception of the lack of rustfmt (which is being worked on by Nick Cameron and others). I use native profilers and GDB with Rust almost every day, and Cargo is getting pretty mature. The library ecosystem isn't very mature yet, sure, but I wouldn't say that makes the language incomplete.
Rust is certainly harder to pick up than Go (and possibly Java), but I don't think that makes it any more complex than, say, C++.
The difference is in the learning curve. The concepts Rust forces down your throat are the same ones you'd need to learn in some way in C++ anyway (well, not the same concepts, but similar ones having to do with avoiding segfaults). The difference is that you can write simple programs in C++ whilst blissfully unaware of the perils that come later. On the other hand you sometimes need to understand ownership for even the simplest programs.
But for a larger application, you have the same amount of learning required if you want to responsibly write an app in C++ or in Rust.
When we're talking about using a language for something other than teaching programming newbies, we really don't care about small prime number programs being harder in Rust. We care about how hard it is to write large applications, and I strongly suspect Rust isn't harder than C++ for this.
Oh, by the way, for the most part lifetimes work themselves out[1] without effort from your side. And if you find them complicated, you can always compose the relevant wrapper object (like Rc for refcounted memory management -- almost a GC) and use it. It's a bit more verbose, but it's not hard to grok.
> the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages.
Except you have to solve those very same problems on your own with every other type of resource that is not called "memory" in other languages.
Ownership is a huge problem, having built in primitives to handle it is a benefit. Having or not having GC is almost (but not quite!) a separate discussion.
As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and Go is an order of magnitude better there than Rust. That said, despite the recent 1.0, the language is also heavily worked upon in several aspects (internals etc) and it doesn't seem that it's a "complete" offering that just happens to do incremental improvements, but a "we got an 1.0 out of the door, but we've got work to do to make it more mature".