6 ms·

> curious why people want this? It's important for core infrastructure to have multiple competing implementations. On a related note, does Rust have a standard

by Reelin 7y ago

> curious why people want this? It's important for core infrastructure to have multiple competing implementations. On a related note, does Rust have a standard yet or are they still doing the reference implementation thing? > I was under the impression that llvm is better than gcc? And I thought that tabs were better than spaces, BSD beat Linux, Emacs was the one true god... what were we arguing about again?

sanxiyn 7y ago
Rust has no reasonable specification yet although it is being worked on.
- bluejekyll 7y ago
  I would say that rust doesn’t have a formal specification, what it does have is close to or better than many languages “specs” with the “Rust Reference”: https://doc.rust-lang.org/stable/reference/ https://doc.rust-lang.org/stable/reference/ It really depends on how strictly you define the term specification. The Rust Reference is not required to be accurate. Though many other language compilers/implementations don’t fully implement their respective specs so, :shrug:.
  - mjw1007 7y ago
    The Rust Reference is very far from being complete, or even correct in what it does cover. If I have a question whose answer isn't obvious, it's far more likely that I have to go trawling around in RFCs than that there's an answer in the reference. I think most languages of a similar age (eg Go, Swift) are doing better.
    - littlestymaar 7y ago
      Rust is younger than Go (released in 2015 vs 2012) and way more ambitious, especially Rust 1.0 was released as kind of an MVP and many things have changed since then, which made the maintenance of such a reference an issue. The pace of change is slowing nowadays (that's especially visible if you look new and accepted RFCs), so I hope the reference will catch up eventually.
  - clarus 7y ago
    There are some people studying Rust with formal verification. For example in this paper https://plv.mpi-sws.org/rustbelt/rbrlx/paper.pdf https://plv.mpi-sws.org/rustbelt/rbrlx/paper.pdf However I do not know if the whole language is covered or only a core.
    - sanxiyn 7y ago
      The big gap with RustBelt is that it does not cover traits. This actually does matter: some bugs were missed because they interact with traits.
- cbmuser 7y ago
  Which is the main reason why no usable alternative implementations exist yet and why Rust hasn't found its way to more low-level software projects like the Linux plumberland yet. Rust dearly needs a stable specification, it is the main blocker why the language hasn't been more widely adopted.
  - galangalalgol 7y ago
    Rust has LTS like releases based on years, but the last one didnt have async await so everyone just kept tracking. I think the nexts LTS type release may snag some people and slow stuff down. Cargo should handle that fine, but not sure about maintainers. I cant get cargo in my day job, just the rustc 1.3x shipped with rhel, so I'm already standing still. Rhel's version migh make a good defacto lts in the absence of cargo, but the thin std lib makes that hard, and random old rustc versions sometimes don't play nice with every crate.
    - pietroalbini 7y ago
      Rust doesn't have LTS releases. Editions are both a way to market the new features introduced in the past years as a "bundle" to outside users, and a way for us to introduce some breaking changes for the users opting into the new edition. The release an edition is stabilized in (1.31 for Rust 2018) does not get any special treatment from the Rust team though, and that includes no LTS support (for example we won't backport bug fixes, even security ones).
      - galangalalgol 7y ago
        Yikes! I had no idea. It takes my company years sometimes to approve a new point release of software. Rhel subscription was my backdoor to get rust at work. I knew I'd never get a cargo access or a mirror approved, but i thought some day I'd push for an lts release. I don't see my company ever doing sw approval and transfer to our development network faster than once a year.
        pietroalbini 7y ago
mjw1007 7y ago
I don't think Rust is even defined by a reference implementation, given that they release a new compiler every six weeks. For many practical purposes I think the closest thing to a language definition is the set of testsuites visible to Crater. (That is: when the compiler people are considering a change, they don't say "we can't change this because we're past 1.0 and the change is technically backwards-incompatible", or "we can't change this because the Reference specifies the current behaviour"; they say "let's do a Crater run and see if anything breaks".)
- steveklabnik 7y ago
  This is not correct. We do use crater to help with questionable cases, but we often say “we can’t change this because we’re past 1.0 and the change is backwards incompatible.”
  - umanwizard 7y ago
    Which is still not the same as having a spec or even a reference implementation. It’s a bit weird how laser-focused the Rust community is on backwards compatibility, not seeming to believe that forward compatibility is also important. e.g., if I write code targeting C++17, I can be reasonably sure it compiles with an older version of the compiler, as long as that version also claims to support C++17, modulo bugs. Not the case if I write code targeting Rust 2015 as they’re still adding features to that from time to time. Let alone Rust 2018 which changes every 6 weeks. Will there ever be a version of Rust that the community agrees “OK, this language definition is not changing unless we find some major soundness bug” ? This is a big blocker for mainstream adoption in Linux distributions since the maintainer wants to be able to land one specific version of rustc in the repositories, not rely on people downloading new versions with rustup continuously. But old versions of rustc are effectively useless due to the lack of forward compatibility guarantees.
    - sanxiyn 7y ago
      It's not that Rust community ignores forward compatibility, it's just that right now is not the right time. Things recently landing on Rust is not new stuffs. Most of them were designed in, like, 2017. It just took years to stabilize.
sfink 7y ago
My impression is that gcc produces smaller code that is roughly comparable with clang in terms of runtime performance (with a slight advantage when compiling the codebase I care about the most). Gcc has better debug info, especially when optimizing. I don't know about compile speeds. Clang has better infrastructure for writing static analysis tools. Clang is a much more realistic alternative to msvc on windows than gcc is. I don't know about their development velocities. Clang seems to have the edge in mindshare. I'd be curious to know whether this would provide cross-language outlining during LTO using gcc. I believe some form of this is possible with llvm?
- Reelin 7y ago
  My understanding is that LTO (and thus any cross-language inlining) takes place using a low level IR where language barriers aren't relevant. The GCC and LLVM backends both have full support as far as I know. Hypothetically it's simple to implement support in a given frontend, but apparently it proved to be a bit tricky in practice for Rust (http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-...).

by Reelin 7y ago

sanxiyn 7y ago

Rust has no reasonable specification yet although it is being worked on.

bluejekyll 7y ago
I would say that rust doesn’t have a formal specification, what it does have is close to or better than many languages “specs” with the “Rust Reference”: https://doc.rust-lang.org/stable/reference/ https://doc.rust-lang.org/stable/reference/ It really depends on how strictly you define the term specification. The Rust Reference is not required to be accurate. Though many other language compilers/implementations don’t fully implement their respective specs so, :shrug:.
- mjw1007 7y ago
  The Rust Reference is very far from being complete, or even correct in what it does cover. If I have a question whose answer isn't obvious, it's far more likely that I have to go trawling around in RFCs than that there's an answer in the reference. I think most languages of a similar age (eg Go, Swift) are doing better.
  - littlestymaar 7y ago
    Rust is younger than Go (released in 2015 vs 2012) and way more ambitious, especially Rust 1.0 was released as kind of an MVP and many things have changed since then, which made the maintenance of such a reference an issue. The pace of change is slowing nowadays (that's especially visible if you look new and accepted RFCs), so I hope the reference will catch up eventually.
- clarus 7y ago
  There are some people studying Rust with formal verification. For example in this paper https://plv.mpi-sws.org/rustbelt/rbrlx/paper.pdf https://plv.mpi-sws.org/rustbelt/rbrlx/paper.pdf However I do not know if the whole language is covered or only a core.
  - sanxiyn 7y ago
    The big gap with RustBelt is that it does not cover traits. This actually does matter: some bugs were missed because they interact with traits.
cbmuser 7y ago
Which is the main reason why no usable alternative implementations exist yet and why Rust hasn't found its way to more low-level software projects like the Linux plumberland yet. Rust dearly needs a stable specification, it is the main blocker why the language hasn't been more widely adopted.
- galangalalgol 7y ago
  Rust has LTS like releases based on years, but the last one didnt have async await so everyone just kept tracking. I think the nexts LTS type release may snag some people and slow stuff down. Cargo should handle that fine, but not sure about maintainers. I cant get cargo in my day job, just the rustc 1.3x shipped with rhel, so I'm already standing still. Rhel's version migh make a good defacto lts in the absence of cargo, but the thin std lib makes that hard, and random old rustc versions sometimes don't play nice with every crate.
  - pietroalbini 7y ago
    Rust doesn't have LTS releases. Editions are both a way to market the new features introduced in the past years as a "bundle" to outside users, and a way for us to introduce some breaking changes for the users opting into the new edition. The release an edition is stabilized in (1.31 for Rust 2018) does not get any special treatment from the Rust team though, and that includes no LTS support (for example we won't backport bug fixes, even security ones).
    - galangalalgol 7y ago
      Yikes! I had no idea. It takes my company years sometimes to approve a new point release of software. Rhel subscription was my backdoor to get rust at work. I knew I'd never get a cargo access or a mirror approved, but i thought some day I'd push for an lts release. I don't see my company ever doing sw approval and transfer to our development network faster than once a year.
      - pietroalbini 7y ago

mjw1007 7y ago

I don't think Rust is even defined by a reference implementation, given that they release a new compiler every six weeks. For many practical purposes I think the closest thing to a language definition is the set of testsuites visible to Crater. (That is: when the compiler people are considering a change, they don't say "we can't change this because we're past 1.0 and the change is technically backwards-incompatible", or "we can't change this because the Reference specifies the current behaviour"; they say "let's do a Crater run and see if anything breaks".)

steveklabnik 7y ago
This is not correct. We do use crater to help with questionable cases, but we often say “we can’t change this because we’re past 1.0 and the change is backwards incompatible.”
- umanwizard 7y ago
  Which is still not the same as having a spec or even a reference implementation. It’s a bit weird how laser-focused the Rust community is on backwards compatibility, not seeming to believe that forward compatibility is also important. e.g., if I write code targeting C++17, I can be reasonably sure it compiles with an older version of the compiler, as long as that version also claims to support C++17, modulo bugs. Not the case if I write code targeting Rust 2015 as they’re still adding features to that from time to time. Let alone Rust 2018 which changes every 6 weeks. Will there ever be a version of Rust that the community agrees “OK, this language definition is not changing unless we find some major soundness bug” ? This is a big blocker for mainstream adoption in Linux distributions since the maintainer wants to be able to land one specific version of rustc in the repositories, not rely on people downloading new versions with rustup continuously. But old versions of rustc are effectively useless due to the lack of forward compatibility guarantees.
  - sanxiyn 7y ago
    It's not that Rust community ignores forward compatibility, it's just that right now is not the right time. Things recently landing on Rust is not new stuffs. Most of them were designed in, like, 2017. It just took years to stabilize.

sfink 7y ago

My impression is that gcc produces smaller code that is roughly comparable with clang in terms of runtime performance (with a slight advantage when compiling the codebase I care about the most). Gcc has better debug info, especially when optimizing. I don't know about compile speeds. Clang has better infrastructure for writing static analysis tools. Clang is a much more realistic alternative to msvc on windows than gcc is. I don't know about their development velocities. Clang seems to have the edge in mindshare. I'd be curious to know whether this would provide cross-language outlining during LTO using gcc. I believe some form of this is possible with llvm?

Reelin 7y ago
My understanding is that LTO (and thus any cross-language inlining) takes place using a low level IR where language barriers aren't relevant. The GCC and LLVM backends both have full support as far as I know. Hypothetically it's simple to implement support in a given frontend, but apparently it proved to be a bit tricky in practice for Rust (http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-...).