Live data from Hacker News

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

fractalfir.github.io

251–260 of 264 posts

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

#251

Earlier quoted context omitted.

Well, the promise was that rustc_codegen_gcc would reach its goals very quickly which is why several people dismissed projects such as gccrs. But it turns out that rustc_codegen_gcc still hasn't delivered and it seems the project has fallen asleep.

I am not affiliated with `cg_gcc`, but I have contributed some tiny things here and there. Currently, `cg_gcc` is within spitting distance of being able to bootstrap the compiler. There really are only 3(!) bugs that currently stop a stage 2 build. I know for sure, because I found workarounds for them, and have a working stage 2 build. A stage 3 build requires a bit more RAM than I have, but, besides that, it is defi…

Thanks for the update. I think one important issue that also needs to be resolved is adding the GCC git tree as a subproject in Rust's git tree so that in the end, it will be possible to build a Rust compiler with a rustc_codegen_gcc backend without having to resort to external repositories.

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

#252

Earlier quoted context omitted.

> I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous. You don't have to statically link C libraries.

I am referring to Rust scaling up to where C is now (i.e. try to remove C from the picture). As in, if there will ever be a Rust equivalent of KDE/GNOME (e.g. maybe COSMIC), it will have similar libraries. They will have to be in Rust, and will have to be statically linked. And they will eventually grow up to be the size of KDE/GNOME (as opposed to the tiny thing COSMIC is now).

If it is any consolation, early C did not have dynamic linking either. It was added afterward. From what I understand, UNIX systems had statically linked binaries in /bin until ELF was introduced and gradually switched to dynamically linked binaries afterward.

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

#253
post #187

Earlier quoted context omitted.

> 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 l…

If your like Rust, this is fine, but I will stay with C. I find it much better for my purposes.

He said elsewhere that he does not even use Rust. He uses typescript. I am confused why he is bothering to push Rust when he does not even use it.

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

#254
post #240

Earlier quoted context omitted.

There's tools that can prove the absence of runtime errors in industrially-useful subsets of C. Frama-C, RV-Match, and Meta's Infer come to mind. That code is then usable in about anything because so much of it is written in or can call C. Until Rust has that combo, there's still a reason to use C. Personally, I'd use both Rust and C with equivalent code. The Rust types and borrow checker give some extra assurance th…

Astree claims to be able to prove the absence of runtime errors in both C and C++, without requiring the use of subsets: https://www.absint.com/astree/index.htm By the way, C has a formally verified C compiler: https://compcert.org/compcert-C.html

Yeah, CompCert will certify a binary for those willing to buy it or use a GPL license. Empirical testing showed it had no bugs in its middle end, unlike other compiler.

On Astree, I couldn't believe it supported all language constructs. I found this on your link:

"and is subject to the same restrictions as Astrée for C.

The high-level abstraction features and template library of C++ facilitate the design of very complex and dynamic software. Extensive use of these features may violate the established principles of safety-critical embedded software development and lead to unsatis­fac­tory analysis times and results. The Astrée manual gives recommendations on the use of C++ features to ensure that the code can be well analyzed. For less constrained (less critical) C++ code, we recommend using the standalone RuleChecker."

So, it still does require a language subset that reduces complexity to benefit from the full analysis. They have greatly expanded what errors they catch since I first read about them. So, thanks for the link.

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

#255
post #151

Earlier quoted context omitted.

This comment is strange, given that LLVM is rust's most mature backend

I think the GP means emit LLVM IR directly. And the answer to that is yes; you can pass a flag to rustc that will emit the IR[1]. [1]: https://stackoverflow.com/questions/39004513/how-to-emit-llv...

This is what I meant, thank you.

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

#256

"Most components of std are about 95% working in .NET, and 80% working in C." .NET Core tests 1662 39 12 97.02% C Core tests 1419 294 82.83% Missing from HN title: The "95%" pass rate only applies to .NET. For GCC/Clang it is only "80%".

Sorry, the README was out of date. Those numbers are from the beginning of the year, and now they are: | .NET Core tests | 1764 | 48 | 20 | 96.29% | | C Core tests | 1712 | 71 | 8 | 95.59% |

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

#257

"Most components of std are about 95% working in .NET, and 80% working in C." .NET Core tests 1662 39 12 97.02% C Core tests 1419 294 82.83% Missing from HN title: The "95%" pass rate only applies to .NET. For GCC/Clang it is only "80%".

Sorry, the README was out of date. Those numbers are from the beginning of the year, and now they are: | .NET Core tests | 1764 | 48 | 20 | 96.29% | | C Core tests | 1712 | 71 | 8 | 95.59% |

Has anyone tested this project on NetBSD.

https://github.com/dotnet/coreclr/pull/4504/files

Any reason why it would not work.

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

#258
post #249

Earlier quoted context omitted.

> As for C++, there is nothing at that link that says you need a textbook to learn C++. Sorry, it says that in their FAQ[0]. It also says "Should I learn C before I learn C++?" "Don’t bother." and proceeds to advertise a Stroustrup book[1]. [0]: https://isocpp.org/wiki/faq/how-to-learn-cpp#start-learning [1]: https://isocpp.org/wiki/faq/how-to-learn-cpp#learning-c-not-... > If you insist on learning C++ first, here i…

> Sorry, it says that in their FAQ[0]. It also says "Should I learn C before I learn C++?" "Don’t bother." and proceeds to advertise a Stroustrup book[1]. They also would say "Don't bother" about using any other language. If you listen to them, you would never touch Rust or anything else. > But I have a problem with learning from non-authoritative sources, especially random websites and YouTube tutorials. I like to l…

> Thus, you need to call accept() repeatedly to drain the backlog before returning to listening for signals.

It's not just accept. If your socket is non-blocking the same applies to read, write, and everything else. You keep syscalling until it returns EAGAIN.

> I described the general idea to Grok and it produced a beautiful implementation of this in Rust using the tokio "crate". The result had the same bug that the C++ code had, because it made the understandable assumption my younger self made that 1 SIGIO = 1 connection, but that is wrong.

I don't know what your general idea was but tokio uses epoll under the hood (correctly), so what you are describing could only have happened if you specifically instructed grok to use SIGIO.

> Finally, it is far more natural for C developers and C++ developers to use a binary format over network sockets (like I did) than HTTP.

Designing a custom protocol is way more work than just using HTTP. .

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

#259
post #249

Earlier quoted context omitted.

> As for C++, there is nothing at that link that says you need a textbook to learn C++. Sorry, it says that in their FAQ[0]. It also says "Should I learn C before I learn C++?" "Don’t bother." and proceeds to advertise a Stroustrup book[1]. [0]: https://isocpp.org/wiki/faq/how-to-learn-cpp#start-learning [1]: https://isocpp.org/wiki/faq/how-to-learn-cpp#learning-c-not-... > If you insist on learning C++ first, here i…

> Sorry, it says that in their FAQ[0]. It also says "Should I learn C before I learn C++?" "Don’t bother." and proceeds to advertise a Stroustrup book[1]. They also would say "Don't bother" about using any other language. If you listen to them, you would never touch Rust or anything else. > But I have a problem with learning from non-authoritative sources, especially random websites and YouTube tutorials. I like to l…

> You could go to edx.org and audit courses...

This is great advice, thanks!

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

#260
post #253
post #187

Earlier quoted context omitted.

If your like Rust, this is fine, but I will stay with C. I find it much better for my purposes.

He said elsewhere that he does not even use Rust. He uses typescript. I am confused why he is bothering to push Rust when he does not even use it.

I would use it if I had the opportunity, that's why.
Post reply on HN