"Rust's rise shows signs of slowing," argues the CEO of TIOBE.

Back in 2020 Rust first entered the top 20 of his "TIOBE Index," which ranks programming language popularity using search engine results. Rust "was widely expected to break into the top 10," he remembers today. But it never happened, and "That was nearly six years ago...." Since then, Rust has steadily improved its ranking, even reaching its highest position ever (#13) at the beginning of this year. However, just three months later, it has dropped back to position #16. This suggests that Rust's adoption rate may be plateauing.

One possible explanation is that, despite its ability to produce highly efficient and safe code, Rust remains difficult to learn for non-expert programmers. While specialists in performance-critical domains are willing to invest in mastering the language, broader mainstream adoption appears more challenging. As a result, Rust's growth in popularity seems to be leveling off, and a top 10 position now appears more distant than before.
Or, could Rust's sudden drop in the rankings just reflect flaws in TIOBE's ranking system? In January GitHub's senior director for developer advocacy argued AI was pushing developers toward typed languages, since types "catch the exact class of surprises that AI-generated code can sometimes introduce... A 2025 academic study found that a whopping 94% of LLM-generated compilation errors were type-check failures." And last month Forbes even described Rust as "the the safety harness for vibe coding.."

A year ago Rust was ranked #18 on TIOBE's index — so it still rose by two positions over the last 12 months, hitting that all-time high in January. Could the rankings just be fluctuating due to anomalous variations in each month's search engine results? Since January Java has fallen to the #4 spot, overtaken by C++ (which moved up one rank to take Java's place in the #3 position).

Here's TIOBE's current estimate for the 10 most popularity programming languages:

1. Python
2. C
3. C++
4. Java
5. C#
6. JavaScript
7. Visual Basic
8. SQL
9. R
10. Delphi/Object Pascal

TIOBE estimates that tthe next five most popular programming languages are Scratch, Perl, Fortran, PHP, and Go.

BrianFagioli writes: Little Snitch, the well known macOS tool that shows which applications are connecting to the internet, is now being developed for Linux. The developer says the project started after experimenting with Linux and realizing how strange it felt not knowing what connections the system was making. Existing tools like OpenSnitch and various command line utilities exist, but none provided the same simple experience of seeing which process is connecting where and blocking it with a click. The Linux version uses eBPF for kernel level traffic interception, with core components written in Rust and a web based interface that can even monitor remote Linux servers.

During testing on Ubuntu, the developer noticed the system was relatively quiet on the network. Over the course of a week, only nine system processes made internet connections. By comparison, macOS reportedly showed more than one hundred processes communicating externally. Applications behave similarly across platforms though. Launching Firefox immediately triggered telemetry and advertising related connections, while LibreOffice made no network connections at all during testing. The early release is meant primarily as a transparency tool to show what software is doing on the network rather than a hardened security firewall.

BrianFagioli writes: Canonical has joined the Rust Foundation as a Gold Member, signaling a deeper investment in the Rust programming language and its role in modern infrastructure. The company already maintains an up-to-date Rust toolchain for Ubuntu and has begun integrating Rust into parts of its stack, citing memory safety and reliability as key drivers. By joining at a higher tier, Canonical is not just adopting Rust but also stepping closer to its governance and long-term direction.

The move also highlights ongoing tensions in Rust's ecosystem. While Rust can reduce entire classes of bugs, it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments. Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond. "As the publisher of Ubuntu, we understand the critical role systems software plays in modern infrastructure, and we see Rust as one of the most important tools for building it securely and reliably. Joining the Rust Foundation at the Gold level allows us to engage more directly in language and ecosystem governance, while continuing to improve the developer experience for Rust on Ubuntu," said Jon Seager, VP Engineering at Canonical. "Of particular interest to Canonical is the security story behind the Rust package registry, crates.io, and minimizing the number of potentially unknown dependencies required to implement core concerns such as async support, HTTP handling, and cryptography -- especially in regulated environments."

Interesting Engineering reports: US tech giant Google announced on Tuesday that it will build a new data center in Pine Island, Minnesota. The new facility will be powered by 1.9 gigawatts (GW) of clean energy from wind and solar, coupled with a 300-megawatt battery, claimed to be the 'world's largest', with a 30-gigawatt-hour (GWh) capacity and 100-hour duration... The planned battery would dwarf a 19 GW lithium-ion project in the UAE...

Form Energy's batteries work very differently from most large batteries today. Instead of using lithium like the batteries in electric cars, they store electricity by making iron rust and then reversing the rusting process to release the energy when needed... Form's iron-air batteries are heavier and less efficient than their counterparts; they can only return about 50% to 70% of the energy used to charge them, while lithium-ion batteries return more than 90%. However, Form's batteries have one distinct advantage. They are cheaper than lithium-ion batteries, costing about $20 per kilowatt-hour of storage, which is almost three times as cheap... It will store 150 MWh of electricity and can supply to the grid for up to 100 hours, delivering about 1.5 MW at peak output.
Thanks to long-time Slashdot reader schwit1 for sharing the article.

Google and Microsoft contributed $5 million to launch Alpha-Omega in 2022 — a Linux Foundation project to help secure the open source supply chain. But its co-founder Michael Winser warns that open source registries are in financial peril, reports The Register, since they're still relying on non-continuous funding from grants and donations.

And it's not just because bandwidth is expensive, he said at this year's FOSDEM. "The problem is they don't have enough money to spend on the very security features that we all desperately need..." In a follow-up LinkedIn exchange after this article had posted, Winser estimated it could cost $5 million to $8 million a year to run a major registry the size of Crates.io, which gets about 125 billion downloads a year. And this number wouldn't include any substantial bandwidth and infrastructure donations (Like Fastly's for Crates.io). Adding to that bill is the growing cost of identifying malware, the proliferation of which has been amplified through the use of AI and scripts. These repositories have detected 845,000 malware packages from 2019 to January 2025 (the vast majority of those nasty packages came to npm)...

In some cases benevolent parties can cover [bandwidth] bills: Python's PyPI registry bandwidth needs for shipping copies of its 700,000+ packages (amounting to 747PB annually at a sustained rate of 189 Gbps) are underwritten by Fastly, for instance. Otherwise, the project would have to pony up about $1.8 million a month. Yet the costs Winser was most concerned about are not bandwidth or hosting; they are the security features needed to ensure the integrity of containers and packages. Alpha-Omega underwrites a "distressingly" large amount of security work around registries, he said. It's distressing because if Alpha-Omega itself were to miss a funding round, a lot of registries would be screwed. Alpha-Omega's recipients include the Python Software Foundation, Rust Foundation, Eclipse Foundation, OpenJS Foundation for Node.js and jQuery, and Ruby Central.

Donations and memberships certainly help defray costs. Volunteers do a lot of what otherwise would be very expensive work. And there are grants about...Winser did not offer a solution, though he suggested the key is to convince the corporate bean counters to consider paid registries as "a normal cost of doing business and have it show up in their opex as opposed to their [open source program office] donation budget."
The dilemma was summed up succinctly by the anonymous Slashdot reader who submitted this story.

"Free beer is great. Securing the keg costs money!"

Created in 1993, Slackware is considered the oldest Linux distro that's still actively maintained. And more than three decades later... there's a new release! (And there's also a Slackware Live Edition that can run from a DVD or USB stick...) .

Slackware's latest version was released way back in 2016, notes the blog It's FOSS: The major highlight of Slackware 15 is the addition of the latest Linux Kernel 5.15 LTS. This is a big jump from Linux Kernel 5.10 LTS that we noticed in the beta release. Interestingly, the Slackware team tested hundreds of Linux Kernel versions before settling on Linux Kernel 5.15.19. The release note mentions... "We finally ended up on kernel version 5.15.19 after Greg Kroah-Hartman confirmed that it would get long-term support until at least October 2023 (and quite probably for longer than that)."

In case you are curious, Linux Kernel 5.15 brings in updates like enhanced NTFS driver support and improvements for Intel/AMD processors and Apple's M1 chip. It also adds initial support for Intel 12th gen processors. Overall, with Linux Kernel 5.15 LTS, you should get a good hardware compatibility result for the oldest active Linux distro.
Slackware's announcement says "The challenge this time around was to adopt as much of the good stuff out there as we could without changing the character of the operating system. Keep it familiar, but make it modern." And boy did we have our work cut out for us. We adopted privileged access management (PAM) finally, as projects we needed dropped support for pure shadow passwords. We switched from ConsoleKit2 to elogind, making it much easier to support software that targets that Other Init System and bringing us up-to-date with the XDG standards. We added support for PipeWire as an alternate to PulseAudio, and for Wayland sessions in addition to X11. Dropped Qt4 and moved entirely to Qt5. Brought in Rust and Python 3. Added many, many new libraries to the system to help support all the various additions.

We've upgraded to two of the finest desktop environments available today: Xfce 4.16, a fast and lightweight but visually appealing and easy to use desktop environment, and the KDE Plasma 5 graphical workspaces environment, version 5.23.5 (the Plasma 25th Anniversary Edition). This also supports running under Wayland or X11. We still love Sendmail, but have moved it into the /extra directory and made Postfix the default mail handler. The old imapd and ipop3d have been retired and replaced by the much more featureful Dovecot IMAP and POP3 server.
"As usual, the kernel is provided in two flavors, generic and huge," according to the release notes. "The huge kernel contains enough built-in drivers that in most cases an initrd is not needed to boot the system."

If you'd like to support Slackware, there's an official Patreon account. And the release announcement ends with this personal note: Sadly, we lost a couple of good friends during this development cycle and this release is dedicated to them. Erik "alphageek" Jan Tromp passed away in 2020 after a long illness... My old friend Brett Person also passed away in 2020. Without Brett, it's possible that there wouldn't be any Slackware as we know it — he's the one who encouraged me to upload it to FTP back in 1993 and served as Slackware's original beta-tester. He was long considered a co-founder of this project. I knew Brett since the days of the Beggar's Banquet BBS in Fargo back in the 1980's... Gonna miss you too, pal.
Thanks to long-time Slashdot reader rastos1 for sharing thre news.

Anthropic researcher Nicholas Carlini set 16 instances of Claude Opus 4.6 loose on a shared codebase over two weeks to build a C compiler from scratch, and the AI agents produced a 100,000-line Rust-based compiler capable of building a bootable Linux 6.9 kernel on x86, ARM and RISC-V architectures.

The project ran through nearly 2,000 Claude Code sessions and cost about $20,000 in API fees. Each instance operated inside its own Docker container, independently claiming tasks via lock files and pushing completed code to a shared Git repository. No orchestration agent directed traffic. The compiler achieved a 99% pass rate on the GCC torture test suite and can compile major open source projects including PostgreSQL, SQLite, Redis, FFmpeg and Doom. But it lacks a 16-bit x86 backend and calls out to GCC for that step, its assembler and linker remain buggy, and it produces less efficient code than GCC running with all optimizations disabled.

Carlini also invested significant effort building test harnesses and feedback systems to keep the agents productive, and the model hit a practical ceiling at around 100,000 lines as bug fixes and new features frequently broke existing functionality.

After more than 30 years of development, GNU gettext finally "crossed the symbolic 'v1.0' milestone," according to Phoronix's Michael Larabel. "GNU gettext 1.0 brings PO file handling improvements, a new 'po-fetch' program to fetch translated PO files from a translation project's site on the Internet, new 'msgpre' and 'spit' pre-translation programs, and Ocaml and Rust programming language improvements." From the report: With this v1.0 release in 2026, the "msgpre" and "spit" programs do involve.... Large Language Models (LLMs) in the era of AI: "Two new programs, 'msgpre' and 'spit', are provided, that implement machine translation through a locally installed Large Language Model (LLM). 'msgpre' applies to an entire PO file, 'spit' to a single message."

And when dealing with LLMs, added documentation warns users to look out for the licensing of the LLM in the spirit of free software. More details on the GNU gettext 1.0 changes via the NEWS file. GNU gettext 1.0 can be downloaded from GNU.org.

Richard Stallman spoke Friday at Atlanta's Georgia Institute of Technology, continuing his activism for free software while also addressing today's new technologies.

Speaking about AI, Stallman warned that "nowadays, people often use the term artificial intelligence for things that aren't intelligent at all..." He makes a point of calling large language models "generators" because "They generate text and they don't understand really what that text means." (And they also make mistakes "without batting a virtual eyelash. So you can't trust anything that they generate.") Stallman says "Every time you call them AI, you are endorsing the claim that they are intelligent and they're not. So let's let's refuse to do that."

"So I've come up with the term Pretend Intelligence. We could call it PI. And if we start saying this more often, we might help overcome this marketing hype campaign that wants people to trust those systems, and trust their lives and all their activities to the control of those systems and the big companies that develop and control them."

"By the way, as far as I can tell, none of them is free software."

When it comes to today's cars, Stallman says they contain "malicious functionalities... Cars should not be connected. They should not upload anything." (He adds that "I am hoping to find a skilled mechanic to work with me in a project to make disconnected cars.")

And later Stallman calls the smartphone "an Orwellian tracking and surveillance device," saying he refuses to own one. (An advantage of free software is that it allows the removal of malicious functionalities.)

Stallman spoke for about 53 minutes — but then answered questions for nearly 90 minutes longer. Here's some of the highlights...

After widespread backlash over its 2022 decision to remove JPEG-XL support, Google has quietly restored the image format in the latest Chrome/Chromium codebase. Phoronix reports: Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support. Now as of yesterday they wired up the JXL decoder! The jxl-rs-powered JPEG-XL image decoding is gated by the enable_jxl_decoder build flag but it's enabled by default.

Gentoo Linux posted its 2025 project retrospective this week. Some interesting details: Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg. Codeberg is a site based on Forgejo, maintained by a non-profit organization, and located in Berlin, Germany. Gentoo continues to host its own primary git, bugs, etc infrastructure and has no plans to change that...

We now publish weekly Gentoo images for Windows Subsystem for Linux (WSL), based on the amd64 stages, see our mirrors. While these images are not present in the Microsoft store yet, that's something we intend to fix soon...

Given the unfortunate fracturing of the GnuPG / OpenPGP / LibrePGP ecosystem due to competing standards, we now provide an alternatives mechanism to choose the system gpg provider and ease compatibility testing...

We have added a bootstrap path for Rust from C++ using Mutabah's Rust compiler mrustc, which alleviates the need for pre-built binaries and makes it significantly easier to support more configurations. Similarly, Ada and D support in gcc now have clean bootstrap paths, which makes enabling these in the compiler as easy as switching the useflags on gcc and running emerge.
Other interesting statistics for the year:

• Gentoo currently consists of 31,663 ebuilds for 19,174 different packages.
• For amd64 (x86-64), there are 89 GBytes of binary packages available on the mirrors.
• Gentoo each week builds 154 distinct installation stages for different processor architectures and system configurations, with an overwhelming part of these fully up-to-date.
• The number of commits to the main ::gentoo repository has remained at an overall high level in 2025, with a slight decrease from 123,942 to 112,927.
• The number of commits by external contributors was 9,396, now across 377 unique external authors.

Thanks to long-time Slashdot reader Heraklit for sharing the 2025 retrospective.

For a quarter century, the TIOBE Index has attempted to rank the popularity of programming languages by the number of search engine results they bring up — and this week they had an announcement.

Over the last year the language showing the largest increase in its share of TIOBE's results was C#.

TIOBE founder/CEO Paul Jansen looks back at how C++ evolved: From a language-design perspective, C# has often been an early adopter of new trends among mainstream languages. At the same time, it successfully made two major paradigm shifts: from Windows-only to cross-platform, and from Microsoft-owned to open source. C# has consistently evolved at the right moment.

For many years now, there has been a direct battle between Java and C# for dominance in the business software market. I always assumed Java would eventually prevail, but after all this time the contest remains undecided. It is an open question whether Java — with its verbose, boilerplate-heavy style and Oracle ownership — can continue to keep C# at bay.
While C# remains stuck in the same #5 position it was in a year ago, its share of TIOBE's results rose 2.94% — the largest increase of the 100 languages in their rankngs.

But TIOBE's CEO notes that his rankings for the top 10 highest-scoring languages delivered "some interesting movements" in 2025: C and C++ swapped positions. [C rose to the #2 position — behind Python — while C++ dropped from #2 to the #4 rank that C held in January of 2025]. Although C++ is evolving faster than ever, some of its more radical changes — such as the modules concept — have yet to see widespread industry adoption. Meanwhile, C remains simple, fast, and extremely well suited to the ever-growing market of small embedded systems. Even Rust has struggled to penetrate this space, despite reaching an all-time high of position #13 this month.

So who were the other winners of 2025, besides C#? Perl made a surprising comeback, jumping from position #32 to #11 and re-entering the top 20. Another language returning to the top 10 is R, driven largely by continued growth in data science and statistical computing.

Of course, where there are winners, there are also losers. Go appears to have permanently lost its place in the top 10 during 2025. The same seems true for Ruby, which fell out of the top 20 and is unlikely to return anytime soon.

What can we expect from 2026? I have a long history of making incorrect predictions, but I suspect that TypeScript will finally break into the top 20. Additionally, Zig, which climbed from position #61 to #42 in 2025, looks like a strong candidate to enter the TIOBE top 30.
Here's how TIOBE estimated the 10 most popularity programming languages at the end of 2025

1. Python
2. C
3. Java
4. C++
5. C#
6. JavaScript
7. Visual Basic
8. SQL
9. Delphi/Object Pascal
10. R

Microsoft has denied any plans to rewrite Windows 11 using AI and Rust after a LinkedIn post from one of its top-level engineers sparked a wave of online backlash by claiming the company's goal was to "eliminate every line of C and C++ from Microsoft by 2030."

Galen Hunt, a principal software engineer responsible for several large-scale research projects at Microsoft, made the claim in what was originally a hiring post for his team. His original wording described a "North Star" of "1 engineer, 1 month, 1 million lines of code" and outlined a strategy to "combine AI and Algorithms to rewrite Microsoft's largest codebases." The repeated use of "our" in the post led many to interpret it as an official company direction rather than a personal research ambition.

Frank X. Shaw, Microsoft's head of communications, told Windows Latest that the company has no such plans. Hunt subsequently edited his LinkedIn post to clarify that "Windows is NOT being rewritten in Rust with AI" and that his team's work is a research project focused on building technology to enable language-to-language migration. He characterized the reaction as "speculative reading between the lines."

theodp writes: We all mix pictures, emojis, and text freely in our communications. So why not in our code? That's the premise of "Fun With Python and Emoji: What Might Adding Pictures to Text Programming Languages Look Like?" (two-image Bluesky explainer; full slides), which takes a look at what mixing emoji with Python and SQL might look like. A GitHub repo includes a Google Colab-ready Python notebook proof of concept that does rudimentary emoji-to-text translation via an IPython input transformer.

So, in the Golden Age of AI -- some 60+ years after Kenneth Iverson introduced the chock-full-of-symbols APL -- are valid technical reasons still keeping symbols and pictures out of code, or is their absence more of a programming dogma thing?

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."

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.

Longtime Linux developer Greg Kroah-Hartman announced that the Linux kernel has received its first CVE tied to Rust code. Phoronix reports: This first CVE (CVE-2025-68260) for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash. This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.

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.

This week System76 launched the first stable release of its Rust-based COSMIC desktop environment. Announced in 2021, it's designed for all GNU/Linux distributions — and it shipping with Pop!_OS 24.04 LTS (based on Ubuntu 24.04 LTS).

An anonymous reader shared this report from 9to5Linux: Previous Pop!_OS releases used a version of the COSMIC desktop that was based on the GNOME desktop environment. However, System76 wanted to create a new desktop environment from scratch while keeping the same familiar interface and user experience built for efficiency and fun. This means that some GNOME apps have been replaced by COSMIC apps, including COSMIC Files instead of Nautilus (Files), COSMIC Terminal instead of GNOME Terminal, COSMIC Text Editor instead of GNOME Text Editor, and COSMIC Media Player instead of Totem (Video Player).

Also, the Pop!_Shop graphical package manager used in previous Pop!_OS releases has now been replaced by a new app called COSMIC Store.
"If you're ambitious enough, or maybe just crazy enough, there eventually comes a time when you realize you've reached the limits of current potential, and must create something completely new if you're to go further..." explains System76 founder/CEO Carl Richell: For twenty years we have shipped Linux computers. For seven years we've built the Pop!_OS Linux distribution. Three years ago it became clear we had reached the limit of our current potential and had to create something new. Today, we break through that limit with the release of Pop!_OS 24.04 LTS with the COSMIC Desktop Environment. Today is special not only in that it's the culmination of over three years of work, but even more so in that System76 has built a complete desktop environment for the open source community... I hope you love what we've built for you. Now go out there and create. Push the limits, make incredible things, and have fun doing it!

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.