Our great sponsors
-
cryptography
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
-
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.
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
-
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.
I'm mostly just happy to see that Rust is finding its way into widely used Python packages even if it seems to be just a test for now judging from the lib.rs file.
It depends on the specific design and on your perspective. rustc_codegen_gcc is an attempt to combine the existing rustc frontend with GCC, so it could be considered either a GCC backend for rustc or a rustc frontend for GCC. Perhaps "backend" is a bit more accurate since rustc is the main process and is driving GCC as a library. But gccrs is an attempt to write a frontend from scratch, so it could only be considered a Rust frontend for GCC (or GCC frontend for Rust - the order doesn't really matter). When I said "GCC frontend" I meant to encompass both approaches.
Semver only applies to public APIs. https://semver.org/ says the following.
If rustc supported compiling to C, it could add a mode that automatically runs the C compiler on the output, resulting in the same interface as a native port of rustc, just a bit slower. This could work with not only GCC, but any C compiler. Targeting a platform where the official compiler is some antiquated fork of GCC or proprietary fork of Clang, or perhaps a completely proprietary compiler? Having issues with LLVM version incompatibilities when submitting bitcode to Apple's App Store? Or perhaps you want to compare the performance of LLVM, GCC, Intel's C compiler, and MSVC? Going through C would solve all those problems.
I still use python a bit and find poetry quite nice. It has a lot of similarities to cargo including using the new pyproject.toml file (like Cargo.toml) and handles virtual environments with a lockfile for direct and transitive dependencies.
Also note that this is a well trodden path—the original C++ compiler cfront compiled to C. More recently, Nim compiles to C (and supports full source level debugging).