Why Rust is not a mature programming language
Everyone is going to have a different definition of &quot;mature&quot;, and that&#x27;s fine :) Obviously lots of respect for Kostya. I do think that framing these as &quot;maturity&quot; is a good framing, that is, fundamentally, he&#x27;s right. A lot of this stuff has to do with Rust being so young, and in the future, it will be taken care of. I would argue that this is a significantly <i>higher</i> maturity requirement than most people actually need, and that Rust is more mature in other places and so may be for other people, but that&#x27;s a different thing.<p>My take on the state of these issues:<p>&gt; Rust does not have a formal language specification...  I understand that adding new features is more important than documenting them but this is lame.<p>Most languages do not. It also really depends on what you mean by &quot;formal.&quot;<p>It&#x27;s not about being more important, it&#x27;s that we value stability <i>very</i> strongly, and don&#x27;t have the ability to document things with the guarantees we&#x27;d prefer. You might call it... not mature enough yet :)<p>There&#x27;s been a bunch of movement here, I&#x27;m excited to see it continue to develop!<p>&gt; Function&#x2F;method calling convention. ...  I’m told that newer versions of the compiler handle it just fine but the question still stands<p>The objection here doesn&#x27;t have to do with calling conventions, actually, this is about &quot;two-phase borrowing,&quot; described in a series of blog posts ending here <a href="http:&#x2F;&#x2F;smallcultfollowing.com&#x2F;babysteps&#x2F;blog&#x2F;2017&#x2F;03&#x2F;01&#x2F;nested-method-calls-via-two-phase-borrowing&#x2F;" rel="nofollow">http:&#x2F;&#x2F;smallcultfollowing.com&#x2F;babysteps&#x2F;blog&#x2F;2017&#x2F;03&#x2F;01&#x2F;nest...</a><p>I believe this will get even better with polonius <a href="https:&#x2F;&#x2F;nikomatsakis.github.io&#x2F;rust-belt-rust-2019&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nikomatsakis.github.io&#x2F;rust-belt-rust-2019&#x2F;</a><p>Regarding argument evaluation order, technically it is not yet documented <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;reference&#x2F;issues&#x2F;248" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;reference&#x2F;issues&#x2F;248</a> but has been left-to-right for basically forever <a href="https:&#x2F;&#x2F;internals.rust-lang.org&#x2F;t&#x2F;rust-expression-order-of-evaluation&#x2F;2605&#x2F;34" rel="nofollow">https:&#x2F;&#x2F;internals.rust-lang.org&#x2F;t&#x2F;rust-expression-order-of-e...</a> and I actually thought that it <i>was</i> documented as such. I would expect this to shake out the exact same way as struct field destruction order, that is, something that&#x27;s been one way for a long time and so we wouldn&#x27;t change it even if maybe it&#x27;s a good idea to.<p>&gt; Traits...  the problem is not me being stupid but rather the lack of formal description on how it’s done and why what I want is so hard. Then I’d probably at least be able to realize how I should change my code to work around the limitations.<p>Upcasting&#x2F;downcasting is rarely used, and so has less love, generally, it&#x27;s true.<p>&gt; First of all, bootstrapping process is laughably bad.<p>So, Kostya acknowledges<p>&gt;  Of course it’s a huge waste of resources for rather theoretical problem but it may prove beneficial for compiler design itself.<p>Which is I think the way most feel about it. <i>However</i>, there is <i>some</i> desire to improve this, for other, related reasons. <a href="https:&#x2F;&#x2F;matklad.github.io&#x2F;2020&#x2F;09&#x2F;12&#x2F;rust-in-2021.html" rel="nofollow">https:&#x2F;&#x2F;matklad.github.io&#x2F;2020&#x2F;09&#x2F;12&#x2F;rust-in-2021.html</a> talks about some of them.<p>&gt; Then there’s LLVM dependency.<p>While this stuff is all true, we wouldn&#x27;t be where we are without it. Everything has upsides and downsides.<p>&gt; And finally there’s a thing related to the previous problem. Rust has poor support for assembly.<p>He mentions asm; we&#x27;re almost there! It took some time because it is not a simple problem. At the end of this, we&#x27;ll have <i>better</i> support than C or C++ according to his metrics; these are not part of the language standard, so give his previous comments about maturity, I find this one a <i>little</i> weird, but it is what it is. :)<p>&gt; There’s also one problem with Rust std library that I should mention too. It’s useless for interfacing OS.<p>Yes, the intention of the standard library is to be <i>portable</i>, so that&#x27;s not really a goal.<p>&gt; But the proper solution would be to support at least OS-specific syscall() in std crate<p>This may in fact be a good idea! I&#x27;m not sure how much use it would actually get.