4 ms·

I disagree that multiple frontend implementations is going to be a good thing for Rust. Multiple backends is great, but multiple frontends could result in Rust

• apendleton 5y ago
  FWIW, an alternative outcome to lowest-common-denominator is what's happened with, for example, alternative Python implementations: there's still a main blessed one, most library authors don't care about whether or not anything works on any of the others, and users who want to avail themselves of the benefits of one of the alternatives (e.g., better runtime performance on PyPy) probably just can't, if the libraries they need aren't supported, unless they go to the effort of adding support themselves. (This outcome is probably also bad, to be clear, but maybe of less practical consequence to people who continue to use mainline rustc.)
  • nynx 5y ago
    Yeah, that outcome is still pretty bad. I don’t think there’s any value gained from multiple frontends here. It’s unlike the PyPy situation in that a Rust GCC frontend is not going to have better performance, at least at runtime, from rustc with a GCC backend. Any compile performance differences could be resolved.
• kzrdude 5y ago
  GCC vs llvm competition has been beneficial for C++, though
  • nynx 5y ago
    And it's going to be beneficial for Rust too. Just there's no reason to have multiple frontends.
  • cmrdporcupine 5y ago
    This is new, though. Back in the 90s and early 2000s the compiler situation for C++ held back the language because the intersection of features from the "standard" available through both MSCV and GCC wasn't ideal. Both were good compilers. But in different ways. Nowadays it's pretty trivial to get a codebase to compile across MSVC, GCC and Clang. Back then it was often weeks and weeks of work.
    • brundolf 5y ago
      This sounds like a social issue though (compiler teams cooperating and keeping things up to date). It seems like when you have a smaller number of implementations they tend to be more agile; look at the modern web browser landscape vs that of the 2000s, for example I'd bet that having exactly two implementations will be a good place to be
      • cmrdporcupine 5y ago
        Yes, it was definitely social at least in part because MS leadership at that time didn't see something like GCC as a legitimate partner to cooperate with. They wanted open source to go away. Things definitely changed in that regard later. I think you're probably right that two Rust implementations with a cooperative mentality would be a good thing in the long run.
    • pjmlp 5y ago
      On the contrary it fostered a development in C++ IDEs and .NET like frameworks, whose Qt and VCL are the only worthwhile survivors. As for your list, I never had many issues keeping a code compiling across MSVC, aCC, xlC, SunPro, GCC. In fact aCC on HP-UX 11 was the one that gave me more problems.
• stu2b50 5y ago
  As long as the current rustc front end is the canonical one I think it’ll end up fine. As the parent post explains, there are niches that want the gcc frontend and they should be able to get it.
• chrismorgan 5y ago
  Multiple implementations allows for competition by novel approaches. (It doesn’t guarantee that that’s the way it’ll work out, but it makes it possible.) Look at browsers: IE stagnated, Firefox got things going again, and IE eventually improved. And then as Firefox had become bloated, Chrome came along and showed that better performance was possible, and so Firefox improved as effort to match Chrome was exerted. Or npm: it got mired as people couldn’t agree on the way to resolve some pretty big issues (centring on performance), so some people started Yarn, and its success helped unstick npm, so that now many that had switched to Yarn were able to move back to npm once it caught up again. And these are just a couple of examples I’m familiar with. Yes, there are costs to diversity of implementation, but there are benefits. The reasons why multiple backends is great can largely apply to multiple frontends. Rust’s backend and frontend are both performance bottlenecks. One perfectly plausible course of events is that someone builds a new Rust compiler focused on end-to-end performance. That could help both the ecosystem and rustc.
  • Dylan16807 5y ago
    I don't really want significant competition inside a programming language. Most features can be added on to an experimental version of the existing code base, or done as a prototype. Not much needs a full competing compiler.
    • chrismorgan 5y ago
      Now, that may be true. (Or it may not be. I won’t judge the matter.) In ten years’ time? Again maybe, maybe not; but history of parallel cases suggests it’s less likely to be true in time to come than it is likely to be true now.
    • pjmlp 5y ago
      Programming languages are software products like anything else in computing. I rather not be using edlin of programming languages when given the option.
• geofft 5y ago
  As a counterargument, the web platform has multiple "frontends" (multiple, unrelated codebases that interpret HTML and JS and CSS, not just multiple engines/renderers), and the argument to avoid the monoculture seems good there. Although, hm, I suppose you could argue that if there were one libhtml5 and Gecko and Blink and WebKit all used that, but they had different "backends," that might be even better than the current situation - that the value of having multiple web browsers is in the equivalent to the backends, not in the equivalent to the frontends.
• dataangel 5y ago
  > I disagree that multiple frontend implementations is going to be a good thing for Rust. Specialization, GATs, and const generics that aren't painfully limited are taking a very long time to deliver. As a selfish user I would love to see a Clang vs GCC style friendly rivalry develop.
• pjmlp 5y ago
  Monocultures are bad and stiff innovation.