<p><pre><code>  &gt; I get the feeling that Rust design is concerned more about write-ability
  &gt; of the code than readability.
</code></pre>
We&#x27;re usually accused of the opposite: being explicit about things really helps in the long run. We&#x27;ve made several choices that we think, at least, helps &quot;in the large&quot; but hurts &quot;in the small&quot;. We can always be wrong, of course :)<p><pre><code>  &gt;  code comprehension (debugging, integration efforts, etc) by third parties will be hampered.
</code></pre>
In what way? I still don&#x27;t understand what you&#x27;re getting at here.<p><pre><code>  &gt; Not importing the entire library will result in faster compilation.
</code></pre>
Rust&#x27;s unit of compilation is a &quot;crate&quot;, which gets compiled at once. Metadata is then stored in the artifact (.rlib) so that you can know the interface, etc, and you don&#x27;t need to recompile the rlib when you change what aspects of the library you use. So I&#x27;m a _little_ bit unsure of the _exact_ details, but I think it&#x27;s the same as precompiled headers, to my knowledge.<p><pre><code>  &gt; where codebase took 12 hours to compile on a powerful cluster.
</code></pre>
Well, I&#x27;m sure we&#x27;ll get to really huge projects someday, but we tend to do the &quot;small packages&quot; philosophy, so an initial compile might take a while, but subsequent ones aren&#x27;t as bad. I just did a clean build of Servo, which is roughly 6MM LOC (575k Rust, 500k C, 1MM C++ (Spidermonkey, I&#x27;m guessing)),  and it took 16 minutes on the first (debug) build, and 3 minutes on the second, after touch-ing the main file. Lots of the initial time is building the 170 (!) dependencies, which then don&#x27;t need to be compiled again. (And your second build-times will be different based on which sub-package you&#x27;re building. Some are faster, some are slower.)<p>We also have a lot of compiler performance improvements coming down the pipeline, including incremental recompilation within a single crate.<p><pre><code>  &gt; Since both are supported, maybe the parser can be made smarter?
</code></pre>
It&#x27;s been debated, but it&#x27;s another edge case to remember. It&#x27;s not clear that adding another special rule to the language is worth saving four characters.<p><pre><code>  &gt;  Is not easily read or debugged ( on which line do you set the breakpoint, etc).
</code></pre>
I think it depends. I come from a functional background, so reading it feels fairly straightforward to me (though that for in a fold is a bit odd), and debugging should work as usual, though I don&#x27;t feel the need to use a debugger a whole lot in Rust.<p>Thanks for taking the time to reply. Skepticism is good! Constructive criticism is the only way things move forward.