[dasfasf]

Rust is not as finalized as any of the languages whose semantics are completely defined by a standard document. There is no definitive answer to the question of what a great many pieces of Rust do beyond checking out rustc from the commit date and examining the LLVM IR.

[steveklabnik]

There are a very small number of languages which have those things. They are useful and we want them, but I think it's _generally_ an unreasonable standard overall.

[dasfasf]

Not if you weight by use. C, C++, Java, Javascript, and C# all have specs. Among the most popular languages, it's really only the scripting languages that have the "as our implementation does" perspective on specification. I've always used languages that have standard documents, and communities that think those standard document are very important, so rather than being unreasonable, I think of complete language documentation as the natural state of the world.

Incidentally, this isn't really a criticism, but it's precisely because I don't see Rust as finalized that it isn't. A language that's finalized but not specified is just poorly documented.

[nickpsecurity]

Most of those languages had no clear, formal spec early on. Especially C and C++: one getting started with UNIX and ad hoc code with the other starting as C w/ Classes plus some extra features from other languages. IIRC, Java's initial mandates hurt it because they were terrible quality in a number of areas and took up to a 15x (yes, times) performance hit in some measurements I saw. JavaScript were two, competing implementations with a ship-first mentality with a bit of it standardized later with vendor-specific stuff left in. C# did have a language specification on v1.0 whose quality I have no knowledge of. I do know they internally beta'd it starting in the late 90's. So, it was done similar to Rust but privately for years before that spec.

So, I'm not seeing your examples as relevant or a critique. Most were in use and changing [to their benefit] before any spec was created. Three of those very publicly, one privately. Another sucked partly thanks to formalizations with lots of money driving adoption. I think you should read Gabriel's Worse is Better essays... several rather than just the first... to see why pushing a partly done or evolving system is right approach for growth & accelerated improvements. Lipner at Microsoft, inventor of successful Security Development Lifecycle, incidentally thought the same thing.

Least Rust team is trying to fix problems and evolve in a robust way. That's quite rare for mainstream stuff that I've seen.

[dasfasf]

To be honest, I'm not seeing your pointing this out as relevant. I never claimed Rust should have a spec at this point in its life, or claimed any other language had a spec at an equivalent point in its life, and I explicitly disclaimed any criticism. I objected only to the statement that Rust is "just as finalized as any other language". Talking about other languages' youth and whether being specified early is a good thing is especially disingenuous, since the topic of the thread was whether Rust was a good candidate to use now, compared against other languages as they exist now, not making some kind of "fair" comparison against their early versions.

[nickpsecurity]

"I objected only to the statement that Rust is "just as finalized as any other language"."

I might have been too hasty there. Your context and this quote makes much more sense. I say something similar to them myself. Yet, they've already entered a 1.0 mode where they're not breaking stuff with much of it documented in guides. That's not formal but pretty final on language itself. Standard libraries and other tooling are where most of their work is right now.

So, I don't feel it's an accurate statement but it's close if we're talking the language. I prefer to say the core language is pretty stable or something like that.

[steveklabnik]

Yes. Those are all old, established languages. And while they do have a _lot_ of use, there are also a significant number of languages which see heavy amount of use that have no spec. And as you mention, it's not exactly a criticism; it depends on where you fall on the maturity scale of languages you wish to use.

It's only unreasonable due to Rust's young age. At Rust's age, none of those languages had a specification either.

[kibwen]

In fact, C didn't have a specification for the first 17 years of its existence. :)

[pjmlp]

I wouldn't see this as positive.

This fact is the major reason behind the whole undefined behavior story in C and its derived languages.

When the standard came to be, no vendor wanted to give up on the semantics that gave their compiler some kind of advantage.

So all those little issues were tucked into undefined bucket.

[kibwen]

Indeed, I'm hoping that Rust begins a push for standardization no later than five years from now, with a formal spec ratified no later than ten (which may sound like a long timeframe, but that would still put it ahead of the average standardization curve). And we're already making a head start on a few necessary aspects of a specification, such as formally proving that our type system is actually as strong as we think it is.

[pcwalton]

Developing a standard for Rust would have incredibly few practical consequences, given that there are no alternative implementations. It would, however, consume a lot of people's time. That time could be spent on things with practical impact, such as compilation speed improvements, stabilization of features, and better optimization.

The reason why Rust was stabilized in advance of a standard is that stabilization had an immediate practical consequence: ceasing to break code. A standard, by contrast, would have virtually no practical use.