
Sealed Rust Update - csomar
https://ferrous-systems.com/blog/sealed-rust-the-plan/
======
xvilka
I am surprised they didn't mention Iris[1] and RustBelt[2] projects. Iris
works on creating the formalization framework based on separation logic and
Coq. They have the Rust code model specifically[3].

[1] [https://iris-project.org/](https://iris-project.org/)

[2] [https://plv.mpi-sws.org/rustbelt/](https://plv.mpi-sws.org/rustbelt/)

[3] [https://gitlab.mpi-sws.org/iris/lambda-rust](https://gitlab.mpi-
sws.org/iris/lambda-rust)

~~~
Argorak
This is mainly a lapse. Thanks for highlighting them, they do awesome work!

They are also not quite what Sealed Rust is about. RustBelt is about formally
verifying Rust and improving the understanding of the language.

Sealed Rust is mainly about the industrial adoption process. It's not meant as
a replacement or competing project, quite the contrary: RustBelt existing is a
huge motivator and a major stepping stone to build on.

We are also personally in touch through the Rust project.

------
_bxg1
This is an important effort, but it's weird (disconcerting?) to me that
something so fundamental as a formal language specification (for a language
that advertises safety as a key feature) is being bootstrapped not by the core
team, but by a third party. It doesn't feel like that's something you only
need "collaboration with" the core team about. I can't think of anything
that's _more_ "core".

The rest of it makes sense as an auxiliary effort: working directly with
relatively niche industries on certification, narrowing down a fully-safe
subset of the language, etc. But I don't see how Rust can ever come into its
own in the space that it's targeting without having a real specification
outside of the compiler.

~~~
chrismorgan
Speaking bluntly:

Almost everyone using the language at present is getting by just fine without
this. As a normal Rust developer, I don’t particularly care about a formal
language specification existing. It’s a _long_ way down my list of nice-to-
haves—yeah, it would be nice to have, but there are quite a few other things
that would be _more_ nice to have.

The core team are compiler and language developers. I’d much rather have them
working on the language, rather than a formalisation of the language that
isn’t going to benefit me particularly for many years. If there are other
people that _are_ interested in doing that work, good on ’em; it’ll be
interesting to see what happens, but I don’t want the core developers
distracted with this sort of speculative work—for this is a heavily
experimental area. This is _absolutely_ a place for only a collaboration,
rather than having it being managed by the core team. If the core team were
focusing on this, everything would collapse in a heap. The core team is a very
finite resource that does not specialise in this sort of thing in any way.

~~~
saurik
I think the argument is that if you said that about C++ everyone would be
"yeah: this is just a useful tool, so why do I care?"... but Rust is about
safety, and if you don't have a formal model of the language by what reasoning
could you possibly have to _know_ it is safe? (And, in fact, every now and
then--much less often these days, but still--someone finds a soundness issue
in Rust itself, something you would hope to have been able to disprove at the
outset using a proof over a formal model.)

~~~
chrismorgan
I care about Rust’s safety. It’s what let me confidently use Rust instead of
Python or JavaScript, where I had never felt comfortable with C or C++.

But the safety that Rust has already is good enough for me. I know that
soundness holes exist (c.f. [https://github.com/rust-
lang/rust/labels/I-unsound%20%F0%9F%...](https://github.com/rust-
lang/rust/labels/I-unsound%20%F0%9F%92%A5)), but they are very few, and if
they’re realistic (most of those are _possible_ but difficult to trigger and
very unlikely to be encountered by real code) they get knocked down very
quickly.

Frankly I think you’re overhyping the benefits of a formal model (in practice
I believe it’s normally only certain subsets of popular compilers that are
ever formally verified), underestimating the pernicious presence of bugs even
with formal verification, and overvaluing the significance of the remaining
0.00000001% of safety to a working programmer.

In line with what mikekchar says, I care about performance and such things
more than I care about _formal verification_ of Rust’s safety.

I’m happy to hear about this stuff, but I don’t expect it to personally affect
me, for the better _or_ for the worse.

------
sliken
The working URL [https://ferrous-systems.com/blog/sealed-rust-the-
plan/](https://ferrous-systems.com/blog/sealed-rust-the-plan/)

------
analognoise
I don't get why there is so much love for Rust but so little love for Ada?

~~~
sgift
Did Ada - or rather its proponents - make any effort to get people to learn
it? If I google for "Ada programming language" I do not even find what could
be an official site? I thought it could be adacore.com, but that's a
commercial offering. Wiki tells me it could also be adaic.org, which errors
out with "SSL_ERROR_UNSUPPORTED_VERSION" in current Firefox. Even if I could
access the site: Would I find tutorials? Other supporting material?
Explanations why I should use Ada?

If you want people to use your language you have a to put in work. Even more
for a language with the reputation of Ada (the sibling comment by pjmlp gives
a good overview).

~~~
synack
Agreed, Ada's documentation is sparse and hard to find. Unfortunately, the
best resource I've found for learning it from the ground up is the textbook
"Programming in Ada 2012" by John Barnes. It's a bit pricey, but the core of
the language hasn't really changed since Ada 95, so a used copy of an old
edition will get you started.

AdaCore's got some decent learn-by-example stuff here, but it doesn't cover
every aspect of the language. [https://learn.adacore.com/courses/intro-to-
ada/index.html](https://learn.adacore.com/courses/intro-to-ada/index.html)

Wikibooks has a pretty comprehensive book on Ada Programming, but there are
still a lot of missing pages.
[https://en.wikibooks.org/wiki/Ada_Programming](https://en.wikibooks.org/wiki/Ada_Programming)

Finally, the language reference covers everything, but it's formatted in the
most unusable and difficult to search way I've ever seen. The source files for
the reference are maintained by a single editor who invented his own markup
language and parser for converting that into HTML and PDF. That may have been
acceptable in 1995, but it provides a significant barrier to adoption today.
I've made a few attempts at coercing these sources into docbook, but so far
I've found I'm not clever enough to untangle this mess. [http://www.ada-
auth.org/standards/ada12.html](http://www.ada-auth.org/standards/ada12.html)

So yeah, just buy the textbook... Skip the first few chapters, they're
basically just advertising that tells you how great the thing you're about to
learn is, which I find to be in poor taste.

------
jnordwick
I want much more runtime performance out of rust more than anything else.
Faster builds are second on the list. This probably doesn't even make top 10.
Who is this aimed at? And I would hate for those top goals to be subverted for
this.

~~~
banana_smoothie
From the previous blog post ("Part 1: The Pitch"[1]):

> We hope that the Sealed Rust effort would be applicable to any developers
> working in safety critical software domains, such as:

> Automotive (under safety standard ISO26262)

> Industrial (under safety standard IEC61508)

> Robotics (under a number of safety standards deriving from IEC61508)

> Medical Devices (under safety standard IEC62304)

> Avionics (under safety standard DO-178)

[1]: [https://ferrous-systems.com/blog/sealed-rust-the-
pitch/](https://ferrous-systems.com/blog/sealed-rust-the-pitch/)

~~~
sriram_sun
I work in medical devices and out-of-the-box rust would be a much better
option than the C++ systems we build!

There is competition in this space from qnx as well.

Take a look at the medical device alarms standard IEC 60601-1-8. It's possible
to provide a very generic implementation of the standard for high, low and
medium priority alarms. Could act as a trojan horse to introduce your back end
messaging, logging, shared memory infrastructure - all developed according to
ISO 62304 (of course)!

