Microsoft plans to eliminate all C and C++ code across its major codebases by 2030, replacing it with Rust using AI-assisted, large-scale refactoring. "My goal is to eliminate every line of C and C++ from Microsoft by 2030," Microsoft Distinguished Engineer Galen Hunt writes in a post on LinkedIn. "Our strategy is to combine AI and Algorithms to rewrite Microsoft's largest codebases. Our North Star is '1 engineer, 1 month, 1 million lines of code.' To accomplish this previously unimaginable task, we've built a powerful code processing infrastructure. Our algorithmic infrastructure creates a scalable graph over source code at scale. Our AI processing infrastructure then enables us to apply AI agents, guided by algorithms, to make code modifications at scale. The core of this infrastructure is already operating at scale on problems such as code understanding." Hunt says he's looking to hire a Principal Software Engineer to help with this effort. "The purpose of this Principal Software Engineer role is to help us evolve and augment our infrastructure to enable translating Microsoft's largest C and C++ systems to Rust," writes Hunt. "A critical requirement for this role is experience building production quality systems-level code in Rust -- preferably at least 3 years of experience writing systems-level code in Rust. Compiler, database, or OS implementation experience is highly desired. While compiler implementation experience is not required to apply, the willingness to acquire that experience in our team is required."

Read more of this story at Slashdot.

The team authoring the Rust 2025 Vision Doc interviewed Rust developers to find out what they liked about the language — and have now issued three recommendations "to help Rust continue to scale across domains and usage levels." — Enumerate and describe Rust's design goals and integrate them into our processes, helping to ensure they are observed by future language designers and the broader ecosystem. — Double down on extensibility, introducing the ability for crates to influence the develop experience and the compilation pipeline. — Help users to navigate the crates.io ecosystem and enable smoother interop The real "empowering magic" of Rust arises from achieving a number of different attributes all at once — reliability, efficiency, low-level control, supportiveness, and so forth. It would be valuable to have a canonical list of those values that we could collectively refer to as a community and that we could use when evaluating RFCs or other proposed designs... We recommend creating an RFC that defines the goals we are shooting for as we work on Rust... One insight from our research is that we don't need to define which values are "most important". We've seen that for Rust to truly work, it must achieveallthe factors at once... We recommenddoubling down on extensibilityas a core strategy. Rust's extensibility — traits, macros, operator overloading — has been key to its versatility. But that extensibility is currently concentrated in certain areas: the type system and early-stage proc macros. We should expand it to coversupportive interfaces(better diagnostics and guidance from crates) andcompilation workflow(letting crates integrate at more stages of the build process)... Doubling down on extensibility will not only make current Rust easier to use, it will enable and support Rust's use in new domains. Safety Critical applications in particular require a host of custom lints and tooling to support the associated standards. Compiler extensibility allows Rust to support those niche needs in a more general way. We recommend finding ways to help users navigate the crates.io ecosystem... [F]inding which crates to use presents a real obstacle when people are getting started. The Rust org maintains a carefully neutral stance, which is good, but also means that people don't have anywhere to go for advice on a good "starter set" crates... Part of the solution is enabling better interop between libraries.

Read more of this story at Slashdot.

Elite computer science degrees are no longer a guaranteed on-ramp to tech jobs, as AI-driven coding tools slash demand for entry-level engineers and concentrate hiring around a small pool of already "elite" or AI-savvy developers. The Los Angeles Times reports: "Stanford computer science graduates are struggling to find entry-level jobs" with the most prominent tech brands, said Jan Liphardt, associate professor of bioengineering at Stanford University. "I think that's crazy." While the rapidly advancing coding capabilities of generative AI have made experienced engineers more productive, they have also hobbled the job prospects of early-career software engineers. Stanford students describe a suddenly skewed job market, where just a small slice of graduates -- those considered "cracked engineers" who already have thick resumes building products and doing research -- are getting the few good jobs, leaving everyone else to fight for scraps. "There's definitely a very dreary mood on campus," said a recent computer science graduate who asked not to be named so they could speak freely. "People [who are] job hunting are very stressed out, and it's very hard for them to actually secure jobs." The shake-up is being felt across California colleges, including UC Berkeley, USC and others. The job search has been even tougher for those with less prestigious degrees. [...] Data suggests that even though AI startups like OpenAI and Anthropic are hiring many people, it is not offsetting the decline in hiring elsewhere. Employment for specific groups, such as early-career software developers between the ages of 22 and 25 has declined by nearly 20% from its peak in late 2022, according to a Stanford study. [...] A common sentiment from hiring managers is that where they previously needed ten engineers, they now only need "two skilled engineers and one of these LLM-based agents," which can be just as productive, said Nenad Medvidovic, a computer science professor at the University of Southern California. "We don't need the junior developers anymore," said Amr Awadallah, CEO of Vectara, a Palo Alto-based AI startup. "The AI now can code better than the average junior developer that comes out of the best schools out there." [...] Stanford students say they are arriving at the job market and finding a split in the road; capable AI engineers can find jobs, but basic, old-school computer science jobs are disappearing. As they hit this surprise speed bump, some students are lowering their standards and joining companies they wouldn't have considered before. Some are creating their own startups. A large group of frustrated grads are deciding to continue their studies to beef up their resumes and add more skills needed to compete with AI.

Read more of this story at Slashdot.

The R programming language "is sometimes frowned upon by 'traditional' software engineers," says the CEO of software quality services vendor Tiobe, "due to its unconventional syntax and limited scalability for large production systems." But he says it "continues to thrive at universities and in research-driven industries, and "for domain experts, it remains a powerful and elegant tool." Yet it's now gaining more popularity as statistics and large-scale data visualization become important (a trend he also sees reflected in the rise of Wolfram/Mathematica). That's according to December's edition of his TIOBE Index, which attempts to rank the popularity of programming languages based on search-engine results for courses, third-party vendors, and skilled engineers. InfoWorld explains: In the December 2025 index, published December 7, R ranks 10th with a 1.96% rating. R has cracked the Tiobe index's top 10 before, such as in April 2020 and July 2020, but not in recent years. The rival Pypl Popularity of Programming Language Index, meanwhile, has R ranked fifth this month with a 5.84% share. "Programming language R is known for fitting statisticians and data scientists like a glove," said Paul Jansen, CEO of software quality services vendor Tiobe, in a bulletin accompanying the December index... Although data science rival Python has eclipsed R in terms of general adoption, Jansen said R has carved out a solid and enduring niche, excelling at rapid experimentation, statistical modeling, and exploratory data analysis. "We have seen many Tiobe index top 10 entrants rising and falling," Jansen wrote. "It will be interesting to see whether R can maintain its current position." "Python remains ahead at 23.64%," notes TechRepublic, "while the familiar chase group behind it holds steady for the moment. The real movement comes deeper in the list, where SQL edges upward, R rises to the top 10, and Delphi/Object Pascal slips away... SQLclimbs from tenth to eighth at 2.10%, adding a small +0.11% that's enough to move it upward in a tightly packed section of the table. Perl holds ninth at 1.97%, strengthened by a +1.33% gain that extends its late-year resurgence." It's interesting to see how TIOBE's ranking compare with PYPL's (which ranks languages based solely on how often language tutorials are searched on Google): TIOBE PYPL Python Python C C/C++ C++ Objective-C Java Java C# R JavaScript JavaScript Visual Basic Swift SQL C# Perl PHP R Rust Despite their different methodologies, both lists put Python at #1, Java at #5, and JavaScript at #7.

Read more of this story at Slashdot.

Steven J. Vaughan-Nichols files this report from Tokyo: At the invitation-only Linux Kernel Maintainers Summit here, the top Linux maintainers decided, as Jonathan Corbet, Linux kernel developer, put it, "The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the 'experimental' tag will be coming off." As Linux kernel maintainer Steven Rosted told me, "There was zero pushback." This has been a long time coming. This shift caps five years of sometimes-fierce debate over whether the memory-safe language belonged alongside C at the heart of the world's most widely deployed open source operating system... It all began when Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit said that about two-thirds of Linux kernel vulnerabilities come from memory safety issues. Rust, in theory, could avoid these by using Rust's inherently safer application programming interfaces (API)... In those early days, the plan was not to rewrite Linux in Rust; it still isn't, but to adopt it selectively where it can provide the most security benefit without destabilizing mature C code. In short, new drivers, subsystems, and helper libraries would be the first targets... Despite the fuss, more and more programs were ported to Rust. By April 2025, the Linux kernel contained about 34 million lines of C code, with only 25 thousand lines written in Rust. At the same time, more and more drivers and higher-level utilities were being written in Rust. For instance, the Debian Linux distro developers announced that going forward, Rust would be a required dependency in its foundational Advanced Package Tool (APT). This change doesn't mean everyone will need to use Rust. C is not going anywhere. Still, as several maintainers told me, they expect to see many more drivers being written in Rust. In particular, Rust looks especially attractive for "leaf" drivers (network, storage, NVMe, etc.), where the Rust-for-Linux bindings expose safe wrappers over kernel C APIs. Nevertheless, for would-be kernel and systems programmers, Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees. This combination may define the next generation of low-level development work.

Read more of this story at Slashdot.