Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.
Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.
Ferrous Systems donated their language specification ("Ferrocene") to the Rust foundation[0] who is working on integrating it but that takes time, obviously.
0: https://rustfoundation.org/media/ferrous-systems-donates-fer...
Their spec just happens to describe whatever the compiler decided to implement, it's not a source of truth.
How do you think that C got specified?
Do you think that it was made up from whole cloth in the abstract machine and implemented later? No, it was based on the available implementations of its time.
On top of that, languages like Python do not have a specification and yet have multiple implementations.
That's literally what the C++ specification does. The reason for all the UB and implementation defined stuff is because 90s compilers disagreed on sizeof(int).
I don’t think it’s a fair argument to criticize a spec because it’s derived from an implementation. If anything it shows how the spec can be practically applied.
And? What did you think it was going to be? An abstract description that completely ignores the existing compiler?
I don’t think this is a good argument, given that there are manifestly successful languages that don’t have a formal specification. Python comes to mind.
(Plus, architecture quantity isn’t exactly the thing that matters. Quality is what matters, and Rust’s decision to conservatively stabilize on the subset of LLVM backends they can reliably test on seems very reasonable to me.)
How has a language specification and multiple viable compilers helped C developers write security-critical code?
Considering the number of provers and statistical analysers and given C is the only mainstream language with a formally verified compiler, I would say fairly well thank you.
Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members that specification is meaningless.
C obviously always was a questionable choice for a tool like apt but Rust seems even worse to me. Apt has absolutely no need to be written in a low level language. At least you could argue that C was chosen because it’s portable but I don’t see what Rust has going for it.
All those things didn’t stop Heartbleed or numerous other CVEs from happening, though, did it?
Doesn't Java have also a formally verified compiler?
Check the list of supported architectures https://wiki.debian.org/SupportedArchitectures, it's pretty short. Official support extends to exactly 5 architectures. So Debian was never going to be your go to for anything not mainstream.
Perl has been a hard dependency of the base system since forever and it doesn't have a specification nor more than one interpreter.
The only spec you need meet to get Perl or Python running on a new platform is the C spec. A compiler meeting that spec is enough to port and compile the interpreter for a new platform.
Large share of C programs also (accidentally) depend on holes in the specifications, aka undefined behavior. Putting them under the mercy of the compiler to remain consistent.
Because there's so many PIC, MIP, and PS/2 systems out there running debian?
The war is over. ARM and x86 won.
RISC-V is well on its way to be a challenger to both, with (eventually) full support for Rust.
I'll be happy if it does, but I very much have a "I'll believe it when I see it" view of new archs like RISC-V.
The complaint about architecture support is somewhat valid (though: the world largely runs on a small handful of architectures). The other complaints are completely bogus, and repeatedly bringing them up just suggests bad faith.
Can you please make your substantive points thoughtfully instead of posting in the flamewar style? We're trying for the one and not the other here: https://news.ycombinator.com/newsguidelines.html.
(We detached this subthread from https://news.ycombinator.com/item?id=45782109.)
gccrs exists?
Flagged for deliberately spreading disinformation under the name StopDisinfo. As this user is aware, rust has a specification https://github.com/rust-lang/fls, which they have previously commented on: https://news.ycombinator.com/item?id=44927141 (and which I probably wouldn't have remembered if not for the rather remarkable name they are saying false things under).
Rust also has multiple compilers (rustc, mrustc, and gccrs) though only one is production ready at this time.
Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.
https://news.ycombinator.com/newsguidelines.html
The Rust specification you link is performative and only intended to satisfy requirements of certification processes. No one is actually using it to implement the language, as far as I am aware.
There is other work on specifying Rust (e.g. the Unsafe Code Guidelines Working Group), but nothing approaching a real spec for the whole language. Honestly, it is probably impossible at this point; Rust has many layers of implementation-defined hidden complexities.
“There’s a standard, but it’s performative” is a different argument than the top level one.
But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the virtues of standardization don’t seem compatible with accepting that.
The original purpose of the C standard was to solve the problems created by the diversity of increasingly divergent implementations of C. They studied existing behavior across systems, proposed new language constructs, and it was generally a success (look at the proliferation of C in the 90s across many different systems and architectures).
The actual informal semantics in the standard and its successors is written in an axiomatic (as opposed to operational or denotational) style, and is subject to the usual problem of axiomatic semantics: one rule you forgot to read can completely change the meaning of the other rules you did read. There are a number of areas known to be ill-specified in the standard, with the worst probably being the implications of the typed memory model. There have since been formalized semantics of C, which are generally less general than the informal version in the standard and make some additional assumptions.
C++ tried to follow the same model, but C++ is orders of magnitude more complex than C and thus the standard is overall less well specified than the C++ standard (e.g. there is still no normative list of all the undefined behavior in C++). It is likely practically impossible to write a formal specification for C++. Still, essentially all of the work on memory models for low-level programming languages originates in the context of C++ (and then ported back to C and Rust).
Well, the memory ordering model was developed for C++ and is used in C and Rust. But e.g. C++ does not have a pointer provenance model, which is arguably almost as important in this context. It turns out one of the things we really care about with multi-processing, and thus memory models is linked list hacks, and those only work if you have provenance rules, which uh, C++ just has a shrug emoji where the provenance rules would go so that's not great. C has an ISO document, although it's not part of the ISO C standard it's just another document so far, but Rust has specified provenance.
Also, the C++ ordering model is defective in the sense that while it offers the orders we actually use it also offers an order nobody knows how to implement, so it's basically just wishful thinking. For years now the C++ standard has labelled this order "temporarily discouraged" as experts tried to repair the definition and C++ 26 is slated to just deprecate it instead. Rust doesn't copy that defect.
They have a document that they sometimes describe using the word "specification", but its README clarifies that it's not actually a specification:
> The FLS is not intended to be used as the normative specification of the Rust language
To be clear, my argument doesn't hinge on whether FLS is a normative specification of Rust or not. The argument is that being "specified" is neither necessary nor sufficient for language maturity or quality.
[flagged]