Having more than one way of doing things is good when it's a consequence of a positive, well-curated language evolution. I think that's Rust case. It doesn't me

Having more than one way of doing things is good when it's a consequence of a positive, well-curated language evolution. I think that's Rust case. It doesn't mean that it will become more readable ("beauty"?) in the future, there's a lot of line noise already: <'a>, foo::bar, #[define(...)], etc. Or, ehem, JS. I think the JavaScript -> ES6,7,8,9 evolution is a good example of positive change: the language improved immensely at the cost of having even more idioms, TIMTOWTDI and transpilers like TS. The old parts are now marked as bad practice and optionally linted to hell. You still have to put up with W3schools-level code once in a awhile though. Perl and C++ to me would be some bad examples. TIMTOWTDI hampered their evolution way too much. Perl froze for 10 years+. Python was much braver: their folks evolved (from 2 to 3) by breaking compatibility in order to remain true to its Zen. Zig and Go are examples of rigidity, one-way-only extreme, which is a pain sometimes but, in Zig's case, maybe a good practice for a young language project. Readability in Zig is excellent and I like the choices with the @ functions ie. @as or @ptrToInt() instead of piling-up parens and asterisks. Definitely a case-study of readability and evolution for the future to come.