Hacker News Reader

LOL some people complain that Rust is moving too slow, and others that Rust is moving too fast and adds too many features. Can never make everyone happy...

I just filled out the Rust survey [1] and may have done both—iirc there were checkboxes for missing features and concerns the language is getting too complicated. It's a hard balance to find.

[1] https://blog.rust-lang.org/2023/12/18/survey-launch.html

Depending on the scenario, I don’t hear mutual exclusion there.

It can be moving too slow on important things, and too fast on unimportant or volatile things.

The problem is the things people think are important or unimportant is not universal.

Good projects with bad leadership die ever day.

Hopefully Rust has people with vision and drive in places to let it escape its niche status.

Mara’s blog post (your first link) says essentially that Rust does not need a standard since it already has means for adding features and maintaining compatibility.

Mara's blog post also describes the benefits of standardizing Rust.

Since she created the RFC for standardizing Rust (https://github.com/rust-lang/rfcs/pull/3355) and is also on the team that is working on Rust standardization (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...), I think she was making the point that Rust has good controls in place for adding features while compatibility, not that "Rust does not need a standard".

If she really believed that Rust does not need a standard, why would she create the RFC and join the team working on the effort?

Rust is a great language. There is no reason why it should not have a standard to better formalize its requirements and behaviors.

Yes, it’s a nuanced blog post. But that also means it doesn’t coming out swinging hard for needing a standard, either. It seems like there is as strong an argument to be made that “Rust is a great language. There is no reason why it needs a standard.”

See the Ferrocene compiler which has been qualified for ISO standards. It’s essentially a standard Rust 1.68 compiler with a lot of added documentation. If you need a Rust compiler for safety critical environments, it’s reasonably priced and requires essentially zero changes to the Rust compiler that they didn’t just upstream. Without a standard.

Yes, it would be nice to have a standard for reducing ambiguity. But does the language need a standard? And if so, then for what purpose?

They created a specification for Ferrocene because Rust does not yet have a language standard:

https://spec.ferrocene.dev/

>> But does the language need a standard?

Yes, Rust needs a standard.

>> And if so, then for what purpose?

For the same purpose that all standards have--to formally define it in writing.

Ferrocene's web site (https://ferrous-systems.com/ferrocene/) shows that it meets the ISO 26262 standard (https://en.wikipedia.org/wiki/ISO_26262).

Why does ISO 26262 matter? What purpose does it serve? Couldn't a vehicle manufacturer just say "our vehicles are safe"?

Which would you trust more: a vehicle that is verified to meet ISO 26262 standards, or a vehicle whose manufacturer tells you "it's safe" without formally defining what "safe" means?

I stated it above, but I will re-state it here: Without a language standard, there are many organizations and industries that will not use Rust. Not because Rust is not a fantastic tool for the job, but because laws, regulations, etc. require standardization and qualification of components.

This means that I can use a qualified C compiler and toolchain to write safety-critical code, but I can't use Rust despite the fact that Rust is a better choice and will help to prevent problems. Standards do matter. Rust needs a language standard.

> For the same purpose that all standards have--to formally define it in writing.

This is tautological. It's equivalent to saying "it needs a standard to be written because it needs a written standard."

I mean what use case is there for Rust language users that isn't already met by the Ferrocene project? And the Ferrocene project is not a standard as in "other implementations will be found lacking," but a description of the 1.68 compiler as-is. That is a specification, not a standard. Ferrous Systems did not need Rust to have a standard in order to qualify the compiler for ISO 26262 and IEC 61508.

>> "it needs a standard to be written because it needs a written standard."

Yes. And if the law in your country requires it to be standardized for specific use cases, then a language standard is needed.

>> what use case is there for Rust language users that isn't already met by the Ferrocene project?

Can you legally use Rust for the control software in aircraft? (https://en.wikipedia.org/wiki/DO-178C)

What about the safety systems for railroads? (https://ldra.com/ldra-blog/software-safety-and-security-stan...)

What about the control systems for nuclear reactors? (https://www.nrc.gov/docs/ML1300/ML13007A173.pdf)

And if you need a ISO 26262 qualified Rust compiler, one exists. Hurrah.

Since you edited your post…simply having a standard won’t immediately qualify the language for those industries. There is only a tenuous link between having a standard and qualifying the language for industrial use.

>> simply having a standard won’t immediately qualify the language for those industries. There is only a tenuous link between having a standard and qualifying the language for industrial use.

Not having a language standard disqualifies Rust.

Administrators say that it shows that Rust is "not serious" and "not ready" for critical work.

> Not having a language standard disqualifies Rust.

Then explain how Ferrous Systems qualified a stock Rust compiler.

Ferrocene is not a "stock Rust compiler". The "stock Rust compiler" is not qualified for safety critical work. If Ferrocene did not add value above what is offered by the stock Rust compiler, why would anyone buy Ferrocene?

Ferrocene is qualified for some safety critical work and plans to have more qualifications soon.

Ferrous Systems wrote a blog post about the process: https://ferrous-systems.com/blog/qualifying-rust-without-for...

The blog post you link to says it's an unmodified fork. Here's a Ferrous Systems employee saying as much:

> Ferrocene is upstream rustc but with some extra targets, long term support, and qualifications so you can use them in safety critical contexts. This is what was stopping things like automotive companies from moving to Rust for things like engine control units, etc.

> It basically costs some money for the support and the qualification documents, but they will be all you need to prove qualification to any pertinent regulatory body so that your software can be certified for use in a real vehicle or whatever.

> ...Ferrocene is just unmodified rustc

https://old.reddit.com/r/rust/comments/17qi9v0/its_official_...

Basically the value add was to expand the support and documentation, which was required for qualification.

Again...no "standard" needed.

I think you are conflating standards and specifications. Ferrous fleshed out the specification, the description of the 1.68 compiler as-is. That means Rust 1.68 as-is was good enough for ISO qualification. Without a standard.

A standard is a minimum bar for languages to meet in order to be considered compliant. That's not a problem right now because there is, for all intents and purposes, a single canonical compiler and that is not likely to change.

As you point out, the important bit is the documentation that shows how and why a language is compliant with a safety standard. The spec serves as the basis on which the compliance can be referenced. A given implementation then is shown to satisfy the spec.

So yes, a given vanilla release is compliant, you just can't do anything with that in a way that an audit will allow until you include all the justifications as to how that makes the language safe (defined by whatever safety standard you need).

Spec ≠ Standard

Rust absolutely does not need a standard. Having a standard is a completely outdated way to design software in the internet era. Having a specification is a great idea and is what most people actually mean.

What’s the difference?

A standard is a way of writing and ratifying a specification. A spec is just a formal document describing the requirements for something, but a standard is when you have large coalition of relevant players accepting the spec as a committee. In this context it's also implied that it's an ISO standard which is extremely slow, rigid and formal and is a downgrade in every way from the current system of anyone who wants to voice their opinion just chiming in on an RFC on github.

The Ferrocene spec permits Rust to be used in those industries.

Go has a really nice spec and multiple implementations too.

https://go.dev/ref/spec

Does any other go implementation support the full language? I thought gccgo lagged significantly.

The official GCC releases tend to lag a bit as they are released on a longer cadence than the standard Go compiler but upstream. The current release is a bit further behind than normal due to the complexities around implementing the generics back end, but it is being worked on (https://groups.google.com/g/golang-dev/c/5ZKcPsDo1fg).

Thanks for the heads up, I was starting to think it would join gjc in retirement home.

> There are many organizations and industries that will not adopt Rust until it has a standard.

Counterpoint: rust is doing fine without those organizations and industries. Why change what is working well?

If rust wants to replace memory-unsafe languages, it needs to cover their use cases.

Which usecases does it not cover?

>>> There are many organizations and industries that will not adopt Rust until it has a standard.

So if you want those orgs/industries to get memory safety via rust, you either need a standard, or to convince them to not require that.

Those are bureaucratic reasons, not anything specifically lacking in Rust.

>> Counterpoint: rust is doing fine without those organizations and industries. Why change what is working well?

Because Rust is a game changer.

Wouldn't it be better to have Rust used for the code that runs on automobiles and aircraft? Or you would prefer that they keep using (subsets of) C and C++?

Is the security of your Internet-of-Things (IoT) devices good enough or could they be better?

What do you have against Rust being used in more places and for more purposes?

Ferrous Systems has a basically bog standard Rust 1.68 compiler that’s been certified for use in the most safety critical environments: https://ferrous-systems.com/blog/officially-qualified-ferroc...

This happened without a standard.

>> This happened without a standard.

They created a specification for Ferrocene:

https://spec.ferrocene.dev/

While it is technically not a Rust language standard, it serves a similar purpose for Ferrocene.

Is it doing fine without those? It seems like every time someone makes a personal or professional project in C/C++, the Rust community floods the comments section and talks about how it's irresponsible to use C/C++ and how the author should just throw away the whole project and re-write it in Rust.

It happens so often it became a meme at this point.

> It happens so often it became a meme at this point.

No, the meme is kept alive by C++ people who say that this happens without it actually happen. It happened a long time ago a few times, since then it's either an active discussion about languages, where for some reason talking about Rust is a problem, but every other language is okay or it's someone feeling attacked by the mere idea that projects which only could be done in C++ could now also be done by another language and starts crying about how the Rust community would flood every topic.

There's no longer an area where C++ is the only available option. Get over it. The rest of the world did a long time ago.

This is really odd to me. Language design should start with specification. Your compiler is just a reference implementation.

Rust language design does start from specifications, namely RFCs. What is being discussed here is producing a more formal specification than the ones that currently exist.

Yeah. The culture crash here is shocking dissonant. The people you'd normally expect to be the biggest voices for documentation robustness are...

... suddenly finding themselves in the "Actually, language standards are bad" camp, all because of a tribal opposition to the FSF?

Write the standard. Then argue that gccrust doesn't do it right. Don't refuse to document the language just to hamstring a competitor.

Also, please start with the borrow checker semantics. I don't think I've ever met anyone who could explain exactly what the rules are regarding what it can/can't prove.

There's been active work on a Rust specification for a while now. It'll happen.

https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...

What culture crash? The Rust project has a language reference, is working on expanding it into a more formal spec, and there are efforts like Ferrocene's to qualify the existing compiler for use in safety critical environments.

The argument is not that language standards are bad, it's that a C++-like ISO standard is unnecessary (when the quality documentation can exist in another form) and C++-like implementation fragmentation is bad.

(Have you read the NLL RFC? The Polonius work?)

Reply on news.ycombinator.com