9 ms·

And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. Just get a few rust standards out of

by rualca 6y ago

And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. Just get a few rust standards out of iso, one for the core language and another for some standard libraries, and get it over with.

piaste 6y ago
> And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. I'm not a C++ programmer but when I read C++ programmers discussing their language standard committee, "free and unconstrained by corporate interests" is usually not how they characterize it.
- usrnm 6y ago
  Of course not, but at least we have several very different corporations that have to fight and agree on the final result, instead of just one that can push whatever crap that suits its short-term interests better
  - fluffy87 6y ago
    But that’s not the case for Rust? Rust is backed by Microsoft, Amazon, Apple, Google, Facebook, Intel, and many others... The Rust development and specification happens all in the open on GitHub. There is no single company controlling its future or direction.
    - nullifidian 6y ago
      Mozilla pays salary to the core team members, who approve/decline pull requests, vote on RFCs. So far there haven't been any reasons for concern, and Mozilla is more of a dying husk without too many interests to affect rust's development, but the situation could be improved with more neutrality/independence.
      - parley 6y ago
        That is actively ongoing work: https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html https://blog.rust-lang.org/2020/08/18/laying-the-foundation-...
      - steveklabnik 6y ago
        Mozilla used to pay a salary to a handful of the 200+ folks who make these decisions. And since we operate on consensus, every member of the team must agree. So it’s never been possible for one company to completely control things. This is by design.
chrismorgan 6y ago
Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definition written down, but instead are defined by the rustc implementation: most significantly, the ownership and borrow checking system. Research towards formalising this model in a way that a specification could use is ongoing (e.g. https://people.mpi-sws.org/~jung/thesis.html https://people.mpi-sws.org/~jung/thesis.html, published a couple of months back), but until then any specification document would be unreasonably complicated and verbose, containing large chunks of the current compiler rather than describing an independently-useful model. But more generally, I think you’re approaching this from the wrong angle, perceiving a problem that doesn’t exist—Rust is already not tied to a single corporate interest. But have patience, there are rustlings of independent implementations in a few places, and their fullness will come in a few years’ time.
- pjmlp 6y ago
  Most languages aren't either, they just start the process and evolve from there. C was still mostly K&R C when the process started, and in C++ all we had was the C++ARM book.
- tannhaeuser 6y ago
  Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. And no, I don't trust the Rust propaganda machine. When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
  - 6y ago
pjmlp 6y ago
Although both are standards by accident. C because when UNIX started to get widespread, that was the way to settle difference across multiple language implementations. And C++ because Bjarne eventually settled on ISO as means to settle out the differences across the various C++ implementations that sprung off. https://www.stroustrup.com/hopl-almost-final.pdf https://www.stroustrup.com/hopl-almost-final.pdf However this is also a reason why nice tools like package managers and IDEs are ages behind, because when one vendor comes up with nice toys (C++Builder, vcpkg, CUDA), they don't land on ISO and you are stuck in one eco-system anyway.
cageface 6y ago
What’s the advantage of a formal standard when the language itself and the tools are all open source? All I can see a formal standard adding to the picture is a lot of bureaucracy and friction and the headache of subtly incompatible implementations.
- higerordermap 6y ago
  Having a spec is enough IMO. Go has one. That enables alternative implementations. There are enough reasons to not want an implementation monoculture.
  - cageface 6y ago
    What are the reasons? I see a lot of benefits of an open source monoculture, especially if corporate backing is uncertain.
    - higerordermap 6y ago
      Competition is great. If there is no competition, implementation quality stagnates. It happened with GCC, for example.
      - cageface 6y ago
        I doesn't seem like a comparable situation. There were already multiple competing C & C++ compilers including several commercial options. I don't think complacency is holding Rust back.
- nullifidian 6y ago
  I would be nice to have a document we can rely on and refer to, in case of subtle breakages and bugs. Alternative implementations could also be a possibility down the line. Having a formal spec would also help with code verification, i.e. you basically can't do it unless the language is specified.
  - 6y ago
dijit 6y ago
> And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. Is that true though? I mean the spec is so "loose" that most compilers don't even work with the same code if it has any level of serious complexity. Normally that's put under the rug of 'undefined behaviour' but imo it's a "vendored version" of the language, the most common variants being MSVC, GCC and CLANG, and even projects which make efforts to be agnostic or have many eyes (linux) can't support GCC _and_ CLANG easily.
- jononor 6y ago
  If you move up from kernel level, many projects work with multiple compilers. For example most of the underlying libraries that are part of GNOME work with MSVC, GCC and CLANG. Probably also many more, but it does not tend to be tested much.

by rualca 6y ago

piaste 6y ago

> And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. I'm not a C++ programmer but when I read C++ programmers discussing their language standard committee, "free and unconstrained by corporate interests" is usually not how they characterize it.

usrnm 6y ago
Of course not, but at least we have several very different corporations that have to fight and agree on the final result, instead of just one that can push whatever crap that suits its short-term interests better
- fluffy87 6y ago
  But that’s not the case for Rust? Rust is backed by Microsoft, Amazon, Apple, Google, Facebook, Intel, and many others... The Rust development and specification happens all in the open on GitHub. There is no single company controlling its future or direction.
  - nullifidian 6y ago
    Mozilla pays salary to the core team members, who approve/decline pull requests, vote on RFCs. So far there haven't been any reasons for concern, and Mozilla is more of a dying husk without too many interests to affect rust's development, but the situation could be improved with more neutrality/independence.
    - parley 6y ago
      That is actively ongoing work: https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html https://blog.rust-lang.org/2020/08/18/laying-the-foundation-...
    - steveklabnik 6y ago
      Mozilla used to pay a salary to a handful of the 200+ folks who make these decisions. And since we operate on consensus, every member of the team must agree. So it’s never been possible for one company to completely control things. This is by design.

chrismorgan 6y ago

Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definition written down, but instead are defined by the rustc implementation: most significantly, the ownership and borrow checking system. Research towards formalising this model in a way that a specification could use is ongoing (e.g. https://people.mpi-sws.org/~jung/thesis.html https://people.mpi-sws.org/~jung/thesis.html, published a couple of months back), but until then any specification document would be unreasonably complicated and verbose, containing large chunks of the current compiler rather than describing an independently-useful model. But more generally, I think you’re approaching this from the wrong angle, perceiving a problem that doesn’t exist—Rust is already not tied to a single corporate interest. But have patience, there are rustlings of independent implementations in a few places, and their fullness will come in a few years’ time.

pjmlp 6y ago
Most languages aren't either, they just start the process and evolve from there. C was still mostly K&R C when the process started, and in C++ all we had was the C++ARM book.
tannhaeuser 6y ago
Why would I then base a development project on Rust, if there's neither a spec nor an alternate implementation? This is strictly worse than what we have now. And no, I don't trust the Rust propaganda machine. When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser. And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
- 6y ago

pjmlp 6y ago

Although both are standards by accident. C because when UNIX started to get widespread, that was the way to settle difference across multiple language implementations. And C++ because Bjarne eventually settled on ISO as means to settle out the differences across the various C++ implementations that sprung off. https://www.stroustrup.com/hopl-almost-final.pdf https://www.stroustrup.com/hopl-almost-final.pdf However this is also a reason why nice tools like package managers and IDEs are ages behind, because when one vendor comes up with nice toys (C++Builder, vcpkg, CUDA), they don't land on ISO and you are stuck in one eco-system anyway.

cageface 6y ago

What’s the advantage of a formal standard when the language itself and the tools are all open source? All I can see a formal standard adding to the picture is a lot of bureaucracy and friction and the headache of subtly incompatible implementations.

higerordermap 6y ago
Having a spec is enough IMO. Go has one. That enables alternative implementations. There are enough reasons to not want an implementation monoculture.
- cageface 6y ago
  What are the reasons? I see a lot of benefits of an open source monoculture, especially if corporate backing is uncertain.
  - higerordermap 6y ago
    Competition is great. If there is no competition, implementation quality stagnates. It happened with GCC, for example.
    - cageface 6y ago
      I doesn't seem like a comparable situation. There were already multiple competing C & C++ compilers including several commercial options. I don't think complacency is holding Rust back.
nullifidian 6y ago
I would be nice to have a document we can rely on and refer to, in case of subtle breakages and bugs. Alternative implementations could also be a possibility down the line. Having a formal spec would also help with code verification, i.e. you basically can't do it unless the language is specified.
- 6y ago

dijit 6y ago

> And that's why languages such as C and C++ are not a reference implementation from a vendor but an international standard. Is that true though? I mean the spec is so "loose" that most compilers don't even work with the same code if it has any level of serious complexity. Normally that's put under the rug of 'undefined behaviour' but imo it's a "vendored version" of the language, the most common variants being MSVC, GCC and CLANG, and even projects which make efforts to be agnostic or have many eyes (linux) can't support GCC _and_ CLANG easily.

jononor 6y ago
If you move up from kernel level, many projects work with multiple compilers. For example most of the underlying libraries that are part of GNOME work with MSVC, GCC and CLANG. Probably also many more, but it does not tend to be tested much.