5 ms·

Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users option

by ndiddy 3y ago

Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that's not currently possible.

VBprogrammer 3y ago
I don't have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.
- cozzyd 3y ago
  It's pretty easy to move between gcc/clang/icc for most codebases. Though there are some useful features still that are gcc only. (And probably some that are clang only, though I pretty much only use gcc...)
- logicchains 3y ago
  >I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them Many places deliberately compile with multiple compilers as part of the build/test pipeline, to benefit from more compiler warnings, diagnostics etc.
- jupp0r 3y ago
  There are lots of libraries that need to compile on a variety of platforms (ie different versions of LLVM for Android and MacOS, MSVC for Windows and GCC for some embedded targets not well supported by LLVM).
- ska 3y ago
  It works but you have to keep it at least "semi-active". Some shops have CI services setup to cross compile etc. already. Mainly I've seen this not as a tool to maintain a "backup" but as a way to shake out bugs and keep non-portable stuff from creeping into the codebase. You could probably do most of it with conservative linting and some in-house knowledge of portability issues, non-standard compiler extensions, etc. It's typically a lot easier to do this for different compiler, same target, than different targets.
- Guvante 3y ago
  Our codebase works on all three, we compile on MSVC for Windows, GCC for Linux, and Clang for Mac. It isn't easy and honestly the idea of "just don't use MSVC for a while" is strange to me. Sure you can compile with any of them but almost certainly you are going to stick to one for a given use case. "This release is on a different compiler" isn't something you do because of a bug. Instead your roll back a version or avoid using the unsupported feature until a fix is released. The reason is as much as they are supposed to do the same thing the reality is bugs are bugs, e.g. if you invoke undefined behavior you will generally get consistent results with a given compiler but all bets are off if you swap. Similarly it is hard not to rely on implementation defined behavior without building your own standard library which specifically defines that behavior across compilers.
- gpderetta 3y ago
  It is quite common. In most places I have worked we did GCC and clang builds. Some did GCC/clang/msvc/ICC. And of course plenty of OSS libraries support many compilers even beyond the main three.
- jandrewrogers 3y ago
  Many complex C++ codebases have full parallel CI pipelines for GCC and LLVM. It encourages good code hygiene and occasionally identifies bugs in the compiler toolchain. If you are using intrinsics or other architecture-specific features, there is a similar practice of requiring full CI pipelines for at least two CPU architectures. Again, it occasionally finds interesting bugs. For systems I work on we usually have 4 CI pipelines for the combo of GCC/LLVM and ARM/x86 for these purposes. It costs a bit more but is generally worth it from a code quality perspective.
  - izacus 3y ago
    Adding CI pipeline running compiles on MSVC was one of the big shakeouts of undefined behaviour and bugs in our C++ codebase - while making that compiler happy is annoying if you come from Unixy land, it did force us to shed quite a few bad habits and even find several bugs in that endeavor. (And then we could ship the product on Windows, so that was nice.)
- zik 3y ago
  It's easy to write C or C++ code which works with both gcc and clang. Generally if there's a problem it's a standards compliance issue in your code so it's good to know and fix. MSVC is a bit more quirky... At times its standards compliance has been patchy but I think it's ok right now.
- jamesfinlayson 3y ago
  In a presentation a few years ago Valve Software said that getting the Source engine working on Linux and Mac helped them find some issues in their Windows code (I don't remember the exact timeline though - I assume they had an Xbox 360 build pipeline at the same time, but maybe not yet a PlayStation 3 build pipeline).
vlovich123 3y ago
The C++ spec regularly has all sorts of errata and misdesigns. Not sure I buy this argument.
KolmogorovComp 3y ago
Rust has currently no formal specification, so what would you use as an arbiter? Also the article says otherwise > The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all
- lambda 3y ago
  You use the same process as for deciding if changes to rustc are compliant or not; the judgement of the language and compiler teams. And running into these kinds of questions, both in a single project that evolves over time (rustc) and a separate project, help to feed information back into what you need for a formal specification; which is something that is being planned out. Having a second implementation can help find these areas where you might need to be narrower or broader in your specification, in order to clarify enough for it to be implementable or broaden it enough to accommodate reasonable implementation differences. They are not trying to diverge in language implementation, but there will always be simple compiler bugs, which may crop up in one implementation but not another. For instance, some LLVM optimization pass may miscompile some code; gccrs wouldn't necessarily be trying to recreate that exact bug. I think that "bugs, quirks, and all" really means that they aren't trying to fix major limitations of rustc, such as introducing a whole different borrow checker model which might allow some programs that current rustc does not. They're trying to fairly faithfully recreate the language that rustc implements, even if some aspects might be considered sub-optimal, but they aren't going to re-implement every ICE and miscompilation, those are places where there could be differences.
  - KolmogorovComp 3y ago
    I agree with you it has benefits, what I’m wondering about is if not more bugs (though not the same ones) would be fixed by contributing directly to rustc compared to the massive effort of building a new compiler.
    - Narishma 3y ago
      It's about finding those bugs in the first place. Working on a different implementation is one way of doing that.
slashdev 3y ago
I hit a compiler bug in rust and downgraded it to an earlier stable version. That’s usually enough.
tester756 3y ago
>Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that's not currently possible. Theory is cool, but in practice other compiler has its own quirks too How about having one compiler which is used by all developers, which increases chances of bugs getting caught faster and fixed faster meanwhile you just use workaround?
nindalf 3y ago
Your sentiment is a commonly expressed one, but not usually by people who have adopted Rust. It’s usually Clang/MSVC/GCC users who have decided this is the optimal flow and want to replicate it in all future codebases they work in, regardless of language. In reality if you hit a compiler bug in Rust or Go (or any other language with one main impl like Python, Ruby…) you would file a report and do one of two things - downgrade the compiler (if it’s an option) or write the code a different way. Compiler bugs in these languages are rare enough that this approach works well. That said, for people who are really keen on a spec, there is one being worked on (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). But this GCCRS effort doesn’t get you any closer to your ideal C/C++ style workflow because they are committing to matching the semantics of the main compiler exactly. Bugs and all. And that’s the way it should be. The Rust ecosystem becomes worse if I have to install a different toolchain and learn a different build system with a different compiler for every new project I interact with. And after all that extra effort it turns out there are subtle differences between implementations. My developer experience is just worse at that point. If I wanted to code like this, I would code in C++ but I don’t.
- moregrist 3y ago
  > Your sentiment is a commonly expressed one, but not usually by people who have adopted Rust. Perhaps because it’s currently not possible in Rust, so users don’t really see the advantages yet. Multiple implementation are always a good thing. They bring in diversity of thought and allow for some competition in the implementation. Having multiple slightly different implementations also gives more clarity to a spec. This isn’t the kind of stuff that users tend to think about until it’s already there.
  - rblatz 3y ago
    All i hear is fragmented ecosystem.
    - crotchfire 3y ago
      Have you had your ears checked lately?
nicoburns 3y ago
That works until you have a popular project that needs to support all the compilers. Then you need you need to work around n sets of bugs and incompatibilities.
justinclift 3y ago
Not sure about that, as the article has this: > The project wants to ... replicate the output of rustc — bugs, quirks, and all.

by ndiddy 3y ago

VBprogrammer 3y ago

I don't have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.

cozzyd 3y ago
It's pretty easy to move between gcc/clang/icc for most codebases. Though there are some useful features still that are gcc only. (And probably some that are clang only, though I pretty much only use gcc...)
logicchains 3y ago
>I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them Many places deliberately compile with multiple compilers as part of the build/test pipeline, to benefit from more compiler warnings, diagnostics etc.
jupp0r 3y ago
There are lots of libraries that need to compile on a variety of platforms (ie different versions of LLVM for Android and MacOS, MSVC for Windows and GCC for some embedded targets not well supported by LLVM).
ska 3y ago
It works but you have to keep it at least "semi-active". Some shops have CI services setup to cross compile etc. already. Mainly I've seen this not as a tool to maintain a "backup" but as a way to shake out bugs and keep non-portable stuff from creeping into the codebase. You could probably do most of it with conservative linting and some in-house knowledge of portability issues, non-standard compiler extensions, etc. It's typically a lot easier to do this for different compiler, same target, than different targets.
Guvante 3y ago
Our codebase works on all three, we compile on MSVC for Windows, GCC for Linux, and Clang for Mac. It isn't easy and honestly the idea of "just don't use MSVC for a while" is strange to me. Sure you can compile with any of them but almost certainly you are going to stick to one for a given use case. "This release is on a different compiler" isn't something you do because of a bug. Instead your roll back a version or avoid using the unsupported feature until a fix is released. The reason is as much as they are supposed to do the same thing the reality is bugs are bugs, e.g. if you invoke undefined behavior you will generally get consistent results with a given compiler but all bets are off if you swap. Similarly it is hard not to rely on implementation defined behavior without building your own standard library which specifically defines that behavior across compilers.
gpderetta 3y ago
It is quite common. In most places I have worked we did GCC and clang builds. Some did GCC/clang/msvc/ICC. And of course plenty of OSS libraries support many compilers even beyond the main three.
jandrewrogers 3y ago
Many complex C++ codebases have full parallel CI pipelines for GCC and LLVM. It encourages good code hygiene and occasionally identifies bugs in the compiler toolchain. If you are using intrinsics or other architecture-specific features, there is a similar practice of requiring full CI pipelines for at least two CPU architectures. Again, it occasionally finds interesting bugs. For systems I work on we usually have 4 CI pipelines for the combo of GCC/LLVM and ARM/x86 for these purposes. It costs a bit more but is generally worth it from a code quality perspective.
- izacus 3y ago
  Adding CI pipeline running compiles on MSVC was one of the big shakeouts of undefined behaviour and bugs in our C++ codebase - while making that compiler happy is annoying if you come from Unixy land, it did force us to shed quite a few bad habits and even find several bugs in that endeavor. (And then we could ship the product on Windows, so that was nice.)
zik 3y ago
It's easy to write C or C++ code which works with both gcc and clang. Generally if there's a problem it's a standards compliance issue in your code so it's good to know and fix. MSVC is a bit more quirky... At times its standards compliance has been patchy but I think it's ok right now.
jamesfinlayson 3y ago
In a presentation a few years ago Valve Software said that getting the Source engine working on Linux and Mac helped them find some issues in their Windows code (I don't remember the exact timeline though - I assume they had an Xbox 360 build pipeline at the same time, but maybe not yet a PlayStation 3 build pipeline).

vlovich123 3y ago

The C++ spec regularly has all sorts of errata and misdesigns. Not sure I buy this argument.

KolmogorovComp 3y ago

Rust has currently no formal specification, so what would you use as an arbiter? Also the article says otherwise > The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all

lambda 3y ago
You use the same process as for deciding if changes to rustc are compliant or not; the judgement of the language and compiler teams. And running into these kinds of questions, both in a single project that evolves over time (rustc) and a separate project, help to feed information back into what you need for a formal specification; which is something that is being planned out. Having a second implementation can help find these areas where you might need to be narrower or broader in your specification, in order to clarify enough for it to be implementable or broaden it enough to accommodate reasonable implementation differences. They are not trying to diverge in language implementation, but there will always be simple compiler bugs, which may crop up in one implementation but not another. For instance, some LLVM optimization pass may miscompile some code; gccrs wouldn't necessarily be trying to recreate that exact bug. I think that "bugs, quirks, and all" really means that they aren't trying to fix major limitations of rustc, such as introducing a whole different borrow checker model which might allow some programs that current rustc does not. They're trying to fairly faithfully recreate the language that rustc implements, even if some aspects might be considered sub-optimal, but they aren't going to re-implement every ICE and miscompilation, those are places where there could be differences.
- KolmogorovComp 3y ago
  I agree with you it has benefits, what I’m wondering about is if not more bugs (though not the same ones) would be fixed by contributing directly to rustc compared to the massive effort of building a new compiler.
  - Narishma 3y ago
    It's about finding those bugs in the first place. Working on a different implementation is one way of doing that.

slashdev 3y ago

I hit a compiler bug in rust and downgraded it to an earlier stable version. That’s usually enough.

tester756 3y ago

>Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that's not currently possible. Theory is cool, but in practice other compiler has its own quirks too How about having one compiler which is used by all developers, which increases chances of bugs getting caught faster and fixed faster meanwhile you just use workaround?

nindalf 3y ago

Your sentiment is a commonly expressed one, but not usually by people who have adopted Rust. It’s usually Clang/MSVC/GCC users who have decided this is the optimal flow and want to replicate it in all future codebases they work in, regardless of language. In reality if you hit a compiler bug in Rust or Go (or any other language with one main impl like Python, Ruby…) you would file a report and do one of two things - downgrade the compiler (if it’s an option) or write the code a different way. Compiler bugs in these languages are rare enough that this approach works well. That said, for people who are really keen on a spec, there is one being worked on (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...). But this GCCRS effort doesn’t get you any closer to your ideal C/C++ style workflow because they are committing to matching the semantics of the main compiler exactly. Bugs and all. And that’s the way it should be. The Rust ecosystem becomes worse if I have to install a different toolchain and learn a different build system with a different compiler for every new project I interact with. And after all that extra effort it turns out there are subtle differences between implementations. My developer experience is just worse at that point. If I wanted to code like this, I would code in C++ but I don’t.

moregrist 3y ago
> Your sentiment is a commonly expressed one, but not usually by people who have adopted Rust. Perhaps because it’s currently not possible in Rust, so users don’t really see the advantages yet. Multiple implementation are always a good thing. They bring in diversity of thought and allow for some competition in the implementation. Having multiple slightly different implementations also gives more clarity to a spec. This isn’t the kind of stuff that users tend to think about until it’s already there.
- rblatz 3y ago
  All i hear is fragmented ecosystem.
  - crotchfire 3y ago
    Have you had your ears checked lately?

nicoburns 3y ago

That works until you have a popular project that needs to support all the compilers. Then you need you need to work around n sets of bugs and incompatibilities.

justinclift 3y ago

Not sure about that, as the article has this: > The project wants to ... replicate the output of rustc — bugs, quirks, and all.