ZDNet's Steven Vaughan-Nichols shares some of the latest improvements to ExpressVPN following its codebase transition from C to Rust. An anonymous reader quotes an excerpt from the report: ExpressVPN is one of ZDNET's favorite Virtual Private Networks (VPNs). The popular VPN's transformation of its Lightway codebase from C to Rust promises to make the service faster and more secure. For now, the updated Lightway 2.0 is only available via ExpressVPN's Aircove router with the February 4 AircoveOS v5 update. The Aircove, which we rate as the best VPN router, costs $189. With this device, you can protect your tech from unwanted snoopers without installing a VPN on each gadget. So, how much faster is the updated ExpressVPN? In my tests, I connected to the internet via my updated router over my 2 Gigabit per second (Gbps) AT&T Internet using a 2.5 Gbps Ethernet-connected Linux Mint desktop with a Wi-Fi 6 connection over my Samsung Galaxy 25 Plus smartphone.

Without the VPN engaged, I saw 1.6 Gbps speeds, which is about par. With the VPN switched on and using Lightway 2.0, I saw speeds in the 290 to 330 Megabit per second (Mbps) range to Toronto and London, England. Farther afield, I saw speeds around 250 to 280Mbps to Hong Kong and Seoul. That's about 20% faster than I had seen with earlier Lightway versions. I was impressed. This version of the VPN should also be more secure. As Pete Membrey, ExpressVPN's chief research officer, said in a statement: "At ExpressVPN, we innovate to solve the challenges of tomorrow. Upgrading Lightway from its previous C code to Rust was a strategic and straightforward decision to enhance performance and security while ensuring longevity."

The updated Lightway VPN protocol also uses ML-KEM, the newly finalized NIST standard for post-quantum encryption. This feature, wrote Membray in a blog post, "ensures your connection is secured by encryption designed not just for today's threats but for the quantum-powered challenges of the future." To ensure the integrity of the recoded Lightway protocol, ExpressVPN commissioned two independent security audits from cybersecurity firms Cure53 and Praetorian. Both audits yielded positive results, with only minor vulnerabilities identified and promptly addressed by ExpressVPN. In short, ExpressVPN is technically about as safe a VPN as they come.

An anonymous Slashdot reader shared this report from Phoronix: Linux's second-in-command Greg Kroah-Hartman has also been a big proponent of Rust kernel code. He's crafted another Linux kernel mailing list post [Wednesdsay] outlining the benefits of Rust and encouraging new kernel code/drivers to be in Rust rather than C. Greg KH makes the case that the majority of the kernel bugs are due to "stupid little corner cases in C that are totally gone in Rust."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "

The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."

This year's "State of Rust" survey was completed by 7,310 Rust developers. DevClass note some key findings: When asked about their biggest worries for Rust's future, 45.5 percent cited "not enough usage in the tech industry," up from 42.5 percent last year, just ahead of the 45.2 percent who cited complexity as a concern... Only 18.6 percent declared themselves "not worried," though this is a slight improvement on 17.8 percent in 2023...

Another question asks whether respondents are using Rust at work. 38.2 percent claimed to use it for most of their coding [up from 34% in 2023], and 13.4 percent a few times a week, accounting for just over half of responses. At the organization level there is a similar pattern. 45.5 percent of organizations represented by respondents make "non-trivial use of Rust," up from 38.7 percent last year.
More details from I Programmer: On the up are "Using Rust helps us achieve or goals", now 82% compared to 72% in 2022; "We're likely to use Rust again in the future", up 3% to 78%; and "Using Rust has been worth the cost of Adoption". Going down are "Adopting Rust has been challenging", now 34.5% compared to 38.5% in 2022; and "Overall adopting Rust has slowed down our team" down by over 2% to 7%.
"According to the survey, organizations primarily choose Rust for building correct and bug-free software (87.1%), performance characteristics (84.5%), security and safety properties (74.8%), and development enjoyment (71.2%)," writes The New Stack: Rust seems to be especially popular for creating server backends (53.4%), web and networking services, cloud technologies and WebAssembly, the report said. It also seems to be gaining more traction for embedded use cases... Regarding the preferred development environment, Linux remains the dominant development platform (73.7%).

However, although VS Code remains the leading editor, its usage dropped five percentage points, from 61.7% to 56.7%, but the Zed editor gained notable traction, from 0.7% to 8.9%. Also, "nine out of 10 Rust developers use the current stable version, suggesting strong confidence in the language's stability," the report said...

Overall, 82% of respondents report that Rust helped their company achieve its goals, and daily Rust usage increased to 53% (up four percentage points from 2023). When asked why they use Rust at work, 47% of respondents cited a need for precise control over their software, which is up from 37% when the question was asked two years ago.

Linus Torvalds responded Thursday to kernel developer Christoph Hellwig, who had claimed Torvalds merged Rust code into the kernel even over his objections as the original C code's maintainer. Highlights from Torvalds' response: The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form... Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".

And that is not how *any* of this works. What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code. You are saying that you disagree with Rust — which is fine, nobody has ever required you to write or read Rust code. But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain...

You don't have to like Rust. You don't have to care about it. That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So to get back to the very core of your statement:

"The document claims no subsystem is forced to take Rust"

that is very much true. You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it...

You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".... So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.

But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code. Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
Torvalds also made sure to add some kind remarks, including "I respect you technically, and I like working with you."

Christoph Hellwig continues to voice strong opposition to Rust in the Linux kernel, arguing that its introduction creates fragmentation, unclear language guidelines, and additional burdens on maintainers. He also says Linus Torvalds has privately stated he will override objections to Rust code, effectively making its adoption inevitable. Phoronix's Michael Larabel has the latest: The latest on Hellwig's perspective of Rust code within the Linux kernel is below. Some interesting insight from a dissenting view. The thread in full can be found on the Rust for Linux mailing list.

[Here's an excerpt from the thread:] "I don't think having a web page in any form is useful. If you want it to be valid it has to be in the kernel tree and widely agreed on. It also states factually incorrect information. E.g. 'Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.' while Linus in private said that he absolutely is going to merge Rust code over a maintainers objection. (He did so in private in case you are looking for a reference). So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not. [...] Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly."
Inevitably there was a response... Torvalds: Rust Kernel Code Isn't Forced In Over Maintainers' Objections.

For over a decade Karol Herbst has been a developer on the open-source Nouveau driver, a reverse-engineered NVIDIA graphics driver for Linux. "He went on to become employed by Red Hat," notes Phoronix. "While he's known more these days for his work on the Mesa 3D Graphics Library and the Rusticl OpenCL driver for it, he's still remained a maintainer of the Nouveau kernel driver."

But Saturday Herbst stepped down as a nouveau kernel maintainer, in a mailing list message that begins "I was pondering with myself for a while if I should just make it official that I'm not really involved in the kernel community anymore, neither as a reviewer, nor as a maintainer." (Another message begins "I often thought about at least contributing some patches again once I find the time, but...")

Their resignation message hints at some long-running unhappiness. "I got burned out enough by myself caring about the bits I maintained, but eventually I had to realize my limits. The obligation I felt was eating me from inside. It stopped being fun at some point and I reached a point where I simply couldn't continue the work I was so motivated doing as I've did in the early days." And they point to one specific discussion on the kernel mailing list February 8th as "The moment I made up my mind."

It happened in a thread about whether Rust would create difficulty for maintainers. (Someone had posted that "The all powerful sub-system maintainer model works well if the big technology companies can employ omniscient individuals in these roles, but those types are a bit hard to come by.") In response, someone else had posted "I'll let you in a secret. The maintainers are not 'all-powerful'. We are the 'thin blue line' that is trying to keep the code to be maintainable and high quality. Like most leaders of volunteer organization, whether it is the Internet Engineerint Task Force (the standards body for the Internet), we actually have very little power. We can not *command* people to work on retiring technical debt, or to improve testing infrastructure, or work on some particular feature that we'd very like for our users. All we can do is stop things from being accepted..."

Saturday Herbst wrote: The moment I made up my mind about this was reading the following words written by a maintainer within the kernel community:

"we are the thin blue line"

This isn't okay. This isn't creating an inclusive environment. This isn't okay with the current political situation especially in the US. A maintainer speaking those words can't be kept. No matter how important or critical or relevant they are. They need to be removed until they learn. Learn what those words mean for a lot of marginalized people. Learn about what horrors it evokes in their minds.

I can't in good faith remain to be part of a project and its community where those words are tolerated. Those words are not technical, they are a political statement. Even if unintentionally, such words carry power, they carry meanings one needs to be aware of. They do cause an immense amount of harm.
The phrase thin blue line "typically refers to the concept of the police as the line between law-and-order and chaos," according to Wikipedia, but more recently became associated with a"countermovement" to the Black Lives Matter movement and "a number of far-right movements in the U.S."

Phoronix writes: Lyude Paul and Danilo Krummrich both of Red Hat remain Nouveau kernel maintainers. Red Hat developers are also working on developing NOVA as the new Rust-based open-source NVIDIA kernel driver leveraging the GSP interface for Turing GPUs and newer.

In January the TIOBE Index (estimating programming language popularity) declared Python their language of the year. (Though it was already #1 in their rankings, it had showed a 9.3% increase in their ranking system, notes InfoWorld.) TIOBE CEO Paul Jansen says this reflects how easy Python is to learn, adding that "The demand for new programmers is still very high" (and that "developing applications completely in AI is not possible yet.")

In fact on February's version of the index, the top ten looks mostly static. The only languages dropping appear to be very old languages. Over the last 12 months C and PHP have both fallen on the index — C from the #2 to the #4 spot, and PHP from #10 all the way to #14. (Also dropping is Visual Basic, which fell from #9 to #10.)

But TechRepublican cites another factor that seems to be affecting the rankings: language speed. Fast programming languages are gaining popularity, TIOBE CEO Paul Jansen said in the TIOBE Programming Community Index in February. Fast programming languages he called out include C++ [#2], Go [#8], and Rust [#13 — up from #18 a year ago].

Also, according to the updated TIOBE rankings...

- C++ held onto its place at second from the top of the leaderboard.
- Mojo and Zig are following trajectories likely to bring them into the top 50, and reached #51 and #56 respectively in February.

"Now that the world needs to crunch more and more numbers per second, and hardware is not evolving fast enough, speed of programs is getting important. Having said this, it is not surprising that the fast programming languages are gaining ground in the TIOBE index," Jansen wrote. The need for speed helped Mojo [#51] and Zig [#56] rise...

Rust reached its all-time high in the proprietary points system (1.47%.), and Jansen expects Go to be a common sight in the top 10 going forward.

Hector Martin has resigned as the project lead of Asahi Linux, weeks after stepping down from his role as a Linux kernel maintainer for Apple ARM support. His departure from Asahi follows a contentious exchange with Linus Torvalds over development processes and social media advocacy. After quitting kernel maintenance earlier this month, the conflict escalated when Martin suggested that "shaming on social media" might be necessary to effect change.

Torvalds sharply rejected this approach, stating that "social media brigading just makes me not want to have anything at all to do with your approach" and suggested that Martin himself might be the problem. In his final resignation announcement from Asahi, Martin wrote: "I no longer have any faith left in the kernel development process or community management approach."

The dispute reflects deeper tensions in the Linux kernel community, particularly around the integration of Rust code. It follows the August departure of another key Rust for Linux maintainer, Wedson Almeida Filho from Microsoft. According to Sonatype's research, more than 300,000 open source projects have slowed or halted updates since 2020.

Keynotes at this year's FOSDEM included free AI models and systemd, reports Heise.de — and also a progress report from Miguel Ojeda, supervisor of the Rust integration in the Linux kernel. Only eight people remain in the core team around Rust for Linux... Miguel Ojeda therefore launched a survey among kernel developers, including those outside the Rust community, and presented some of the more important voices in his FOSDEM talk. The overall mood towards Rust remains favorable, especially as Linus Torvalds and Greg Kroah-Hartman are convinced of the necessity of Rust integration. This is less about rapid progress and more about finding new talent for kernel development in the future.
The reaction was mostly positive, judging by Ojeda's slides:

- "2025 will be the year of Rust GPU drivers..." — Daniel Almedia

- "I think the introduction of Rust in the kernel is one of the most exciting development experiments we've seen in a long time." — Andrea Righi

- "[T]he project faces unique challenges. Rust's biggest weakness, as a language, is that relatively few people speak it. Indeed, Rust is not a language for beginners, and systems-level development complicates things even more. That said, the Linux kernel project has historically attracted developers who love challenging software — if there's an open source group willing to put the extra effort for a better OS, it's the kernel devs." — Carlos Bilbao

- "I played a little with [Rust] in user space, and I just absolutely hate the cargo concept... I hate having to pull down other code that I do not trust. At least with shared libraries, I can trust a third party to have done the build and all that... [While Rust should continue to grow in the kernel], if a subset of C becomes as safe as Rust, it may make Rust obsolete..." Steven Rostedt

Rostedt wasn't sure if Rust would attract more kernel contributors, but did venture this opinion. "I feel Rust is more of a language that younger developers want to learn, and C is their dad's language."

But still "contention exists within the kernel development community between those pro-Rust and -C camps," argues The New Stack, citing the latest remarks from kernel maintainer Christoph Hellwig (who had earlier likened the mixing of Rust and C to cancer). Three days later Hellwig reiterated his position again on the Linux kernel mailing list: "Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain."
But the article also notes that Google "has been a staunch supporter of adding Rust to the kernel for Linux running in its Android phones." The use of Rust in the kernel is seen as a way to avoid memory vulnerabilities associated with C and C++ code and to add more stability to the Android OS. "Google's wanting to replace C code with Rust represents a small piece of the kernel but it would have a huge impact since we are talking about billions of phones," Ojeda told me after his talk.

In addition to Google, Rust adoption and enthusiasm for it is increasing as Rust gets more architectural support and as "maintainers become more comfortable with it," Ojeda told me. "Maintainers have already told me that if they could, then they would start writing Rust now," Ojeda said. "If they could drop C, they would do it...."

Amid the controversy, there has been a steady stream of vocal support for Ojeda. Much of his discussion also covered statements given by advocates for Rust in the kernel, ranging from lead developers of the kernel and including Linux creator Linus Torvalds himself to technology leads from Red Hat, Samsung, Google, Microsoft and others.

A heated dispute has erupted in the Linux kernel community over the integration of Rust code, with kernel maintainer Christoph Hellwig likening multiple programming languages to "cancer" for the project's maintainability. The conflict centers on a proposed patch enabling Rust-written device drivers to access the kernel's DMA API, which Hellwig strongly opposed. While the dispute isn't about Rust itself, Hellwig argues that maintaining cross-language codebases severely compromises Linux's integrated nature. From a report: "Don't force me to deal with your shiny language of the day," he [Hellwig] wrote. "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned." This resistance follows the September departure of Microsoft engineer Wedson Almeida Filho from the Rust for Linux project, citing "nontechnical nonsense."

"Nothing horrible or unexpected happened last week," Linux Torvalds posted tonight on the Linux kernel mailing list, "so I've tagged and pushed out the final 6.13 release."

Phoronix says the release has "plenty of fine features": Linux 6.13 comes with the introduction of the AMD 3D V-Cache Optimizer driver for benefiting multi-CCD Ryzen X3D processors. The new AMD EPYC 9005 "Turin" server processors will now default to AMD P-State rather than ACPI CPUFreq for better power efficiency....

Linux 6.13 also brings more Rust programming language infrastructure and more.
Phoronix notes that Linux 6.13 also brings "the start of Intel Xe3 graphics bring-up, support for many older (pre-M1) Apple devices like numerous iPads and iPhones, NVMe 2.1 specification support, and AutoFDO and Propeller optimization support when compiling the Linux kernel with the LLVM Clang compiler."

And some lucky Linux kernel developers will also be getting a guitar pedal soldered by Linus Torvalds himself, thanks to a generous offer he announced a week ago: For _me_ a traditional holiday activity tends to be a LEGO build or two, since that's often part of the presents... But in addition to the LEGO builds, this year I also ended up doing a number of guitar pedal kit builds ("LEGO for grown-ups with a soldering iron"). Not because I play guitar, but because I enjoy the tinkering, and the guitar pedals actually do something and are the right kind of "not very complex, but not some 5-minute 555 LED blinking thing"...

[S]ince I don't actually have any _use_ for the resulting pedals (I've already foisted off a few only unsuspecting victims^Hfriends), I decided that I'm going to see if some hapless kernel developer would want one.... as an admittedly pretty weak excuse to keep buying and building kits...
"It may be worth noting that while I've had good success so far, I'm a software person with a soldering iron. You have been warned... [Y]ou should set your expectations along the lines of 'quality kit built by a SW person who doesn't know one end of a guitar from the other.'"

"I know, I know: 'Year of the Linux desktop ... yadda, yadda'," writes Steven Vaughan-Nichols, a ZDNet senior contributing editor. "You've heard it all before. But now there's a Linux-powered PC that many people will want..."

He's talking about Nvidia's newly-announced Project Digits, describing it as "a desktop with AI supercomputer power that runs DGX OS, a customized Ubuntu Linux 22.04 distro." Powered by MediaTek and Nvidia's Grace Blackwell Superchip, Project DIGITS is a $3,000 personal AI that combines Nvidia's Blackwell GPU with a 20-core Grace CPU built on the Arm architecture... At CES, Nvidia CEO Jensen Huang confirmed plans to make this technology available to everyone, not just AI developers. "We're going to make this a mainstream product," Huang said. His statement suggests that Nvidia and MediaTek are positioning themselves to challenge established players — including Intel and AMD — in the desktop CPU market. This move to the desktop and perhaps even laptops has been coming for a while. As early as 2023, Nvidia was hinting that a consumer desktop chip would be in its future... [W]hy not use native Linux as the primary operating system on this new chip family?

Linux, after all, already runs on the Grace Blackwell Superchip. Windows doesn't. It's that simple. Nowadays, Linux runs well with Nvidia chips. Recent benchmarks show that open-source Linux graphic drivers work with Nvidia GPUs as well as its proprietary drivers. Even Linus Torvalds thinks Nvidia has gotten its open-source and Linux act together. In August 2023, Torvalds said, "Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work." Canonical, Ubuntu Linux's parent company, has long worked closely with Nvidia. Ubuntu already provides Blackwell drivers.
The article strays into speculation, when it adds "maybe you wouldn't pay three grand for a Project DIGITS PC. But what about a $1,000 Blackwell PC from Acer, Asus, or Lenovo? All three of these companies are already selling MediaTek-powered Chromebooks...."

"The first consumer products featuring this technology are expected to hit the market later this year. I'm looking forward to running Linux on it. Come on in! The operating system's fine."

Researchers from Inria and Microsoft have developed a system to automatically convert specific types of C programming code into memory-safe Rust code, addressing growing cybersecurity concerns about memory vulnerabilities in software systems.

The technique, detailed in a new paper, requires programmers to use a restricted version of C called "Mini-C" that excludes features like pointer arithmetic. The researchers successfully tested their conversion system on two major code libraries, including the 80,000-line HACL* cryptographic library. Parts of the converted code have already been integrated into Mozilla's NSS and OpenSSH security systems, according to the researchers. Memory safety errors account for 76% of Android vulnerabilities in 2019.

Software development is entering an "autopilot era" with AI coding assistants, but the industry needs to prepare for full autonomy, argues former Salesforce co-CEO Bret Taylor. Drawing parallels with self-driving cars, he suggests the role of software engineers will evolve from code authors to operators of code-generating machines. Taylor, a board member of OpenAI and who once rewrote Google Maps over a weekend, calls for new programming systems, languages, and verification methods to ensure AI-generated code remains robust and secure. From his post: In the Autonomous Era of software engineering, the role of a software engineer will likely transform from being the author of computer code to being the operator of a code generating machine. What is a computer programming system built natively for that workflow?

If generating code is no longer a limiting factor, what types of programming languages should we build?

If a computer is generating most code, how do we make it easy for a software engineer to verify it does what they intend? What is the role of programming language design (e.g., what Rust did for memory safety)? What is the role of formal verification? What is the role of tests, CI/CD, and development workflows?

Today, a software engineer's primary desktop is their editor. What is the Mission Control for a software engineer in the era of autonomous development?

Berlin-based T2 Linux developer René Rebe is also long-time Slashdot reader ReneR — and popped by with a special announcement for the holidays: The T2 Linux team has unveiled T2 Linux SDE 24.12, codenamed "Sky's the Limit!", delivering a massive update for this highly portable source-based Linux distribution... With 3,280 package updates, 206 new features, and the ability to boot on systems with as little as 512MB RAM, this release further strengthens T2 Linux's position as the ultimate tool for developers working across diverse hardware and embedded systems.
Some highlights from Rene's announcement:

• "The release includes 37 pre-compiled ISOs with Glibc, Musl, and uClibc, supporting 25 CPU architectures like ARM(64), RISCV(64), Loongarch64, SPARC(64), and vintage retro computing platforms such as M68k, Alpha, and even initial Nintendo Wii U support added."

• " The Cosmic Desktop, a modern Rust-based environment, debuts alongside expanded application support for non-mainstream RISC architectures, now featuring LibreOffice, OpenJDK, and QEMU."

And T2sde.org gives this glimpse of the future:

"While initially created for the Linux kernel, T2 already has proof-of-concept support for building 'home-brew' pkg for Other OS, including: BSDs, macOS and Haiku. Work on alternative micro kernels, such as L4, Fuchsia, RedoxOS or integrating building 'AOSP' Android is being worked on as well."

"The Rust Foundation is dedicated to ensuring a healthy Rust ecosystem," according to a new announcement today, " which depends on a growing pool of well-trained developers to thrive." The latest SlashData Developer Nation survey found Rust to be the fastest-growing programming language, doubling its users over the past two years. As Rust's adoption continues to accelerate, the demand for a multifaceted ecosystem of quality training will too.
Their blog post highlights three examples of the Rust community "creating new pathways for learning Rust" and "addressing the critical need for Rust training in academic settings..." Rust-Edu operates as a non-profit through Portland State University, with funding from Futurewei. Their mission is to "spread Rust use and development through academic curricula and communities throughout the world, making Rust the language of choice for 'systems programming' in its broadest sense through shared efforts of faculty, students and the Rust community." They focus on three main areas: curriculum development, educational tools, and language improvements...

teach-rs, pronounced "teachers," is a modular and reusable university course designed for in-person teaching in Rust. Its mission is to introduce Rust in higher education and ensure that more students enter the job market with considerable Rust experience. The teach-rs project provides ready-to-use Rust teaching materials, including slide decks and exercises that can be adapted to various teaching contexts... As an open source permissively licensed project, teach-rs enables educators to share and improve resources, making introducing Rust instruction into their programs more accessible. Many institutions now use teach-rs in their courses, including the Slovak University of Technology, RustIEC (a collaboration between Vrije Universiteit Brussel and KU Leuven), and the University Politehnica of Bucharest. At the time of this writing, teach-rs has nearly 3000 stars on GitHub...

Under the guidance of The Rust Foundation's Global Rust Coordinator and Rust Nation UK's organizer Ernest Kissiedu, Mordecai Etukudo (Mart) has developed a guide to help educational institutions adopt Rust in their systems. This resource walks organizations through the entire implementation process, from initial assessment to community engagement.

Greg Kroah-Hartman noted some coming changes in Linux 6.13 will make it possible to create "way more" Rust-based kernel drivers. "The veteran kernel developer believes we're at a tipping point of seeing more upstream Rust drivers ahead," reports Phoronix: These Rust char/misc changes are on top of the main Rust pull for Linux 6.13 that brought 3k lines of code for providing more Rust infrastructure. Linux 6.13 separately is also bringing Rust file abstractions.
"Sorry for doing this at the end of the merge window," Greg Kroah-Hartman wrote in the pull request, explaining that "conference and holiday travel got in the way on my side (hence the 5am pull request emails...)" Loads of things in here...

— Rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present.

Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)

The Rust community has "recognized the unsafety of Rust (if used incorrectly)," according to a blog post by Amazon Web Services.

So now AWS and the Rust Foundation are "crowdsourcing an effort to verify the Rust standard library," according to an article at DevClass.com, "by setting out a series of challenges for devs and offering financial rewards for solutions..." Rust includes ways to bypass its safety guarantees though, with the use of the "unsafe" keyword... The issue AWS highlights is that even if developers use only safe code, most applications still depend on the Rust standard library. AWS states that there are approximately 7.5K unsafe functions in the Rust Standard Library and notes that 57 "soundness issues" and 20 CVEs (Common Vulnerabilities and Exposures) have been reported in the last three years. [28% of the soundness issues were discovered in 2024.]

Marking a function as unsafe does not mean it is vulnerable, only that Rust does not guarantee its safety. AWS plans to reduce the risk by using tools and techniques for formal verification of key library code, but believes that "a single team would be unable to make significant inroads" for reasons including the lack of a verification mechanism in the Rust ecosystem and what it calls the "unknowns of scalable verification." The plan therefore is to turn this over to the community, by posing challenges and rewarding developers for solutions.... A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them... The Rust Foundation says that there is a financial reward tied to each challenge, and that the "challenge rewards committee is responsible for reviewing activity and dispensing rewards." How much will be paid though is not stated.

Despite the wide admiration for Rust, there is no formal specification for the language, an issue which impacts formal verification efforts.
Thanks to Slashdot reader sean-it-all for sharing the news.

The goal? "Make C++ and Rust interoperability easily accessible and approachable to the widest possible audience." And the Rust Foundation's "Interop Initiative" is specifically focused on the goal of interoperability "within the same executable," through either inline embedding that allows "integrated compilation", or foreign function interfaces.

To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.

"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."

Their official problem statement outlines three "key strategic approaches."

- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.

- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.

- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.

And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...

The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.

The Tiobe index tries to track the popularity of programming languages by counting the number of search results for the language's name followed by the word "programming" (on 25 different search engines). And this month there were some surprises...

By TIOBE's reckoning, compared to a year ago PHP has now fallen from #7 to #12, while Delphi/Object Pascal shot up five spots from #16 to #11. In that same year, Fortran jumped from #12 to #8 — while both Visual Basic and SQL dropped down a single rank. Toward the top of the list, C actually fell from the #2 spot over the last 12 months to the #4 spot.

And Go just reached the #7 rank on the TIOBE's ranking of programming language popularity — "an all time high for Go," according to TIOBE CEO Paul Jansen. In this month's note, he explains what he thinks is unusual about this — starting by saying that Go programs are both fast, and easy in many ways — easy to deploy, easy to learn, and easy to understand. Python for instance is easy to learn but not fast, and deployment for larger Python programs is fragile due to dependencies on all kind of versioned libraries in the environment.

If compared to Rust for instance (another contender for a top position), Go is a tiny bit slower, but the Go programs are much easier to understand. The next hurdle for Go in the TIOBE index is JavaScript at position #6. That will be a tough one to pass. JavaScript is ubiquitous in software development, although for larger JavaScript systems we see a shift to TypeScript nowadays.
"If annual trends continue this way, Go will bypass JavaScript within 3 years," TIOBE's CEO predicts. (Adding "Let's see what the future has in store for Go...") Although the Go team actually has specific plans for the future, according to a blog post this week celebrating Go's 15th anniversary: We're working on making Go better for AI — and AI better for Go — by enhancing Go's capabilities in AI infrastructure, applications, and developer assistance. Go is a great language for building production systems, and we want it to be a great language for building production AI systems, too... For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit. And from its very beginning, Go aimed to improve the end-to-end software engineering process, so naturally we're looking at bringing the latest tools and techniques from AI to bear on reducing developer toil, leaving more time for the fun stuff — like actually programming!
TIOBE's top 10 programming language rankings for the month of November:

1. Python
2. C++
3. Java
4. C
5. C#
6. JavaScript
7. Go
8. Fortran
9. Visual Basic
10. SQL