> Rust does not have a formal language specification […] A proper mature language (with 1.0 in its version) should have a formal specification
Python doesn’t have a formal specification. It doesn’t even have a semi-formal specification. I would consider Python a proper mature language. (… even if it doesn’t have 1.0 in its version!)
> In Rust it’s undefined because there’s no format specification to tell you even that much.
That seems to me an very unreasonable definition of “undefined”. By that token, nothing in Rust is defined, which renders the term “undefined” devoid of meaning and completely useless. Rather, the implementation defines the specification, which, yes, is weaker than a formal specification, but not that much weaker. (Rust’s stability guarantees do allow it to retcon, but only if safety is on the line, or sometimes if you can convince people that affected code probably doesn’t exist, or was wrong anyway. Changing argument order evaluation in this sort of case would break plenty of real-life code, and so will never happen.)
> […] 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.
I disagree that the lack of a formal description of how it’s done is the problem, though such a description would certainly help. I feel that the real problem here is that you’re trying to treat traits as something that they’re not, trying to do things that you’re used to doing in dynamic/GC languages that just don’t map to Rust because of it being a thin abstraction over what can be fastest. Upcasting and downcasting trait objects is really rare, because other constraints of the language make them just not very useful operations. The main reason you want those operations in other languages is inheritance, not interfaces, and Rust doesn’t do inheritance, and traits aren’t inheritance.
> rustc problems
The bootstrapping process is not laughably bad, the developers have merely prioritised their own ergonomics rather than pandering to making proving a theoretical problem false easier. Still more, they’ve prioritised actually using new functionality, which helps make sure that it both works properly, and is the right new functionality. So I find two or three good reasons for doing it the way they have, and one weak reason not to do it that way.
The LLVM dependency: I feel that this complaint is more about there being only a single Rust backend, rather than about the LLVM dependency. This point is then debatable. Yeah, Rust would be more mature if it had more backends (or better, more full implementations), but does having only a single implementation make it immature? Eh. Plenty of mature languages functionally have but a single implementation.
———
I definitely consider Rust not yet mature, I just don’t think that most of the reasons in this article are legitimate. I would focus in no small part on documentation, just not requiring formality of specification or documentation before I’d consider those parts mature. But note that I said that I’d consider Rust not yet mature, rather than the Rust programming language. Because in most regards I do actually consider the programming language itself mature, and a lot of its tooling (more than popular languages thrice its age), though there are definitely still gaps in both. But the ecosystem around the programming language, that’s the area where it’s not yet mature. Rust is much more complex than many languages (e.g. Go), so it takes a lot longer to fill in the spaces in library availability, and there are many very significant gaps that haven’t been filled yet. GUI, for example, is very immature space. Audio is… eh, it’s getting somewhere, but I wouldn’t call it mature. Web is approaching maturity for some sorts of tasks, but is not generally mature.
> The bootstrapping process is not laughably bad, the developers have merely prioritised their own ergonomics
Ironically, I would disagree here; the language developers have not prioritized their own ergonomics, which is why building rustc is a big pain.
I do agree that making it easier to bootstrap in that way would not necessarily help them... there is a sense in which you're right, I just found the framing kind of funny, since I'd argue the same point but for completely opposite reasons.
Building rustc may be a bit of a pain (big pain? It’s more than five years since I last built rustc from source, but I don’t recall having any particular difficulty with it), but I was speaking specifically of the bootstrapping part, which I don’t feel is at all terrible. Specifically targeting version n − 1 means that you can adopt new language features, which you couldn’t if you were targeting version 1.0 forever, or writing it in another language. That’s what I was meaning by prioritising their own ergonomics—allowing them to use new features. With that clarification, I’m interested in whether you agree or disagree. You’ve been a lot closer to the action than I have.
Yes, I do think you're right about this generally, which is what I was getting at at the end.
This doesn't have to be all-or-nothing, though, if you check out matklad's post I linked, he points to a version where the standard library still gets to use unstable features, but the compiler does not, which is an interesting hybrid that may retain the best of both.
> Rust does not have a formal language specification […] A proper mature language (with 1.0 in its version) should have a formal specification
Python doesn’t have a formal specification. It doesn’t even have a semi-formal specification. I would consider Python a proper mature language. (… even if it doesn’t have 1.0 in its version!)
Some recently-published work in the general direction of formally specifying Rust behaviour: https://people.mpi-sws.org/~jung/thesis.html
> In Rust it’s undefined because there’s no format specification to tell you even that much.
That seems to me an very unreasonable definition of “undefined”. By that token, nothing in Rust is defined, which renders the term “undefined” devoid of meaning and completely useless. Rather, the implementation defines the specification, which, yes, is weaker than a formal specification, but not that much weaker. (Rust’s stability guarantees do allow it to retcon, but only if safety is on the line, or sometimes if you can convince people that affected code probably doesn’t exist, or was wrong anyway. Changing argument order evaluation in this sort of case would break plenty of real-life code, and so will never happen.)
> […] 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.
I disagree that the lack of a formal description of how it’s done is the problem, though such a description would certainly help. I feel that the real problem here is that you’re trying to treat traits as something that they’re not, trying to do things that you’re used to doing in dynamic/GC languages that just don’t map to Rust because of it being a thin abstraction over what can be fastest. Upcasting and downcasting trait objects is really rare, because other constraints of the language make them just not very useful operations. The main reason you want those operations in other languages is inheritance, not interfaces, and Rust doesn’t do inheritance, and traits aren’t inheritance.
> rustc problems
The bootstrapping process is not laughably bad, the developers have merely prioritised their own ergonomics rather than pandering to making proving a theoretical problem false easier. Still more, they’ve prioritised actually using new functionality, which helps make sure that it both works properly, and is the right new functionality. So I find two or three good reasons for doing it the way they have, and one weak reason not to do it that way.
The LLVM dependency: I feel that this complaint is more about there being only a single Rust backend, rather than about the LLVM dependency. This point is then debatable. Yeah, Rust would be more mature if it had more backends (or better, more full implementations), but does having only a single implementation make it immature? Eh. Plenty of mature languages functionally have but a single implementation.
———
I definitely consider Rust not yet mature, I just don’t think that most of the reasons in this article are legitimate. I would focus in no small part on documentation, just not requiring formality of specification or documentation before I’d consider those parts mature. But note that I said that I’d consider Rust not yet mature, rather than the Rust programming language. Because in most regards I do actually consider the programming language itself mature, and a lot of its tooling (more than popular languages thrice its age), though there are definitely still gaps in both. But the ecosystem around the programming language, that’s the area where it’s not yet mature. Rust is much more complex than many languages (e.g. Go), so it takes a lot longer to fill in the spaces in library availability, and there are many very significant gaps that haven’t been filled yet. GUI, for example, is very immature space. Audio is… eh, it’s getting somewhere, but I wouldn’t call it mature. Web is approaching maturity for some sorts of tasks, but is not generally mature.