Some links on the most promising effort so far, gccrs

https://opensrcsec.com/open_source_security_announces_rust_g...

https://www.embecosm.com/2021/01/12/gcc-rust-how-it-can-be-a...

https://rust-gcc.github.io/

This is an entirely new frontend written in C++, that shares no code with rustc (the official rust compiler). It might be merged some day in GCC proper.

But honestly, I'm more excited for rustc_codegen_gcc:

https://github.com/antoyo/rustc_codegen_gcc

It adds gcc as an alternative backend of the official Rust compiler. That way it is much more feasible to stay up to date as the language evolves.

Anyway the former two don't actually work right now. The one that does work today is mrustc, or at least it works for bootstrapping rustc; it doesn't have a borrow checker though (and instead assumes the program is correct). Also, mrustc isn't based on gcc.

https://github.com/thepowersgang/mrustc

(There's a fourth project, https://github.com/sapir/gcc-rust, but it seems abandoned)

Meh. Part of what makes rust appealing over C++ for my current project is that the latter has at least three major target compilers with subtle differences in how they implement things that mean that even staying within the bounds of the standard might result in different outcomes in the code (not to mention the whole mess around dependencies in C++ code). Multiple implementations of a language feels more like a bug than a feature to me.

As best I can tell, C and C++ are the only languages where people are actually happy that there are multiple implementations.

Multiple implementations are great when there's a standard to compare them to, ideally where that standard is backed by a set of tests.

The problem is when you have multiple implementations of languages that are effectively defined by their reference implementation, then the alternatives are usually an exercise in frustration.

I think Javascript has many user who think they benefit from competing implementations. I’m not sure the sentiment there seems as strong as in the C++ community, but it definitely exists.

I'm more annoyed by the inconsistent implementations than anything else (Mostly browsers as server side still sees node being the winner).

Not to mention the terrible tooling to make multiple deployment targets possible (webpack, polyfills and whatnot)

Count Ada, D, Java and .NET as well.

What about Java? As far as I know, everyone was very happy OpenJDK existed and Oracle eventually relented too. Now we have even more interesting stuff like Graal.

Disclaimer : I'm still new and learning Java.

OpenJDK is the original version of Java with a few features stripped out, not a reimplementation.

See the History section of https://en.wikipedia.org/wiki/OpenJDK?wprov=sfla1

Thank you for the link. I stand corrected and better learned.

Glad it was interesting. I was surprised to learn the same thing a few months ago

Java also has multiple implementations. Great to have a documented language standard!

Hmmm what about CPython and PyPy?

As a single data point, I’ve been using Python since 2005 and have never played with PyPy any beyond a quick peek after seeing a conference talk.

On the other hand, I use gcc, clang, and MSVC++ on a regular basis. But... I think the reason I care about multiple C++ compilers is mostly because there’s no “one compiler that is ergonomic to use everywhere” and I end up writing better code because of it (eg gcc warning about something clang doesn’t care about).

For Python, I mostly just care that it Just Works everywhere (modulo compiler setup for building C modules)

Almost all Python code is written for CPython, and if you run into performance issues you tweak it until it runs on pypy.

I'm glad that pypy exists because it forces cpython to do something about performance, but for python overall it's a pretty niche tool.

> even staying within the bounds of the standard might result in different outcomes in the code

If that's important, why not pretend that your project is in "Clang C++" rather than C++? Clang compiles to at least all the platforms that Rust does.

> not to mention the whole mess around dependencies in C++ code

Agreed. I feel like the proliferation of header-only libraries is a sign that something's seriously wrong here.

Multiple implementations is a fact of life for popular and useful languages. (Not Rust yet.)

Standards exist to make multiple implementations palatable.

See Python for a stunning example where they botched the standardization effort and ruined the language for good.

Can you elaborate on why you think they “botched” the standardization? I don’t know much about the topic, and I’m genuinely curious about what went right and wrong.

I'm not very familiar with the details, but I can comment on the results that I see: there's a multitude of python implementations (Jython, ironpython, pypy, stackless python), but only CPython has widespread adoption and there's little overlap between the ecosystems: rarely will python code be written to run on multiple implementations. I think the largest reason for this is that the CPython ecosystem is basically built on a foundation native C code (not just in the standard library but in many of the commonly used packages), and that interface is only starting to get some standardisation, as well as being very tied to CPython implementation details which made it very difficult to implement on other platforms.

In that sense Democracy is also a bug then. In some ways it's a feature. It's a feature because it makes harder for reverse engineers to know which compiler generated the code. When they figure out the compiler, they can reverse the compiler logic.

This seems like a really odd reason to care about multiple implementations: firstly because it's a steam hammer to crack a walnut (there are much more effective and cheap ways to obfuscate code than just using a different compiler), and secondly because it's not very effective: compiler identification is fairly straightforward, both for experienced reverse engineers and the tools that they use.

Compiler identification is not fairly straightforward when you remove all metadata that gives you hints. It gets worse when you fake the metadata.

My opinion echoed by many top people in reverse engineering industry.

Modern C++ is obfuscated by default due to templates, inlined functions and of course OOP.

For example, Marcus Hutchins famously echoed Boost is a cluster fuck of sadness.

My point is not about obfuscation anyway but it does helps obfuscation to some extent. It's about reverse engineering the optimized code and recover the original non-optimized code which can have a lot of use-cases.

https://www.msreverseengineering.com had a course on this subject. Experienced ones can reverse everything but my point is that it increase the barrier.

Making the job of those engineers harder doesn't sound like a feature.

I don't want people even competitors to steal my intellectual property so making job of those reverse engineers harder is a feature not a bug.

https://github.com/Rust-GCC/gccrs is in progress, but I believe it works enough to be worth playing with. Note that it doesn't implement the borrow checker - the plan is to reuse rustc's borrow checker as a compiler plugin. For now, as I understand it, gccrs itself assumes that the code is valid (i.e., would be accepted by rustc).

https://thephilbert.io/ is the primary developer's blog and has status updates.

See also the discussion here https://news.ycombinator.com/item?id=21734529 (about https://github.com/sapir/gcc-rust but also about a GNU Rust compiler in general)

For my own enlightenment, why a GNU implementation? What does it bring to the table?

I suggest you try a functional language before driving into Rust.

First off, your account is just C++ spam. So, off the bat, I've dismissed the notion of taking you seriously.

I've implemented a basic ML variant before, and maybe half a dozen different lisps. Rust is only BARELY functional. A C++ guy ought to know better!

Believe me, I'm not interested in Rust for Rust's sake. If there were a GNU implementation, I could see writing code generators for Rust a little less cumbersome than trying to target C or LLVM IR or Wasm.

Realistically, I see Zig winning the fight that Rust is trying to fight, and C++'s headaches being replaced with Rust's headaches.

I don't spam C++ and I comment on C++.

There is no fight. There is made-up flame-war. Every war happen at HN and Reddit's Echochamber not at Real World.

Every languages has headaches. You won't find a perfect language ever.

You can't do serious Rust if you don't understand functional aspects.

I know C++, Haskell and Rust. Like many says Rust is a functional language disguised as imperative. There were case studies on Rust where a one with Haskell background more like to learn it faster than a one with C++ background.

The Rust book don't show you the functional parts at beginning to build your intuition but once you drive deeper you will realize what I meant.

https://ceronman.com/2020/09/17/is-rust-a-functional-languag...

In my (limited) experience with people who tried to learn Rust with a predominantly C++ background mostly struggle with trying to shoehorn some OOP design, when the language has other idioms better auite to it.

Rust does have a lot of nice ideas borrowed (hehe) from functional programming, but it's far from being FP!

On a tangent: you're comment about learning a FP before learning Rust is great advice, but not for the reasons you initially intended perhaps. Learning FP in general is great, since it teaches you a different way of thinking from the "classical" way programmers think. So, it's great to learn FP for anyone, regardless of whether it's for Rust's sake (it will help a bit with reasoning about some Rust concepts and idioms, though), or not.

Graydon Hoare is a OCaml developer.

Graydon Hoare mentions Rust as linear ML in C++ clothing.

https://twitter.com/graydon_pub/status/1154476823557754880

I empathized the can't deny relationship between Rust and FP. It doesn't means Rust is a pure FP language. I always said same thing about C++ templates too.