Hacker News Reader

Comment by moregrist | Hacker News Reader

> 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.

View on HN

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.

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.

#ifdefs are a signed of ported code, and not portable code.

If you need a few hundred lines of ifdef in a codebase with millions of lines it is portable in the sense that you are able to port it with reasonable effort.

That's nice, you're welcome to continue writing your ifdefs. Nothing you or anyone else has said has built a compelling case for alternate frontends. You're saying "it's not much effort". Sure, but I prefer 0 effort.

What we're saying is that everyone actually using Rust today is fairly happy with how the language is. That's why Rust has had an 80%+ approval rating among Rust developers since its creation and C++ is at 49% (https://survey.stackoverflow.co/2023/#section-admired-and-de...).

This suggestion of alternate frontends still has no good technical reason driving it, just people pattern matching on their past experience. If it happens, all it will do is lower Rust's approval to C++'s level.

If only alternative frontends were the only reason that C++ developers were unhappy with the language...

Only #if you ignore the hundred other issues with building portable c++ code:

* Libraries * ABIs * Build system(s) * Platform compiler support...

In compiled/interpreted land, most if not all of these are solved problems. Even for libraries, usually dependencies can be reliably downloaded and recompiled (if they are not compiled on the fly).

I don't really care if you can create a "portable header" library when the ecosystem is sharded, and "portable" only holds true for some subset of c++ compiler/platforms.

That seems orthogonal to having multiple frontends. I have in fact worked on several systems that compiled under three compilers and ran on multiple architectures and/or operating systems and it was not a hot mess of ifdef spaghetti.

Its orthogonal to ifdef sphaghetti so long as that's not in support of the (general) sphaghetti.

I'm not specifically commenting on ifdefs, because ifdefs are only a small part of the issue (caused by multiple compiler frontends).

It's bad enough already when there's a single implementation, but people can't agree which version increment has left the newfangled stage.

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.

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.

That's only true if you are not distributing your code. If you want to kill portability just involve MSVC in anything.

All i hear is fragmented ecosystem.

Have you had your ears checked lately?

Nah, they’re right.

Reply on news.ycombinator.com