to be rather unreadable. My solution is to not write it that way.
My observation is that code style is very important to Ruby and Python developers and less important to those from C-family backgrounds. That is, a lot of Ruby developers, for example, refuse to touch anything containing braces whereas few C-family developers require them.
I think the solution is that developers with a Python/Ruby background need to create a systems language, instead of expecting those with different backgrounds to be converted to the Python/Ruby-ists mindset. But in reality it seems that few Python/Ruby developers are all that interested in systems languages whereas those with C-family backgrounds are very interested (hence the situation that presently exists).
Fork Rust and change only the syntax, just to make it use whitespace for blocks. PL experts see syntax as secondary because it is something that can arbitrarily change. Take Racket for example. They built into the language the ability to plug in arbitrary syntaxes and still use the same language tools and API. I got tired of () when I was learning Racket and wrote an alternate syntax that used whitespace indentation and converted to 100% compatible s-exp Racket code.
So, you can have a whitespace-based version of Rust easily.
The practical problem is that then you'd split the community between the two syntaxes since you couldn't copy-paste code examples from one syntax into the other. That could be problematic for building a large base of support. Take D for example where they had fragmentation problems with two standard libraries. Perhaps a split based on syntax would be less? (Since code written in one could be shared with the other.) But it would still cause problems in how the language is marketed to new developers.
My observation is that code style is very important to Ruby and Python developers and less important to those from C-family backgrounds. That is, a lot of Ruby developers, for example, refuse to touch anything containing braces whereas few C-family developers require them.
I think the solution is that developers with a Python/Ruby background need to create a systems language, instead of expecting those with different backgrounds to be converted to the Python/Ruby-ists mindset. But in reality it seems that few Python/Ruby developers are all that interested in systems languages whereas those with C-family backgrounds are very interested (hence the situation that presently exists).