Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust to C compiler – 95.9% test pass rate, odd platforms

fractalfir.github.io

Post reply on HN
Print view View original

171–180 of 264 posts

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#171

Post by jpc0 »

koakuma-chan wrote: post #160
ryao wrote: post #157

Earlier quoted context omitted.

Being decades old does not make it out of date. Until a few years ago, the Linux kernel was written using C89. While it has switched to C11, the changes are fairly small such that a book on C89 is still useful. Many projects still write code against older C versions, and the C compiler supports specifying older C versions. This is very different than Rust where every new version is abandonware after 6 weeks and the c…

> Being decades old does not make it out of date. Right, the docs never get out of date if the thing they document never changes. Can you say the same about C++ though? I’ve heard they release new versions every now and then. My robotics teacher didn’t know ‘auto’ is a thing for example.

Auto as it is now has been in C++ since C++11, thats more than a decade ago...

If your argument was C then sure thats a C23 feature (well the type inference type of auto ) and is reasonably new.

This is much more a reflection on youe professor than the language. C++11 was a fundamental change to the language, anyone teaching or using C++ in 2025 should have an understanding of how to to program well in a 14 year old version of said language...

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#172

Post by jpc0 »

koakuma-chan wrote: post #110
cynical_german wrote: post #102

Earlier quoted context omitted.

Oh my... Are you serious? I'm almost triggered by this. A book about algorithms or data structures from 20 years ago has nothing more to teach? 3D game engine design from 20 years ago has nothing more to teach? No point in looking at the source code of Quake, reading k&r, and Knuth's TAOCP Volume 1 was published in 1968 so it's obviously irrelevant garbage! I could spurr into an essay of what kind of lack of understa…

We’re talking about C/C++, not algorithms or data structures.

How you implement algorithms and data structures in C++/rust is semantics at best. The imperative shell of those languages are identical semantically right down to the memory model.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#173

Post by koakuma-chan »

jpc0 wrote: post #172
koakuma-chan wrote: post #110

Earlier quoted context omitted.

We’re talking about C/C++, not algorithms or data structures.

How you implement algorithms and data structures in C++/rust is semantics at best. The imperative shell of those languages are identical semantically right down to the memory model.

Right, that's why a 20 year old book on algorithms and data structures is not necessarily outdated, but a 20 year old book on C/C++ most certainly is.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#174

Post by fintler »

woodruffw wrote: post #165
CursedSilicon wrote: post #146

Earlier quoted context omitted.

Hi, retro computing person here. I've had a similar debate with Rust evangelists in past Something the Rust community doesn't understand is when they shout "REWRITE IT IN RUST!" at a certain point that's simply not possible Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture?…

> This specific line in Tier 2 would send most project managers running for the hills "Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower" Are you operating under the assumption that the largely implicit support tiers in other compilers are better? In other words: do…

> do you think GCC’s m68k backend (to pick an arbitrary one) has been as battle-tested as their AArch64 one

m68k might be a bad example to pick. I was using gcc to target m68k on netbsd in the mid 1990s. It's very battle tested.

Also, don't forget that m68k used to be in all of the macs that Apple sold at one point before they switched to powerpc (before switching to x86 and the current arm chips). You could use gcc (with mpw's libs and headers) on pre-osx (e.g. system 7) m68k macs.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#175

Post by koakuma-chan »

jpc0 wrote: post #171
koakuma-chan wrote: post #160

Earlier quoted context omitted.

> Being decades old does not make it out of date. Right, the docs never get out of date if the thing they document never changes. Can you say the same about C++ though? I’ve heard they release new versions every now and then. My robotics teacher didn’t know ‘auto’ is a thing for example.

Auto as it is now has been in C++ since C++11, thats more than a decade ago... If your argument was C then sure thats a C23 feature (well the type inference type of auto ) and is reasonably new. This is much more a reflection on youe professor than the language. C++11 was a fundamental change to the language, anyone teaching or using C++ in 2025 should have an understanding of how to to program well in a 14 year old…

> Auto as it is now has been in C++ since C++11, thats more than a decade ago...

> anyone teaching or using C++ in 2025 should have an understanding of how to to program well in a 14 year old version of said language...

If the current year is 2025 then 14 years ago is 2011 which is not that long ago.

> If your argument was C then sure thats a C23 feature (well the type inference type of auto ) and is reasonably new.

Grandparent comment is arguing that Linux was written in C89 until a few days ago so decades old books on C aren't actually outdated.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#176

Post by baq »

lmm wrote: post #109
carlmr wrote: post #79

Earlier quoted context omitted.

>To fix bugs, sure. Maybe your program worked due to the bug they fixed.

Extremely unlikely. CPU bugs generally halt the CPU or fail to write the result or something like that. The Pentium FDIV bug where it would give a plausible but wrong result was a once in a lifetime thing.

Spectre and Meltdown exploits stopped working, too. Some of them on some CPUs, anyway.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#177

Post by koakuma-chan »

uecker wrote: post #170
koakuma-chan wrote: post #148

Earlier quoted context omitted.

What aspects do you not like about Rust?

Too much complexity, long build times, monomorphization, lack of stability / no standard, poor portability, supply chain issues, no dynamic linking, no proper standard, not enough different implementations, etc. It is a nice language though, but I do not prefer it over C.

> long build times, monomorphization

Monomorphization is what causes long build times, but it brings better performance than dynamic dispatch.

> lack of stability

There was another comment which also never elaborated on how Rust is not stable.

> supply chain issues

Not a language issue, you choose your dependencies.

> no proper standard, not enough different implementations

Is that a practical problem?

> no dynamic linking

There is.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#178

Post by landr0id »

cod1r wrote: post #30

this fractalfir person is super talented. See them on the rust reddit all the time. I'm not knowledgeable on compilers at all but others seem to really like their work.

I think they’re pretty young too. Hoping for a bright future ahead of them!

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#179

Post by woodruffw »

fintler wrote: post #174
woodruffw wrote: post #165

Earlier quoted context omitted.

> This specific line in Tier 2 would send most project managers running for the hills "Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower" Are you operating under the assumption that the largely implicit support tiers in other compilers are better? In other words: do…

> do you think GCC’s m68k backend (to pick an arbitrary one) has been as battle-tested as their AArch64 one m68k might be a bad example to pick. I was using gcc to target m68k on netbsd in the mid 1990s. It's very battle tested. Also, don't forget that m68k used to be in all of the macs that Apple sold at one point before they switched to powerpc (before switching to x86 and the current arm chips). You could use gcc…

> m68k might be a bad example to pick. I was using gcc to target m68k on netbsd in the mid 1990s. It's very battle tested.

That was 30 years ago! Having worked on LLVM: it's very easy for optimizing compilers to regress on smaller targets. I imagine the situation is similar in GCC.

(The underlying point is simpler: explicit is better than implicit, and all Rust is doing is front-loading the frustration from "this project was never tested on this platform but we pretend like it was" to "this platform is not well tested." That's a good thing.)

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#180

Post by EasyMark »

flomo wrote: post #21

Of course, everyone votes up the headlines, but this link seems like premature WIP. Hopefully this will get posted for real after the presentation.

If you read the article you'll see this is a status report and not a pitch for a final product.
Post reply on HN