Everyone is going to have a different definition of "mature", and that's fine :) Obviously lots of respect for Kostya. I do think that framing these as "maturity" is a good framing, that is, fundamentally, he'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 higher 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's a different thing.

My take on the state of these issues:

> Rust does not have a formal language specification... I understand that adding new features is more important than documenting them but this is lame.

Most languages do not. It also really depends on what you mean by "formal."

It's not about being more important, it's that we value 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.