Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
ioq3
The ioquake3 community effort to continue supporting/developing id's Quake III Arena (by immunant)
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
If anyone had trouble parsing rustccggcc, it's rustc-cg-gcc, ie https://github.com/rust-lang/rustc_codegen_gcc
and also HIR in the very near future (next refresh of the live site): https://github.com/compiler-explorer/compiler-explorer/pull/...
If you have any idea of feature, don't hesitate to open an issue ! :D
Yeah, I hardly understand Rust code, and I did not start learning programming yesterday.
If you want to practice, check out https://github.com/immunant/ioq3/blob/transpiled/quake3-rs/q... or whatever.
That page averages all the builds across different code bases. It doesn’t specify which version/tag of which code base, nor does it talk about the hardware.
https://arewefastyet.pages.dev/ - This page tracks compile times across some common crates over all supported compiler versions, with different hardware (2, 4, 8, 16 cores). This used to be https://arewefastyet.rs but the domain expired.
* time to compile whatever syn generated
I didn’t do a super thorough studies of things, but my impression is that 2, performance of syn itself, is rarely an issue. Most of the time it is 1) (and the associated problem of decreased build parallelism because half of the crates wait for syn to compile) and 3).
To get a feeling how costly a simple proc macro is, run this benchmark: https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....
Yep. But there are two different active projects for compiling Rust with a GCC backend at the moment (one as a completely new frontend written as part of the GCC codebase, one as a libgccjit backend for the existing Rustc), there's also a Cranelift backend for rustc that you could add new architecture support to, and LLVM does add new targets, it can just take a bit longer to get support into LLVM and they don't keep architectures that are lightly or unmaintained around as long as GCC does.
For instance, Tier 3 support for m68k-unknown-linux-gnu was recently stabilized in rustc as a result of m68k support landing in LLVM (https://github.com/rust-lang/rust/blob/master/RELEASES.md#co...), which has been one of the previous sticking points for Rust packaging on Linux distros, some of which still support m68k architectures.
but it still looks weird to me (a static mut would be uncommon in a design, and not having a new-type to represent these would also be uncommon).
If you are interested in looking what Rust written from the ground up in the same domain looks like, you can maybe look at Bevy[1].
The biggest source of "noise" in Rust is explicit type conversions, FP constructs and longer types (`.into()`/`.as_mut_ref()`/`.map()`/`Result, E>`).
[1]: https://github.com/bevyengine/bevy/blob/main/crates/bevy_ren...
Related posts
- What Are Const Generics and How Are They Used in Rust?
- Why do lifetimes need to be leaky?
- How hard would it be to port the Rust toolchain to a new non-POSIX OS written in Rust and get it to host its own development? What would that process entail?
- GCC 13 and the State of Gccrs
- Any alternate Rust compilers?