4 ms·

I agree in general, but I do feel like one counterargument needs to be brought up: > Most languages do not (have a formal specification) Most languages also a

I agree in general, but I do feel like one counterargument needs to be brought up: > Most languages do not (have a formal specification) Most languages also aren't trying to replace languages that do. C and C++ are both languages that Rust, afaik rather officially, aims to replace in some areas. It can be a great language like so many others, but if it wants to replace these old giants, it needs to have a proper spec, maybe in the form of an ISO standard. Of course that will come when its time, but thats a good indicator of when a language can compete as an answer to the question of "what tech will we use for our next big, important and highly specialized project?". This is the pertect indicator of it not being as mature as what it aims to replace.

steveklabnik 6y ago
Sure, though you can make an argument about the relative merits; it is possible that the heavyweight ISO process would have strangled Rust had we started there too early. I do agree that this is why "maturity" is a decent framing for this criticism, after all, C did not have a spec at this point in it's life. And also, about the invocation of "formal" there...
- derefr 6y ago
  The difficulty in something like an ISO standard comes from conflicts between stake-holders, not really anything intrinsic to drafting a standard. In C's case, the problem is that many compilers are developed for C at cross-purposes to one-another; GCC and Clang want different things from C than embedded-cross-compiler toolchain authors do; than JIT authors do; than creators of "child" languages like Objective-C or OpenCL C do; etc. The "work" of C standardization is in getting these people to compromise. Rust doesn't have that problem; there aren't yet any alternative Rust compilers that have any other purpose than to run as a batch-scheduled crate-at-a-time compile step at the command-line. In such a case, where there's only one real stake-holder, "standardization" becomes less about declaring what should happen; and more about specifying what does happen, in exacting detail, such that someone could build an alternative conforming implementation from the spec without looking at the source of your reference implementation. I don't feel like the existence of such a descriptive specification would have "strangled Rust" at any point. At most, this would have roughly doubled the work of any fix: writing the code, and then writing the change in the spec. But it wouldn't have actually been double the overall labor overhead, since the increased clarity-of-purpose of modifying the spec to declare a change in intention, would likely have mooted a lot of requesting-clarification and debating at code-review time. But besides, software-engineering as a discipline now has tools like Behavior-Driven Development to minimize the costs of maintaining a parallel descriptive spec for a project. BDD tests are just regular tests that embed a lot of descriptive strings in them—those strings being words you are already mostly thinking at the time of writing the test. So they're only a little more costly than writing ordinary tests (which the Rust compiler already has), yet can also be compiled out into a descriptive spec. (And then you can diff the generated spec, between versions, and turn that diff into the spec errata for the "minor specification addendum" of that minor release.)
  - steveklabnik 6y ago
    > The difficulty in something like an ISO standard comes from conflicts between stake-holders, not really anything intrinsic to drafting a standard. Sort of, ISO has some rules that are antithetical to Rust's ethos, like requiring that conversations not be recorded. Rust's development chooses when to be public and when to be private where it makes sense. I don't actually know if the "meet in person" aspect is a formal ISO rule or a peculiarity of the C and C++ committees, but that would be another vast difference that matters a lot. Especially at this historical moment. > Rust doesn't have that problem; We do have this problem, it's just not driven by compiler authors, but by the relevant stakeholders directly. The language team and the compiler team, while sharing some people, are separate. > less about declaring what should happen; and more about specifying what does happen This is not how the process plays out in Rust, though you're right that it could, if the compiler team wanted to act in bad faith.
TheCoelacanth 6y ago
C was almost 20 years old by the time it got a standard. It's clearly not that critical.
weinzierl 6y ago
I'd argue that when Rust is considered as an alternative in one of the domains that C and C++ are prevalent today, the fact that it does not have a formalized spec does actually hurt it today. For example: NVidia evaluated various languages to adopt for their "Safe Autonomous Driving" project. Rust was considered but didn't win. One of the reasons was literally: "Does not have a formalized spec" See [1] page 35. [1] https://www.slideshare.net/AdaCore/securing-the-future-of-safety-and-security-of-embedded-software https://www.slideshare.net/AdaCore/securing-the-future-of-sa...
- lionkor 6y ago
  The nvidia thing is part of why I wrote my comment, too, yeah. Was really eye opening to the requirements that some big players have

steveklabnik 6y ago

Sure, though you can make an argument about the relative merits; it is possible that the heavyweight ISO process would have strangled Rust had we started there too early. I do agree that this is why "maturity" is a decent framing for this criticism, after all, C did not have a spec at this point in it's life. And also, about the invocation of "formal" there...

derefr 6y ago
The difficulty in something like an ISO standard comes from conflicts between stake-holders, not really anything intrinsic to drafting a standard. In C's case, the problem is that many compilers are developed for C at cross-purposes to one-another; GCC and Clang want different things from C than embedded-cross-compiler toolchain authors do; than JIT authors do; than creators of "child" languages like Objective-C or OpenCL C do; etc. The "work" of C standardization is in getting these people to compromise. Rust doesn't have that problem; there aren't yet any alternative Rust compilers that have any other purpose than to run as a batch-scheduled crate-at-a-time compile step at the command-line. In such a case, where there's only one real stake-holder, "standardization" becomes less about declaring what should happen; and more about specifying what does happen, in exacting detail, such that someone could build an alternative conforming implementation from the spec without looking at the source of your reference implementation. I don't feel like the existence of such a descriptive specification would have "strangled Rust" at any point. At most, this would have roughly doubled the work of any fix: writing the code, and then writing the change in the spec. But it wouldn't have actually been double the overall labor overhead, since the increased clarity-of-purpose of modifying the spec to declare a change in intention, would likely have mooted a lot of requesting-clarification and debating at code-review time. But besides, software-engineering as a discipline now has tools like Behavior-Driven Development to minimize the costs of maintaining a parallel descriptive spec for a project. BDD tests are just regular tests that embed a lot of descriptive strings in them—those strings being words you are already mostly thinking at the time of writing the test. So they're only a little more costly than writing ordinary tests (which the Rust compiler already has), yet can also be compiled out into a descriptive spec. (And then you can diff the generated spec, between versions, and turn that diff into the spec errata for the "minor specification addendum" of that minor release.)
- steveklabnik 6y ago
  > The difficulty in something like an ISO standard comes from conflicts between stake-holders, not really anything intrinsic to drafting a standard. Sort of, ISO has some rules that are antithetical to Rust's ethos, like requiring that conversations not be recorded. Rust's development chooses when to be public and when to be private where it makes sense. I don't actually know if the "meet in person" aspect is a formal ISO rule or a peculiarity of the C and C++ committees, but that would be another vast difference that matters a lot. Especially at this historical moment. > Rust doesn't have that problem; We do have this problem, it's just not driven by compiler authors, but by the relevant stakeholders directly. The language team and the compiler team, while sharing some people, are separate. > less about declaring what should happen; and more about specifying what does happen This is not how the process plays out in Rust, though you're right that it could, if the compiler team wanted to act in bad faith.

TheCoelacanth 6y ago

C was almost 20 years old by the time it got a standard. It's clearly not that critical.

weinzierl 6y ago

I'd argue that when Rust is considered as an alternative in one of the domains that C and C++ are prevalent today, the fact that it does not have a formalized spec does actually hurt it today. For example: NVidia evaluated various languages to adopt for their "Safe Autonomous Driving" project. Rust was considered but didn't win. One of the reasons was literally: "Does not have a formalized spec" See [1] page 35. [1] https://www.slideshare.net/AdaCore/securing-the-future-of-safety-and-security-of-embedded-software https://www.slideshare.net/AdaCore/securing-the-future-of-sa...

lionkor 6y ago
The nvidia thing is part of why I wrote my comment, too, yeah. Was really eye opening to the requirements that some big players have