I’m thrilled to sit down with Anand Naidu, our resident development expert, whose proficiency in both frontend and backend development offers us a unique perspective on the ever-evolving world of programming. With a deep understanding of various coding languages, Anand is here to unpack the latest updates in Rust 1.90, shedding light on enhancements to the Cargo package manager, changes in target support for macOS and Linux, and what these shifts mean for developers navigating this powerful language.
What excites you most about the Rust 1.90 release in terms of the Cargo package manager’s new capabilities?
I’m really pumped about the introduction of workspace publishing support in Cargo with Rust 1.90. The new cargo publish --workspace command is a game-changer. It automates the process of publishing all crates in a workspace in the correct order, respecting dependencies between them. This eliminates a lot of manual hassle and makes the workflow so much smoother for developers managing multiple crates.
Can you dive into what the cargo publish --workspace command actually does for developers?
Absolutely. This command allows developers to publish every crate within a workspace automatically and in the right sequence. It ensures that dependencies are handled properly, so you don’t end up with broken publishes due to out-of-order uploads. Before this, you had to either script it yourself or use third-party tools, which could be a real pain. Now, it’s all built into Cargo, making the process seamless.
How does this new workspace publishing feature improve on the older methods developers used to rely on?
In the past, developers had to manually order their crate publishes or lean on external tools to manage the sequence. That was time-consuming and prone to errors, especially in larger projects with complex dependencies. With cargo publish --workspace, the process is not only faster but also more reliable since Cargo handles the ordering natively, reducing the risk of mistakes.
What was the typical approach for publishing multiple crates in a workspace before this update?
Before Rust 1.90, developers often had to manually publish each crate one by one, figuring out the dependency order themselves. Some would write scripts or use external tools to automate this, but it wasn’t standardized. It could get messy, especially if you missed a dependency, leading to failed publishes or broken packages on the registry.
Why do you think having native workspace publishing support in Cargo is a significant step forward compared to using external tools?
Native support means tighter integration with Cargo’s ecosystem. It’s not just about convenience; Cargo can now run publish verification across the entire set of crates as if they were already published. This ensures everything builds correctly before anything goes live, which external tools couldn’t always guarantee. Plus, it reduces dependency on third-party solutions that might not keep up with Cargo updates.
How does Cargo’s publish verification tie into this new workspace publishing feature?
Cargo’s publish verification with the workspace feature is pretty neat. When you use cargo publish --workspace, it performs a build across all the crates slated for publishing, simulating the environment as if they were already on the registry. This catches potential issues—like dependency mismatches or build errors—before they become public problems, saving developers a lot of headaches.
Shifting gears, can you explain the changes made to the x86_64-apple-darwin target in Rust 1.90?
Sure, in Rust 1.90, the x86_64-apple-darwin target, which is used for macOS on Intel hardware, has been demoted from Tier 1 to Tier 2 support with host tools. This downgrade reflects changes in the broader tech landscape, like GitHub phasing out free macOS x86-64 runners for public repos and Apple moving away from Intel architecture support.
What prompted the Rust team to make this decision to demote the x86_64-apple-darwin target?
The decision came down to practical realities. With GitHub discontinuing free runners for macOS x86-64 and Apple signaling the end of support for Intel-based systems, maintaining Tier 1 status with the same level of testing and guarantees became unsustainable for the Rust team. They had to adjust to focus resources on more widely used architectures.
How might this demotion impact developers working with Rust on macOS?
For now, most developers won’t notice an immediate impact. The Rust Project will still distribute builds for the standard library and compiler via rustup or other installation methods while it’s at Tier 2. However, over time, reduced testing and coverage could lead to compatibility issues or breakages that might not get flagged or fixed as quickly as before.
What has the Rust team said about future support for this target while it remains at Tier 2?
The team has made it clear that they’ll continue providing builds for the x86_64-apple-darwin target through rustup and other channels during its Tier 2 status. But they’ve also warned that there won’t be further announcements if things start breaking due to lower testing coverage, so developers should be prepared for potential hiccups down the line.
What kind of long-term challenges or risks do you foresee for developers relying on this target?
Over time, the biggest risk is compatibility drift. With less focus on testing for x86_64-apple-darwin, updates to Rust or related tools might introduce subtle bugs or incompatibilities that go unnoticed. Developers using older Intel-based macOS systems might find their workflows breaking without clear fixes, pushing them to consider upgrading hardware or switching targets.
On a different note, what’s the key update for the x86_64-unknown-linux-gnu target in this release?
Rust 1.90 switches the default linker for the x86_64-unknown-linux-gnu target to LLD, which is a faster alternative to the traditional BFD linker on Linux. This change aims to improve linking performance, which is a critical part of the compilation process for many projects.
Can you elaborate on the advantages this switch to the LLD linker brings to developers on Linux?
The main advantage of using LLD by default is speed. Linking can be a bottleneck in large projects, and LLD is generally much quicker than the older BFD linker. This means faster compilation times, which can significantly boost productivity, especially for developers iterating on big codebases or running frequent builds.
What should developers expect to notice with this change to the LLD linker?
Most developers will likely just see a reduction in compilation time, which is a nice bonus. The switch is designed to be transparent—there shouldn’t be any functional differences in the output. It’s all about performance, so the day-to-day experience remains the same, just quicker.
If a developer encounters issues with the LLD linker, what options do they have to revert to the previous setup?
If LLD causes problems, developers can opt out by using the -C linker-features=-lld compiler flag. This lets them go back to the previous linker setup without much fuss. It’s a good safety net for those rare cases where compatibility or specific project needs clash with LLD.
For those eager to try Rust 1.90, how can they update using rustup?
Updating to Rust 1.90 with rustup is super straightforward. Just open a terminal and run rustup update stable. This command will fetch and install the latest stable version, including all the new features and changes we’ve been discussing, ensuring you’re ready to roll with the latest tools.
Looking at the bigger picture, what’s your forecast for how Rust 1.90 will shape the developer community moving forward?
I think Rust 1.90 is going to further solidify Rust’s reputation as a developer-friendly language that keeps evolving to meet real-world needs. The Cargo workspace publishing feature will make managing complex projects easier, encouraging more collaborative and modular development. Meanwhile, the target and linker changes show the team’s commitment to adapting to hardware and ecosystem shifts, even if it means tough calls like demoting certain targets. Overall, I expect this release to streamline workflows and keep Rust at the forefront of systems programming, while nudging developers to stay current with modern platforms.
