5 ms·

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 opti

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?
    - Klonoar 3y ago
      Nah, they’re right.
- MindSpunk 3y ago
  I agree there is value to multiple implementations. We wouldn't be where we are today with open compilers and efficient machine code if it weren't for the competing implementations of LLVM and GCC. However there isn't enough benefit to multiple language _frontends_ that I can see that outweighs the many downsides. Not only do you have to contend with the duplication of effort for implementing two or more language frontend projects, you now create ecosystem splits when inevitably the implementations do not match their behavior. The biggest example of multiple frontends, C++, is not one language. C++ is Clang-C++, GNU-C++, MSVC-C++, and so-on. All of these implementations have subtle incompatibilities with how they handle identical code, or they have disjoint feature matrices, or they have bugs, and so on. Multiple frontends is IMO one of the _worst_ parts of C++ because it makes writing truly portable code almost impossible. How many new C++ features are unusable in practice because one of the main 3 toolchains hasn't implemented it yet? Rust, on the other hand, everything is portable by default. No #ifdef CLANG, no wrangling with subtly incompatible toolchains. If I write code I can trust it will just work on any architecture Rust can build for, ignoring implementation bugs and explicitly platform specific code. I have a hobby game engine I work on in my spare time that was developed exclusively on x86-64 for years and I ported it to run on Apple Silicon ARM in two afternoons. Rust just _worked_, all the time was spent on my C/C++ dependencies and new code needed for MacOS support. I simply don't see how nebulous, difficult to quantify benefits of competing implementations can outweigh the practical advantages of truly portable code that comes from a single implementation. The ecosystem benefits to a uniform language, and the benefits to my sanity with being able to trust my code while compile everywhere I need it to.
  - adrianN 3y ago
    Writing truly portable C++ it’s not all that hard. In the worst case you need a handful of ifdefs even if you write systems code.
    - messe 3y ago
      #ifdefs are a signed of ported code, and not portable code.
- newZWhoDis 3y ago
  That is dumb and counterproductive. Your entire scenario presupposes unlimited labor capacity and funding (monetary or otherwise), so “diversity is better!” In reality, the people wasting their time to produce a redundant ground-up rewrite of existing functionally could have spent their time and effort on something else that actually moves the world forward.
  - moregrist 3y ago
    I think the only thing I’m assuming here is that there are people who want to do the work. Perhaps because it’s fun to write a compiler (it is!), or because they don’t view llvm as the pinnacle of compiler technology, or maybe their employer sees value in it. And apparently there are people who want to do the work, because we have work on a couple of implementations. You can choose to use your one true implementation, no one is stopping you. But it’s kind of weird to assume that people working on another one are detracting from yours. That’s not usually the way open source software works.
- ilayn 3y ago
  That's only true if you are not distributing your code. If you want to kill portability just involve MSVC in anything.
crotchfire 3y ago
Monopoly is never the optimal flow. Sincerely, - Rust adopter
- TheDong 3y ago
  Monopoly rings hollow when it comes to a community open source project. Monopolies are bad when they stifle progress, but rust's written under a free software license. At any point, anyone can take the project and fork it into a new one, can carry on the progress under a new flag. Unlike traditional monopolies, the rust project's priorities aren't extracting profits or holding power, but rather in improving the language, and they're open to anyone (well, anyone who's tolerant of others) joining and helping. The argument here is that we will end up with a better outcome if we work together as a community, rather than if we fragment just for some perceived ideal of multiple implementations. While you're criticizing the rust monopoly, you might as well go and also yell at the group of friends voluntarily picking up trash off the sidewalk for free since they're working together as one monopoly of friends instead of creating two competing cleaning groups.
  - fsckboy 3y ago
    > rust's written under a free software license the way you are using "free" is undefined behavior. "Free" as in speech software, the F in FOSS, is associated with copyleft FSF and GNU, and not like BSD, MIT, and Apache, the open source in fOSs, which is what Rust is.
    - TheDong 3y ago
      The english language is full of ambiguity if you choose to be pedantic, yet somehow most people manage to communicate. The fact that you knew I was referring to rust's license means my English was in fact not undefined, but exactly as clearly defined as one can hope english to be, i.e. we both thought it meant the same thing. In my opinion, in context, "free software license" is also a clear and common phrase, not undefined behavior. Essentially, I think everyone has agreed that "free software", unless you add more qualifiers, will refer to the FSF definition of free software https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/free-sw.html The FSFs definition includes both the licenses rust is licensed under: https://www.gnu.org/licenses/license-list.html#Expat https://www.gnu.org/licenses/license-list.html#Expat The FSF would happily call BSD, MIT, and Apache "Free Software Licenses", and in fact do so.

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?
  - Klonoar 3y ago
    Nah, they’re right.
MindSpunk 3y ago
I agree there is value to multiple implementations. We wouldn't be where we are today with open compilers and efficient machine code if it weren't for the competing implementations of LLVM and GCC. However there isn't enough benefit to multiple language _frontends_ that I can see that outweighs the many downsides. Not only do you have to contend with the duplication of effort for implementing two or more language frontend projects, you now create ecosystem splits when inevitably the implementations do not match their behavior. The biggest example of multiple frontends, C++, is not one language. C++ is Clang-C++, GNU-C++, MSVC-C++, and so-on. All of these implementations have subtle incompatibilities with how they handle identical code, or they have disjoint feature matrices, or they have bugs, and so on. Multiple frontends is IMO one of the _worst_ parts of C++ because it makes writing truly portable code almost impossible. How many new C++ features are unusable in practice because one of the main 3 toolchains hasn't implemented it yet? Rust, on the other hand, everything is portable by default. No #ifdef CLANG, no wrangling with subtly incompatible toolchains. If I write code I can trust it will just work on any architecture Rust can build for, ignoring implementation bugs and explicitly platform specific code. I have a hobby game engine I work on in my spare time that was developed exclusively on x86-64 for years and I ported it to run on Apple Silicon ARM in two afternoons. Rust just _worked_, all the time was spent on my C/C++ dependencies and new code needed for MacOS support. I simply don't see how nebulous, difficult to quantify benefits of competing implementations can outweigh the practical advantages of truly portable code that comes from a single implementation. The ecosystem benefits to a uniform language, and the benefits to my sanity with being able to trust my code while compile everywhere I need it to.
- adrianN 3y ago
  Writing truly portable C++ it’s not all that hard. In the worst case you need a handful of ifdefs even if you write systems code.
  - messe 3y ago
    #ifdefs are a signed of ported code, and not portable code.
newZWhoDis 3y ago
That is dumb and counterproductive. Your entire scenario presupposes unlimited labor capacity and funding (monetary or otherwise), so “diversity is better!” In reality, the people wasting their time to produce a redundant ground-up rewrite of existing functionally could have spent their time and effort on something else that actually moves the world forward.
- moregrist 3y ago
  I think the only thing I’m assuming here is that there are people who want to do the work. Perhaps because it’s fun to write a compiler (it is!), or because they don’t view llvm as the pinnacle of compiler technology, or maybe their employer sees value in it. And apparently there are people who want to do the work, because we have work on a couple of implementations. You can choose to use your one true implementation, no one is stopping you. But it’s kind of weird to assume that people working on another one are detracting from yours. That’s not usually the way open source software works.
ilayn 3y ago
That's only true if you are not distributing your code. If you want to kill portability just involve MSVC in anything.

crotchfire 3y ago

Monopoly is never the optimal flow. Sincerely, - Rust adopter

TheDong 3y ago
Monopoly rings hollow when it comes to a community open source project. Monopolies are bad when they stifle progress, but rust's written under a free software license. At any point, anyone can take the project and fork it into a new one, can carry on the progress under a new flag. Unlike traditional monopolies, the rust project's priorities aren't extracting profits or holding power, but rather in improving the language, and they're open to anyone (well, anyone who's tolerant of others) joining and helping. The argument here is that we will end up with a better outcome if we work together as a community, rather than if we fragment just for some perceived ideal of multiple implementations. While you're criticizing the rust monopoly, you might as well go and also yell at the group of friends voluntarily picking up trash off the sidewalk for free since they're working together as one monopoly of friends instead of creating two competing cleaning groups.
- fsckboy 3y ago
  > rust's written under a free software license the way you are using "free" is undefined behavior. "Free" as in speech software, the F in FOSS, is associated with copyleft FSF and GNU, and not like BSD, MIT, and Apache, the open source in fOSs, which is what Rust is.
  - TheDong 3y ago
    The english language is full of ambiguity if you choose to be pedantic, yet somehow most people manage to communicate. The fact that you knew I was referring to rust's license means my English was in fact not undefined, but exactly as clearly defined as one can hope english to be, i.e. we both thought it meant the same thing. In my opinion, in context, "free software license" is also a clear and common phrase, not undefined behavior. Essentially, I think everyone has agreed that "free software", unless you add more qualifiers, will refer to the FSF definition of free software https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/free-sw.html The FSFs definition includes both the licenses rust is licensed under: https://www.gnu.org/licenses/license-list.html#Expat https://www.gnu.org/licenses/license-list.html#Expat The FSF would happily call BSD, MIT, and Apache "Free Software Licenses", and in fact do so.