3 ms·

The currently flagged comment and the discussion below it actually do have a salient point. Comment: How about get an actual published language standard? How a

by troupo 1y ago

The currently flagged comment and the discussion below it actually do have a salient point. Comment: How about get an actual published language standard? How about get more implementations of it? In the discussion, @infogulch: If you are aiming to be the foundation of an entire industry it doesn't seem unreasonable to ask for some specifications. https://news.ycombinator.com/item?id=44926375 https://news.ycombinator.com/item?id=44926375 I agree with @infogulch

dgfitz 1y ago
As do I. Because I’m a cynical person, I view LLMs like I’ve viewed rust for years: a neat tool that makes a small subset of people happy and a touch more productive. The evangelical defense of either topic is very off-putting, to say the least. @infogulch really nailed it with the comment about how the rust community wants influence/power, and ignores the responsibility that comes with said influence/power.
- sitkack 1y ago
  Python still has no standard and open antagonistic towards refactoring their standard library so that the language and the library aren't shipped as a monolith. The most difficult part for alternative Python implementations is supporting the same stdlib.
  - msgodel 1y ago
    No one seriously tries to write operating systems or large components of operating systems in python, it's very much a "hacking" language.
    - testdelacc1 1y ago
      Why does a language in which you write operating systems need a spec or a second compiler? You have a compiler, that’s MIT licensed. It will be MIT licensed in perpetuity. It will continue to compile your code forever, with absolutely no changes needed to your code. How precisely, does your life change if there is a second compiler or not? Or if there’s an spec? And more interestingly, why does it affect only operating systems development and not web server development?
      - troupo 1y ago
        A second compiler means competition. Different approaches. Better solutions that the original compiler may have missed. We see it time and again across anything that has two implementations.
        testdelacc1 1y ago
        That’s possible in theory, but do you think that’s what’s needed to improve the Rust compiler in practice? The pace of development is pretty good, to the point where one of the main criticisms of Rust is that it moves too quickly. The stability is pretty good, I can only remember one time when code was broken. Compile times are mediocre but three ambitious projects hope to tackle that - parallel frontend, cranelift backend, changing the default linker to a better one(landing next month). This argument would carry more weight if you could point out something specific that the Rust project isn’t addressing but might address if an alternate implementation existed. Remembering of course, that the second implementation would have to be compatible with the OG implementation.
        troupo 1y ago
        > That’s possible in theory, but do you think that’s what’s needed to improve the Rust compiler in practice? We don't know because we don't, and can't, have a competing compiler. For all languages that have competing compilers they all improve on each other.
        testdelacc1 1y ago
        Sorry, that’s a cop out. If you don’t know in what way Rust needs to be improved, you don’t know enough to be making confident pronouncements of what it needs. And like I’ve pointed out before on this thread, a second compiler does exist. It could help with bootstrapping because it’s written in C++ but that’s about it? Plenty of successful languages have just the one implementation. Python is a great example. Slowing down python development by making everyone proposing a new feature have to convince two separate teams to adopt it wouldn’t help either the Python ecosystem or the Rust one. Frankly, this thread has gone like every other thread on this subject. Advocates for a spec and second compiler are unable to come up with technical arguments in favour of it. Instead they simply say “well I’ve seen it done by this other language, so it should be done here as well.” That’s just cargo culting. The only thing different about this thread is hearing from people that work in progress spec and second compiler aren’t enough. No, it needs to be ready right now!!! Yeah alright.
  - testdelacc1 1y ago
    I wouldn’t worry about it. Python will never become popular.
    - sitkack 1y ago
      Python is too popular, no one uses it anymore.
jenadine 1y ago
Could you elaborate what "published language standard" exactly mean and what it would help for?
- testdelacc1 1y ago
  I can’t speak for them, but here’s the Rust project’s rationale on writing a spec when they started on it: Our Vision for the Rust Specification (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). I do find it curious that the people who write comments demanding a spec and alternate implementations aren’t aware of the work-in-progress spec and alternate implementations.
  - StopDisinfo910 1y ago
    They are aware. They are also aware that it’s been going nowhere for quite sometimes. Plus it’s still viewed as non authoritative. A non authoritative specification is basically worthless. Actually that might be why it’s going nowhere.
    - testdelacc1 1y ago
      > getting nowhere Would it surprise you to learn that they’re making steady progress, even merging in two PRs two hours ago? https://github.com/rust-lang/reference https://github.com/rust-lang/reference
      - troupo 1y ago
        A sibling comment argues that it's still work that is basically stalled: https://news.ycombinator.com/item?id=44927519 https://news.ycombinator.com/item?id=44927519
        testdelacc1 1y ago
        I saw that. To which I say, git appears to disagree. If you look at the contributor graph for the reference (https://github.com/rust-lang/reference/graphs/contributors https://github.com/rust-lang/reference/graphs/contributors) you’ll find 327 contributions in 2024 H2 and 322 contributions in 2025 H1. That’s the highest and second highest rate of contribution to the repo by some distance. People see what they want to see. They complain no matter what. Remember this thread started with “there’s no spec”, then “the spec work has been abandoned”, then “the spec work isn’t going fast enough”. When they’re moving the goalposts this fast it’s hard to keep up. Especially because, like my other comment says, it’s not clear what they’d actually use the spec for.
testdelacc1 1y ago
> How about get an actual published language standard? I’m curious, did you Google before writing this comment? I did just now and the first result I found is https://github.com/rust-lang/reference https://github.com/rust-lang/reference. This is something the Rust project is taking very seriously. You can read up on their approach in this detailed blog post from November 2023 - Our Vision for the Rust Specification (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). This is an ambitious and difficult project that is a work in progress. They’re continuing to work hard at it. There were 2 PRs merged to master less than 2 hours ago when I wrote this comment. On a Saturday, that’s commitment right there. > How about get more implementations of it? Here’s what another quick google search yielded. From the official Rust blog, published November 2024: gccrs: An alternative compiler for Rust (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust/ https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...) Hope that helps dispel the confusion around the lack of spec or alternate implementation.
- jmull 1y ago
  I hope this is clear: the published language standard the previous poster was asking about does not currently exist. You linked to efforts to create a specification, but they aren't done or close to done. It's also not clear the goal is to create a standard. E.g., according to the spec-vision document, the spec isn't planned to be authoritative (the implementation is). If that doesn't change the spec can't really function as a standard. (A standard would allow independent implementations and independent validation of an implementation. A non-authoritative spec doesn't.)
  - testdelacc1 1y ago
    If it is impossible to create an alternate implementation without a spec, is that contradicted by the existence of Gccrs?
    - jmull 1y ago
      Gccrs an effort to create an alternate compatible implementation. It hasn't yet created a generally usable compiler. I'm sure they would be among the most interested in a spec. They are currently forced to use the implementation (continuously evolving) as the spec. That makes their job considerably more difficult.
woodruffw 1y ago
I think it’s flagged (although I don’t have an opinion on whether it should be) because it’s not clear at all whether it’s actually a reasonable thing to expect: plenty of industries are built on programming languages that don’t have formal specifications, much less natural language ones. To argue by example: Ruby has an ISO standard, but that standard is for a very old version of the language. Python doesn’t have an independent standard at all; it’s like Rust in that the reference implementation is itself the standard. But nobody is champing at the bit to replace their Ruby or Python stack for standards reasons.
- hitekker 1y ago
  Rust's leadership wanted a formal specification. They thought it's reasonable. Hence, why they invested in a team to build a spec https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio... One of the founding members wrote a blog post & RFC which gives some good reasons why a spec is needed https://blog.m-ou.se/rust-standard https://blog.m-ou.se/rust-standard https://rust-lang.github.io/rfcs/3355-rust-spec.html https://rust-lang.github.io/rfcs/3355-rust-spec.html
- logicchains 1y ago
  Nobody is champing at the bit to rewrite the OS stack in Ruby or Python.
  - woodruffw 1y ago
    Who said they are? The GP's language is "foundation of an entire industry"; I would argue that you and I could both find plenty of industries that directly attribute their foundations to those languages.
    - dingi 1y ago
      In what way Ruby and Python are foundations for entire industries? As I see, these two are just surface level languages which mostly use C/C++ under the hood.
voidhorse 1y ago
I don't have gripes with Rust per se, but I do take issue with the contingent of commenters that seem to not understand the value of a formal specification in the construction of formal computational systems in the first place. Basically every computational system lives and dies on its degree of formal specifiability, and having more formal specification is always better unless you are cool with being beholden to the fact that some particular implementation of some program happened to work at some point in time for some input once. That insecure ground is what you're standing on if you don't think formal specifications have any value. In the world of computation, the specification is the system, modulo incidental properties of implementation like performance.
- aw1621107 1y ago
  > in the construction of formal computational systems > Basically every computational system lives and dies on its degree of formal specifiability How much software development work would you say qualifies as "construction of formal computational systems"? I feel like I have to be thinking of something different than you because to a first approximation I think ~no software has much in the way of formal specification done on it, if any at all. I feel like there's a bit of black-and-white thinking here as well. It's not as if you pick either "full formal specification with bonus Lean/Coq/etc." or "YOLO" - there's shades of grey in between where you can nail down different bits with more or less specificity/formality/etc. depending on feasibility/priorities/etc. Same with support for/against a formal spec - there's more nuance than "an absolute necessity" or "a waste of time".
  - voidhorse 1y ago
    > How much software development work would you say qualifies as "construction of formal computational systems"? All of it. That's a literal definition of what a piece of software is, a formal system for computing things. Whether we realize it or like it or not, that's what we are doing when we build software, and that's why formalization of implementation-independent details is almost always beneficial. Sure, you don't always need to do this formalization in Lean or something, but you should at least have a document that outlines the behaviors of the system, it's invariants, etc. etc. Simply pointing people at a codebase and saying "there it is" or making the present, incidental behavior of an implementation the source of truth is like building a bridge and answering the question "how do we know it won't collapse under load X" by answering "idk put the load on it and see". I know it sounds a bit extreme, but I actually would stick to my original stance here. If you have an implementation but haven't worked out its design formally then you probably have a buggy implementation. An aversion and under appreciation of formalism is far more endemic in contemporary software development than a penchant for it is. Arguably, if people in the industry took the title of "engineer" a little more seriously, we'd have better systems. Civil engineers work out formal specifications for bridges even when they are working on a tiny foot bridge in a park, why? because that's basically the whole job. They don't throw their hands in the air and just say "a formal spec ain't worth it, just build the bridge intuitively"—plenty of bridges are built this way, but we don't call those builders engineers, and for good reason. I completely agree that in reality, we often cannot achieve the ideal precisely for the reasons you described. Constraints may make it infeasible. But for the particular case of Rust, I'd argue that that isn't the case, and my point is more so that those entertaining the idea that formal specification doesn't even have value might be doing something with computers, but it isn't engineering.

by troupo 1y ago

dgfitz 1y ago

As do I. Because I’m a cynical person, I view LLMs like I’ve viewed rust for years: a neat tool that makes a small subset of people happy and a touch more productive. The evangelical defense of either topic is very off-putting, to say the least. @infogulch really nailed it with the comment about how the rust community wants influence/power, and ignores the responsibility that comes with said influence/power.

sitkack 1y ago
Python still has no standard and open antagonistic towards refactoring their standard library so that the language and the library aren't shipped as a monolith. The most difficult part for alternative Python implementations is supporting the same stdlib.
- msgodel 1y ago
  No one seriously tries to write operating systems or large components of operating systems in python, it's very much a "hacking" language.
  - testdelacc1 1y ago
    Why does a language in which you write operating systems need a spec or a second compiler? You have a compiler, that’s MIT licensed. It will be MIT licensed in perpetuity. It will continue to compile your code forever, with absolutely no changes needed to your code. How precisely, does your life change if there is a second compiler or not? Or if there’s an spec? And more interestingly, why does it affect only operating systems development and not web server development?
    - troupo 1y ago
      A second compiler means competition. Different approaches. Better solutions that the original compiler may have missed. We see it time and again across anything that has two implementations.
      - testdelacc1 1y ago
        That’s possible in theory, but do you think that’s what’s needed to improve the Rust compiler in practice? The pace of development is pretty good, to the point where one of the main criticisms of Rust is that it moves too quickly. The stability is pretty good, I can only remember one time when code was broken. Compile times are mediocre but three ambitious projects hope to tackle that - parallel frontend, cranelift backend, changing the default linker to a better one(landing next month). This argument would carry more weight if you could point out something specific that the Rust project isn’t addressing but might address if an alternate implementation existed. Remembering of course, that the second implementation would have to be compatible with the OG implementation.
        troupo 1y ago
        > That’s possible in theory, but do you think that’s what’s needed to improve the Rust compiler in practice? We don't know because we don't, and can't, have a competing compiler. For all languages that have competing compilers they all improve on each other.
        testdelacc1 1y ago
        Sorry, that’s a cop out. If you don’t know in what way Rust needs to be improved, you don’t know enough to be making confident pronouncements of what it needs. And like I’ve pointed out before on this thread, a second compiler does exist. It could help with bootstrapping because it’s written in C++ but that’s about it? Plenty of successful languages have just the one implementation. Python is a great example. Slowing down python development by making everyone proposing a new feature have to convince two separate teams to adopt it wouldn’t help either the Python ecosystem or the Rust one. Frankly, this thread has gone like every other thread on this subject. Advocates for a spec and second compiler are unable to come up with technical arguments in favour of it. Instead they simply say “well I’ve seen it done by this other language, so it should be done here as well.” That’s just cargo culting. The only thing different about this thread is hearing from people that work in progress spec and second compiler aren’t enough. No, it needs to be ready right now!!! Yeah alright.
- testdelacc1 1y ago
  I wouldn’t worry about it. Python will never become popular.
  - sitkack 1y ago
    Python is too popular, no one uses it anymore.

jenadine 1y ago

Could you elaborate what "published language standard" exactly mean and what it would help for?

testdelacc1 1y ago
I can’t speak for them, but here’s the Rust project’s rationale on writing a spec when they started on it: Our Vision for the Rust Specification (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). I do find it curious that the people who write comments demanding a spec and alternate implementations aren’t aware of the work-in-progress spec and alternate implementations.
- StopDisinfo910 1y ago
  They are aware. They are also aware that it’s been going nowhere for quite sometimes. Plus it’s still viewed as non authoritative. A non authoritative specification is basically worthless. Actually that might be why it’s going nowhere.
  - testdelacc1 1y ago
    > getting nowhere Would it surprise you to learn that they’re making steady progress, even merging in two PRs two hours ago? https://github.com/rust-lang/reference https://github.com/rust-lang/reference
    - troupo 1y ago
      A sibling comment argues that it's still work that is basically stalled: https://news.ycombinator.com/item?id=44927519 https://news.ycombinator.com/item?id=44927519
      - testdelacc1 1y ago
        I saw that. To which I say, git appears to disagree. If you look at the contributor graph for the reference (https://github.com/rust-lang/reference/graphs/contributors https://github.com/rust-lang/reference/graphs/contributors) you’ll find 327 contributions in 2024 H2 and 322 contributions in 2025 H1. That’s the highest and second highest rate of contribution to the repo by some distance. People see what they want to see. They complain no matter what. Remember this thread started with “there’s no spec”, then “the spec work has been abandoned”, then “the spec work isn’t going fast enough”. When they’re moving the goalposts this fast it’s hard to keep up. Especially because, like my other comment says, it’s not clear what they’d actually use the spec for.

testdelacc1 1y ago

> How about get an actual published language standard? I’m curious, did you Google before writing this comment? I did just now and the first result I found is https://github.com/rust-lang/reference https://github.com/rust-lang/reference. This is something the Rust project is taking very seriously. You can read up on their approach in this detailed blog post from November 2023 - Our Vision for the Rust Specification (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). This is an ambitious and difficult project that is a work in progress. They’re continuing to work hard at it. There were 2 PRs merged to master less than 2 hours ago when I wrote this comment. On a Saturday, that’s commitment right there. > How about get more implementations of it? Here’s what another quick google search yielded. From the official Rust blog, published November 2024: gccrs: An alternative compiler for Rust (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust/ https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...) Hope that helps dispel the confusion around the lack of spec or alternate implementation.

jmull 1y ago
I hope this is clear: the published language standard the previous poster was asking about does not currently exist. You linked to efforts to create a specification, but they aren't done or close to done. It's also not clear the goal is to create a standard. E.g., according to the spec-vision document, the spec isn't planned to be authoritative (the implementation is). If that doesn't change the spec can't really function as a standard. (A standard would allow independent implementations and independent validation of an implementation. A non-authoritative spec doesn't.)
- testdelacc1 1y ago
  If it is impossible to create an alternate implementation without a spec, is that contradicted by the existence of Gccrs?
  - jmull 1y ago
    Gccrs an effort to create an alternate compatible implementation. It hasn't yet created a generally usable compiler. I'm sure they would be among the most interested in a spec. They are currently forced to use the implementation (continuously evolving) as the spec. That makes their job considerably more difficult.

woodruffw 1y ago

I think it’s flagged (although I don’t have an opinion on whether it should be) because it’s not clear at all whether it’s actually a reasonable thing to expect: plenty of industries are built on programming languages that don’t have formal specifications, much less natural language ones. To argue by example: Ruby has an ISO standard, but that standard is for a very old version of the language. Python doesn’t have an independent standard at all; it’s like Rust in that the reference implementation is itself the standard. But nobody is champing at the bit to replace their Ruby or Python stack for standards reasons.

hitekker 1y ago
Rust's leadership wanted a formal specification. They thought it's reasonable. Hence, why they invested in a team to build a spec https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision/ https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio... One of the founding members wrote a blog post & RFC which gives some good reasons why a spec is needed https://blog.m-ou.se/rust-standard https://blog.m-ou.se/rust-standard https://rust-lang.github.io/rfcs/3355-rust-spec.html https://rust-lang.github.io/rfcs/3355-rust-spec.html
logicchains 1y ago
Nobody is champing at the bit to rewrite the OS stack in Ruby or Python.
- woodruffw 1y ago
  Who said they are? The GP's language is "foundation of an entire industry"; I would argue that you and I could both find plenty of industries that directly attribute their foundations to those languages.
  - dingi 1y ago
    In what way Ruby and Python are foundations for entire industries? As I see, these two are just surface level languages which mostly use C/C++ under the hood.

voidhorse 1y ago

I don't have gripes with Rust per se, but I do take issue with the contingent of commenters that seem to not understand the value of a formal specification in the construction of formal computational systems in the first place. Basically every computational system lives and dies on its degree of formal specifiability, and having more formal specification is always better unless you are cool with being beholden to the fact that some particular implementation of some program happened to work at some point in time for some input once. That insecure ground is what you're standing on if you don't think formal specifications have any value. In the world of computation, the specification is the system, modulo incidental properties of implementation like performance.

aw1621107 1y ago
> in the construction of formal computational systems > Basically every computational system lives and dies on its degree of formal specifiability How much software development work would you say qualifies as "construction of formal computational systems"? I feel like I have to be thinking of something different than you because to a first approximation I think ~no software has much in the way of formal specification done on it, if any at all. I feel like there's a bit of black-and-white thinking here as well. It's not as if you pick either "full formal specification with bonus Lean/Coq/etc." or "YOLO" - there's shades of grey in between where you can nail down different bits with more or less specificity/formality/etc. depending on feasibility/priorities/etc. Same with support for/against a formal spec - there's more nuance than "an absolute necessity" or "a waste of time".
- voidhorse 1y ago
  > How much software development work would you say qualifies as "construction of formal computational systems"? All of it. That's a literal definition of what a piece of software is, a formal system for computing things. Whether we realize it or like it or not, that's what we are doing when we build software, and that's why formalization of implementation-independent details is almost always beneficial. Sure, you don't always need to do this formalization in Lean or something, but you should at least have a document that outlines the behaviors of the system, it's invariants, etc. etc. Simply pointing people at a codebase and saying "there it is" or making the present, incidental behavior of an implementation the source of truth is like building a bridge and answering the question "how do we know it won't collapse under load X" by answering "idk put the load on it and see". I know it sounds a bit extreme, but I actually would stick to my original stance here. If you have an implementation but haven't worked out its design formally then you probably have a buggy implementation. An aversion and under appreciation of formalism is far more endemic in contemporary software development than a penchant for it is. Arguably, if people in the industry took the title of "engineer" a little more seriously, we'd have better systems. Civil engineers work out formal specifications for bridges even when they are working on a tiny foot bridge in a park, why? because that's basically the whole job. They don't throw their hands in the air and just say "a formal spec ain't worth it, just build the bridge intuitively"—plenty of bridges are built this way, but we don't call those builders engineers, and for good reason. I completely agree that in reality, we often cannot achieve the ideal precisely for the reasons you described. Constraints may make it infeasible. But for the particular case of Rust, I'd argue that that isn't the case, and my point is more so that those entertaining the idea that formal specification doesn't even have value might be doing something with computers, but it isn't engineering.