5 ms·

Rust Adopting Ferrocene Language Specification

60 points by Tomte 2y ago

Pet_Ant 2y ago
This is much bigger news than I think people realise. With the push for more secure systems programming language, having a formal model will enable much more powerful tooling and theorem proving that will help spot, model, or identify vulnerabilities. (There will still be a class of vulnerabilities from when the implementation does not match the specification).
- karunamurti 2y ago
  Yeah and at the same time there are efforts to verify standard library using Kani: https://model-checking.github.io/verify-rust-std/ https://model-checking.github.io/verify-rust-std/ Between this and Bjarne Stroustrup panic leaked email to C++ standards committee members, it's going to be interesting for Rust's future.
  - pjmlp 2y ago
    While I agree with the huge adoption improvements, there is also a dose of reality check required. There are several domains where C++ never managed to displace C, and likewise the same seems bound to happen with Rust towards C and C++, regardless of safety improvements. Khronos API definitions, the whole GPGPU ecosystem including vendor tooling, all major runtimes and compiler frameworks, consoles devkits, are few domains where Rust has yet to have a presence.
    - RealityVoid 2y ago
      All GUI domain seems to be one big state, and that is the kind of place Rust refuses to interact with easily.
      - jenadine 2y ago
        That's not true. There are many GUI libraries for Rust.
        RealityVoid 2y ago
        There are. You can do it. It's just that the language fights you on it.
        bfrog 2y ago
        Not really, there’s two models that work. The react model and the immediate model. The whole class inherits widget hellscape is not, no loss there. That route inevitably leads to bugs that are hard to find and fix because of all the weird state buried in inherited types.
        ericwood 2y ago
        Global mutable state is difficult to handle correctly and Rust forces you to think through the consequences. There's no shortage of patterns for safely working with it, but you can't take the easy (and unsafe!) way out.
        tonyarkles 2y ago
        Sort of. Last time I looked, about a year ago, there were a bunch and all of the ones I looked at/tried seemed really awkward to use. I don’t love Qt either, but in C++ land it’s a pretty reliable way to slap together a simple UI that doesn’t require a whole lot of ceremony.
        feverzsj 2y ago
        They are just far far from mature. Your best bet for rust gui is still Qt bindings.
        galangalalgol 2y ago
        I really like egui. People talk about it not being professional because it is raster graphics and doesn't have native widgets, but neither of those things are anywhere on my customer's priority list.
    - LeFantome 2y ago
      Rust seems tailor made for a compiler framework. The issue is how often do new ones come along? In 40 years, we have GCC and LLvM. How long until something comes along to displace them in any language? Nobody is really trying to “rewrite it in Rust” the LLVM platform (even though Rust itself relies on it). There is Cranelift of course but it is not really trying to be LLVM.
  - vhantz 2y ago
    What panic leaked email?
    - ndiddy 2y ago
      I believe this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3651r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p36...
      - vhantz 2y ago
        Thanks > The demands for memory safety are not unreasonable, in fact, I consider them too feeble for the long term, so responding to the demands is in the interest of C++ > The sky isn’t falling, but unless we act now and get C++ onto a track supporting a flexible framework of profiles (supporting various forms of safety), we risk a painful decline. He's simply making the case for profiles and trying to rally the people he works with around that as a necessary goal. That's something that any leadership has to do from time to time. That's also something he's done before when he warned everyone about proposing a bunch of incompatible features with no clear vision. Nothing unexpected here, in no way is this "panicking".
mjw1007 2y ago
The Ferrocene Language Specification has two serious problems: there are very large gaps in it, and what's present is very buggy. If you pick a small part and look at it in isolation it typically looks quite plausible, but if you try to follow the definitions it very often just falls apart.
- evanjrowley 2y ago
  Are there some interesting public examples of where the FLS fails?
  - mjw1007 2y ago
    A year or so ago I read through one smallish section (basically function calls) and filed issues for the problems I found that were easy to write up crisply. They fixed the easy bugs: https://github.com/ferrocene/specification/issues/453 https://github.com/ferrocene/specification/issues/453 https://github.com/ferrocene/specification/issues/454 https://github.com/ferrocene/specification/issues/454 https://github.com/ferrocene/specification/issues/455 https://github.com/ferrocene/specification/issues/455 https://github.com/ferrocene/specification/issues/458 https://github.com/ferrocene/specification/issues/458 https://github.com/ferrocene/specification/issues/459 https://github.com/ferrocene/specification/issues/459 https://github.com/ferrocene/specification/issues/460 https://github.com/ferrocene/specification/issues/460 https://github.com/ferrocene/specification/issues/461 https://github.com/ferrocene/specification/issues/461 https://github.com/ferrocene/specification/issues/463 https://github.com/ferrocene/specification/issues/463 https://github.com/ferrocene/specification/issues/464 https://github.com/ferrocene/specification/issues/464 But they didn't try to fill the gaps: https://github.com/ferrocene/specification/issues/462 https://github.com/ferrocene/specification/issues/462 https://github.com/ferrocene/specification/issues/465 https://github.com/ferrocene/specification/issues/465 https://github.com/ferrocene/specification/issues/466 https://github.com/ferrocene/specification/issues/466 There were a lot more places where I had notes saying "it needs to say more about X" that I couldn't face trying to file issues for. I think that part of the spec wasn't any worse than average.
    - 2y ago
corank 2y ago
It seems to me that the part about unsafe operations is pretty much still unspecified. It's currently just a short paragraph saying it may cause undefined behaviour and a list of high-level descriptions of those unsafe operations. But what's the exact semantics of those operations? When is it undefined?
- wongarsu 2y ago
  Part of the reason is that this is the most difficult part to define, and part is that this is very much an area of active research and improvement. For example, what would a language specification say about the behavior and consequences of calling an unsafe function? It can only point to the function documentation, as the function could do anything. It might be reasonably well-behaved, for example `Vec::get_unchecked(index)` returns the item at `index` if index is a valid index, and does whatever your platform, chosen allocator and overzealous LLVM optimizations do on invalid pointer access. A different function might be complete chaos, since the unsafe function could contain any code. "Dereferencing a value of a raw pointer type" would be easier to define, but then you get down the whole pointer provenance rabbit hole. Saying "well, that might do anything" isn't that unreasonable of a stance for a specification, as long as you properly specify the pointer-provenance-aware route once it has been stabilized. Documentation on the other hand should be more helpful than that (and sadly often isn't), telling you when dereferencing a pointer does what you expect, when it doesn't, and what the pitfalls are.
deleted 2y ago
[deleted]

60 points by Tomte 2y ago

This is much bigger news than I think people realise. With the push for more secure systems programming language, having a formal model will enable much more powerful tooling and theorem proving that will help spot, model, or identify vulnerabilities. (There will still be a class of vulnerabilities from when the implementation does not match the specification).

karunamurti 2y ago
Yeah and at the same time there are efforts to verify standard library using Kani: https://model-checking.github.io/verify-rust-std/ https://model-checking.github.io/verify-rust-std/ Between this and Bjarne Stroustrup panic leaked email to C++ standards committee members, it's going to be interesting for Rust's future.
- pjmlp 2y ago
  While I agree with the huge adoption improvements, there is also a dose of reality check required. There are several domains where C++ never managed to displace C, and likewise the same seems bound to happen with Rust towards C and C++, regardless of safety improvements. Khronos API definitions, the whole GPGPU ecosystem including vendor tooling, all major runtimes and compiler frameworks, consoles devkits, are few domains where Rust has yet to have a presence.
  - RealityVoid 2y ago
    All GUI domain seems to be one big state, and that is the kind of place Rust refuses to interact with easily.
    - jenadine 2y ago
      That's not true. There are many GUI libraries for Rust.
      - RealityVoid 2y ago
        There are. You can do it. It's just that the language fights you on it.
        bfrog 2y ago
        Not really, there’s two models that work. The react model and the immediate model. The whole class inherits widget hellscape is not, no loss there. That route inevitably leads to bugs that are hard to find and fix because of all the weird state buried in inherited types.
        ericwood 2y ago
        Global mutable state is difficult to handle correctly and Rust forces you to think through the consequences. There's no shortage of patterns for safely working with it, but you can't take the easy (and unsafe!) way out.
      - tonyarkles 2y ago
        Sort of. Last time I looked, about a year ago, there were a bunch and all of the ones I looked at/tried seemed really awkward to use. I don’t love Qt either, but in C++ land it’s a pretty reliable way to slap together a simple UI that doesn’t require a whole lot of ceremony.
      - feverzsj 2y ago
        They are just far far from mature. Your best bet for rust gui is still Qt bindings.
        galangalalgol 2y ago
        I really like egui. People talk about it not being professional because it is raster graphics and doesn't have native widgets, but neither of those things are anywhere on my customer's priority list.
  - LeFantome 2y ago
    Rust seems tailor made for a compiler framework. The issue is how often do new ones come along? In 40 years, we have GCC and LLvM. How long until something comes along to displace them in any language? Nobody is really trying to “rewrite it in Rust” the LLVM platform (even though Rust itself relies on it). There is Cranelift of course but it is not really trying to be LLVM.
- vhantz 2y ago
  What panic leaked email?
  - ndiddy 2y ago
    I believe this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3651r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p36...
    - vhantz 2y ago
      Thanks > The demands for memory safety are not unreasonable, in fact, I consider them too feeble for the long term, so responding to the demands is in the interest of C++ > The sky isn’t falling, but unless we act now and get C++ onto a track supporting a flexible framework of profiles (supporting various forms of safety), we risk a painful decline. He's simply making the case for profiles and trying to rally the people he works with around that as a necessary goal. That's something that any leadership has to do from time to time. That's also something he's done before when he warned everyone about proposing a bunch of incompatible features with no clear vision. Nothing unexpected here, in no way is this "panicking".

mjw1007 2y ago

The Ferrocene Language Specification has two serious problems: there are very large gaps in it, and what's present is very buggy. If you pick a small part and look at it in isolation it typically looks quite plausible, but if you try to follow the definitions it very often just falls apart.

evanjrowley 2y ago
Are there some interesting public examples of where the FLS fails?
- mjw1007 2y ago
  A year or so ago I read through one smallish section (basically function calls) and filed issues for the problems I found that were easy to write up crisply. They fixed the easy bugs: https://github.com/ferrocene/specification/issues/453 https://github.com/ferrocene/specification/issues/453 https://github.com/ferrocene/specification/issues/454 https://github.com/ferrocene/specification/issues/454 https://github.com/ferrocene/specification/issues/455 https://github.com/ferrocene/specification/issues/455 https://github.com/ferrocene/specification/issues/458 https://github.com/ferrocene/specification/issues/458 https://github.com/ferrocene/specification/issues/459 https://github.com/ferrocene/specification/issues/459 https://github.com/ferrocene/specification/issues/460 https://github.com/ferrocene/specification/issues/460 https://github.com/ferrocene/specification/issues/461 https://github.com/ferrocene/specification/issues/461 https://github.com/ferrocene/specification/issues/463 https://github.com/ferrocene/specification/issues/463 https://github.com/ferrocene/specification/issues/464 https://github.com/ferrocene/specification/issues/464 But they didn't try to fill the gaps: https://github.com/ferrocene/specification/issues/462 https://github.com/ferrocene/specification/issues/462 https://github.com/ferrocene/specification/issues/465 https://github.com/ferrocene/specification/issues/465 https://github.com/ferrocene/specification/issues/466 https://github.com/ferrocene/specification/issues/466 There were a lot more places where I had notes saying "it needs to say more about X" that I couldn't face trying to file issues for. I think that part of the spec wasn't any worse than average.
  - 2y ago

corank 2y ago

It seems to me that the part about unsafe operations is pretty much still unspecified. It's currently just a short paragraph saying it may cause undefined behaviour and a list of high-level descriptions of those unsafe operations. But what's the exact semantics of those operations? When is it undefined?

wongarsu 2y ago
Part of the reason is that this is the most difficult part to define, and part is that this is very much an area of active research and improvement. For example, what would a language specification say about the behavior and consequences of calling an unsafe function? It can only point to the function documentation, as the function could do anything. It might be reasonably well-behaved, for example `Vec::get_unchecked(index)` returns the item at `index` if index is a valid index, and does whatever your platform, chosen allocator and overzealous LLVM optimizations do on invalid pointer access. A different function might be complete chaos, since the unsafe function could contain any code. "Dereferencing a value of a raw pointer type" would be easier to define, but then you get down the whole pointer provenance rabbit hole. Saying "well, that might do anything" isn't that unreasonable of a stance for a specification, as long as you properly specify the pointer-provenance-aware route once it has been stabilized. Documentation on the other hand should be more helpful than that (and sadly often isn't), telling you when dereferencing a pointer does what you expect, when it doesn't, and what the pitfalls are.

deleted 2y ago

[deleted]