I don't see Python vs. Ruby specifically as worse-is-better versus better-is-better though. If anything, Ruby is a worse-is-better Smalltalk, while Python gained a lot of its initial community from its perception as a better-is-better Perl (based on popular articles by ESR, etc. at the time). Dynamic features like automatic pluralization of tables in Rails isn't "better is better"—it's just highly dynamic (or "magic"), and many people think of magic as a worse-is-better thing to do (for example, many functional programmers would consider any sort of reflection to be a worse-is-better feature, since it breaks parametricity and so forth).
I also don't think it's right to think of Rust as a better-is-better language in philosophy. Many folks coming from languages like Haskell find Rust full of design choices that seem at odds with its "functional programming" reputation: lack of higher-kinded type parameters, for example, lack of an IO monad (or the use of the term "monad" at all), a willingness to have subtyping in the language, heavy use of macros, etc. etc. The reason is that we actually have a heavy bias toward pragmatism and simplicity wherever possible.
It's our constraints that required the language to have the concepts that it does (performance-competitive with C++; no global garbage collection; data-race free; runtimeless/embeddable). We simply couldn't have copied another language and said "here's our language, now let's write a browser engine in it". It would not have the performance characteristics or the safety characteristics we need. It's not a difference in philosophy so much as in requirements.
I think the point may be that once you embrace those constraints, there's nowhere to go but a language with a fair bit of complexity. While Go chose simply to not embrace those constraints, and tell developers "You don't actually need C++ performance, and you really want a GC, and you should ditch Python entirely instead of trying to embed Go in it." Perhaps this is why Go found that their userbase didn't actually consist of the expected C++ developers and instead ended up being mostly ex-Pythonistas who are willing to ditch Python entirely for better performance.
FWIW, I'm glad that Rust didn't choose that path, as I've tried Go out and found that it really didn't work for me as a Python substitute, and am now dreading the day when I (hopefully) will have to rewrite parts of my startup in C++ for performance. I'm actually seriously considering Rust as a substitute here, but would like to see more stability in the core language before investing serious time learning it.
But I'm also someone who has never shied away from complexity in a language before, which probably puts me more in the "likes C++, Ruby, and D" camp even though I chose Python as my main scripting language. One of my main concerns with Rust is whether it will be possible to hire & manage developers who can work effectively in it, since I know that not everyone is as willing to learn new languages and language features as I am.
I actually think it will be easier to find folks willing to dive into Rust than folks willing to dive into C++. The reduction in complexity, corner cases, and memory safety have all allowed many developers with a background in dynamic languages to feel comfortable approaching Rust.
I would actually consider Rust's philosophy to be 'better is better', at least within the core ideas: no nullable values, borrow checking, trait oriented work. Although, perhaps, that was how it started and not how it's being released?
> The reason is that we actually have a heavy bias toward pragmatism and simplicity wherever possible.
And functional programming languages are just arbitrarily complex and obtuse because it hates its users? No, it simply has different constraints, like the following...
> It's our constraints that required the language to have the concepts that it does
And it's Haskell's constraints that lead to it having to be a pure language, and so on. Rust is just opinionated in a different way, and because of different constraints. Do you want functional programming in Rust? - it's probably not going to be as accommodating in that regard as a functional language. Do you want to have zero-cost abstractions in Haskell? - the language is not made with that in mind, so you will probably have to wrestle a lot with extensions and custom abstractions in order to achieve that, if it is even possible.
I also don't think it's right to think of Rust as a better-is-better language in philosophy. Many folks coming from languages like Haskell find Rust full of design choices that seem at odds with its "functional programming" reputation: lack of higher-kinded type parameters, for example, lack of an IO monad (or the use of the term "monad" at all), a willingness to have subtyping in the language, heavy use of macros, etc. etc. The reason is that we actually have a heavy bias toward pragmatism and simplicity wherever possible.
It's our constraints that required the language to have the concepts that it does (performance-competitive with C++; no global garbage collection; data-race free; runtimeless/embeddable). We simply couldn't have copied another language and said "here's our language, now let's write a browser engine in it". It would not have the performance characteristics or the safety characteristics we need. It's not a difference in philosophy so much as in requirements.