Hacker News Reader

Comment by eterm | Hacker News Reader

Said no one who has to maintain others' software.

It's a fair point, but there's a lot of write-only Perl, PHP, and C out there. Let's make sure we don't hold new Rust code to a higher standard that that stuff.

Ideally we should hold all new code to a higher standard than that. All programmers spend much more time reading code than writing it.

Likewise, Rust is not finalized as a language yet. That means whoever has to maintain the original commenter's code is likely to be in for a rough time if and when they ever attempt to bump the Rust version.

> Rust is not finalized as a language yet.

It is just as finalized as any other language.

> if and when they ever attempt to bump the Rust version.

If the parent is using a stable release, like this 1.6 is, then bumping the version should be all they need to do. (Unless they're relying on a safety hole for some reason; we do fix those)

Fair enough- I wasn't familiar with Rust's backwards compatibility guarantees and had heard a bit about breakage, so thanks for pointing that out.

No worries. Every 1.x+1 is backwards compatible with 1.x, modulo some details. Usually breakage is mentioned in the context of the nightly ecosystem, which has no particular guarantee. We also reserve the right to fix soundness bugs, though we try to make upgrading easy in those situations of and when they occur (we've only had one or two so far).

Rust development was done in public (unlike Go or Swift which started out privately), so we had a very long 0.x period which was public and had tons of breakages where the language designers tinkered with just about every tradeoff.

So it's easy to see where you get the impression that Rust is prone to breakages, but that doesn't happen anymore.

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.

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.

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.

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.

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

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.

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.

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.

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.

"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.

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.

Don't forget Python and R and C++ and JS and ... hmm. Almost like the language doesn't have much to do with it so much as the writer. But I digress!

He said it's documented. That tells me it's probably easier to maintain than many other approaches.

There is also a test suite b/c cargo makes it stupidly easy to write tests.

I actually find myself pining for the simplicity of #[test] in other languages. It makes the Write->Test->Write loop so much faster.

Reply on news.ycombinator.com