I always say that purely in terms of design my ideal language is high-level Haskell, low-level C. Conceptually, purely functional design is how programming "should" (note the quotes) be, but doing so down to the level of functions is both not very practical (some algorithms are just easier to express in terms pointers moving around rather than folds, reduces and the like), and makes it hard to reason about performance (especially memory, and most especially if you throw laziness in the mix).
But then again, I write my own stuff in python because I'm a lazy fuck, so probably it's not meant to be :(
That's similar to what I used to say. I was devastated to see the BitC project implode, but then Rust appeared and took up the mantle. It's not perfect by any means but it's influential enough to drag the whole field of PL development kicking and screaming in that general direction.
In spite of all the retarded monkeys in its fanbase, I always thought it was an interesting project. Popular languages today are much more similar than they used to be, they are basically "converging", Rust's willingness to try something new must be applauded.
Still many pain points, still a bit of a "puzzle language", too much of a scatterbrain approach in the governance and design direction, but even if it had no other influence than to force people to think about the problems of low-level programming, that would be still a massive plus in my book.
The reason why Haskell and other popular FP languages all require a GC.
But functional programming is fully supported and lack of GC is not an issue, since you can use Rc<> and Arc<> where needed. (Support for 'pluggable' tracing Gc<> will probably be added at some point, but it will need local allocators, which are not a stable feature yet.)