reference

s more about this than I ever will).

e stability very strongly, and don't have the ability to document things with the guarantees we'd prefer. You might call it... not mature enough yet :) There's been a bunch of movement here, I'm excited to see it continue to develop! > Function/method calling convention. ... I’m told that newer versions of the compiler handle it just fine but the question still stands The objection here doesn't have to do with calling conventions, actually, this is about "two-phase borrowing," described in a series of blog posts ending here http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest... I believe this will get even better with polonius https://nikomatsakis.github.io/rust-belt-rust-2019/ Regarding argument evaluation order, technically it is not yet documented https://github.com/rust-lang/reference/issues/248 but has been left-to-right for basically forever https://internals.rust-lang.org/t/rust-expression-order-of-e... and I actually thought that it was documented as such. I would expect this to shake out the exact same way as struct field destruction order, that is, something that's been one way for a long time and so we wouldn't change it even if maybe it's a good idea to. > 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. Upcasting/downcasting is rarely used, and so has less love, generally, it's true. > First of all, bootstrapping process is laughably bad. So, Kostya acknowledges > Of course it’s a huge waste of resources for rather theoretical problem but it may prove beneficial for compiler design itself. Which is I think the way most feel about it. However, there is some desire to improve this, for other, related reasons. https://matklad.github.io/2020/09/12/rust-in-2021.html talks about some of them. > Then there’s LLVM dependency. While this stuff is all true, we wouldn't be where we are without it. Everything has upsides and downsides. > And finally there’s a thing related to the previous problem. Rust has poor support for assembly. He mentions asm; we're almost there! It took some time because it is not a simple problem. At the end of this, we'll have better 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 little weird, but it is what it is. :) > There’s also one problem with Rust std library that I should mention too. It’s useless for interfacing OS. Yes, the intention of the standard library is to be portable, so that's not really a goal. > But the proper solution would be to support at least OS-specific syscall() in std crate This may in fact be a good idea! I'm not sure how much use it would actually get.