BrianFagioli writes: Google has released Magika 1.0, a stable version of its AI-based file type detection tool, and rebuilt the entire engine in Rust for speed and memory safety. The system now recognizes more than 200 file types, up from about 100, and is better at distinguishing look-alike formats such as JSON vs JSONL, TSV vs CSV, C vs C++, and JavaScript vs TypeScript. The team used a 3TB training dataset and even relied on Gemini to generate synthetic samples for rare file types, allowing Magika to handle formats that don't have large, publicly available corpora. The tool supports Python and TypeScript integrations and offers a native Rust command-line client.

Under the hood, Magika uses ONNX Runtime for inference and Tokio for parallel processing, allowing it to scan around 1,000 files per second on a modern laptop core and scale further with more CPU cores. Google says this makes Magika suitable for security workflows, automated analysis pipelines, and general developer tooling. Installation is a single curl or PowerShell command, and the project remains fully open source. The project is available on GitHub and documentation can be found here.

A curious engineer discovered that his iLife A11 smart vacuum was remotely "killed" after he blocked it from sending data to the manufacturer's servers. By reverse-engineering it with custom hardware and Python scripts, he managed to revive the device to run fully offline. Tom's Hardware reports: An engineer got curious about how his iLife A11 smart vacuum worked and monitored the network traffic coming from the device. That's when he noticed it was constantly sending logs and telemetry data to the manufacturer -- something he hadn't consented to. The user, Harishankar, decided to block the telemetry servers' IP addresses on his network, while keeping the firmware and OTA servers open. While his smart gadget worked for a while, it just refused to turn on soon after. After a lengthy investigation, he discovered that a remote kill command had been issued to his device.

He sent it to the service center multiple times, wherein the technicians would turn it on and see nothing wrong with the vacuum. When they returned it to him, it would work for a few days and then fail to boot again. After several rounds of back-and-forth, the service center probably got tired and just stopped accepting it, saying it was out of warranty. Because of this, he decided to disassemble the thing to determine what killed it and to see if he could get it working again. [...] So, why did the A11 work at the service center but refuse to run in his home? The technicians would reset the firmware on the smart vacuum, thus removing the kill code, and then connect it to an open network, making it run normally. But once it connected again to the network that had its telemetry servers blocked, it was bricked remotely because it couldn't communicate with the manufacturer's servers. Since he blocked the appliance's data collection capabilities, its maker decided to just kill it altogether.

"Someone -- or something -- had remotely issued a kill command," says Harishankar. "Whether it was intentional punishment or automated enforcement of 'compliance,' the result was the same: a consumer device had turned on its owner." In the end, the owner was able to run his vacuum fully locally without manufacturer control after all the tweaks he made. This helped him retake control of his data and make use of his $300 software-bricked smart device on his own terms. As for the rest of us who don't have the technical knowledge and time to follow his accomplishments, his advice is to "Never use your primary WiFi network for IoT devices" and to "Treat them as strangers in your home."

"An engineer got curious about how his iLife A11 smart vacuum worked and monitored the network traffic coming from the device," writes Tom's Hardware.

"That's when he noticed it was constantly sending logs and telemetry data to the manufacturer — something he hadn't consented to." The user, Harishankar, decided to block the telemetry servers' IP addresses on his network, while keeping the firmware and OTA servers open. While his smart gadget worked for a while, it just refused to turn on soon after... He sent it to the service center multiple times, wherein the technicians would turn it on and see nothing wrong with the vacuum. When they returned it to him, it would work for a few days and then fail to boot again... [H]e decided to disassemble the thing to determine what killed it and to see if he could get it working again...

[He discovered] a GD32F103 microcontroller to manage its plethora of sensors, including Lidar, gyroscopes, and encoders. He created PCB connectors and wrote Python scripts to control them with a computer, presumably to test each piece individually and identify what went wrong. From there, he built a Raspberry Pi joystick to manually drive the vacuum, proving that there was nothing wrong with the hardware. From this, he looked at its software and operating system, and that's where he discovered the dark truth: his smart vacuum was a security nightmare and a black hole for his personal data.

First of all, it's Android Debug Bridge, which gives him full root access to the vacuum, wasn't protected by any kind of password or encryption. The manufacturer added a makeshift security protocol by omitting a crucial file, which caused it to disconnect soon after booting, but Harishankar easily bypassed it. He then discovered that it used Google Cartographer to build a live 3D map of his home. This isn't unusual, by far. After all, it's a smart vacuum, and it needs that data to navigate around his home. However, the concerning thing is that it was sending off all this data to the manufacturer's server. It makes sense for the device to send this data to the manufacturer, as its onboard SoC is nowhere near powerful enough to process all that data. However, it seems that iLife did not clear this with its customers.

Furthermore, the engineer made one disturbing discovery — deep in the logs of his non-functioning smart vacuum, he found a command with a timestamp that matched exactly the time the gadget stopped working. This was clearly a kill command, and after he reversed it and rebooted the appliance, it roared back to life.
Thanks to long-time Slashdot reader registrations_suck for sharing the article.

TypeScript overtook Python and JavaScript in August 2025 to become the most used language on GitHub. The shift marked the most significant language change in more than a decade. The language grew by over 1 million contributors in 2025, a 66% increase year over year, and finished August with 2,636,006 monthly contributors.

Nearly every major frontend framework now scaffolds projects in TypeScript by default. Next.js 15, Astro 3, SvelteKit 2, Qwik, SolidStart, Angular 18, and Remix all generate TypeScript codebases when developers create new projects. Type systems reduce ambiguity and catch errors from large language models before production. A 2025 academic study found 94% of LLM-generated compilation errors were type-check failures. Tooling like Vite, ts-node, Bun, and I.D.E. autoconfig hide boilerplate setup. Among new repositories created in the past twelve months, TypeScript accounted for 5,394,256 projects. That represented a 78% increase from the prior year.

The Python Software Foundation rejected a $1.5 million U.S. government grant because it required them to renounce all diversity, equity, and inclusion initiatives. "The non-profit would've used the funding to help prevent supply chain attacks; create a new automated, proactive review process for new PyPI packages; and make the project's work easily transferable to other open-source package managers," reports The Register. From the report: The programming non-profit's deputy executive director Loren Crary said in a blog post today that the National Science Founation (NSF) had offered $1.5 million to address structural vulnerabilities in Python and the Python Package Index (PyPI), but the Foundation quickly became dispirited with the terms (PDF) of the grant it would have to follow. "These terms included affirming the statement that we 'do not, and will not during the term of this financial assistance award, operate any programs that advance or promote DEI [diversity, equity, and inclusion], or discriminatory equity ideology in violation of Federal anti-discrimination laws,'" Crary noted. "This restriction would apply not only to the security work directly funded by the grant, but to any and all activity of the PSF as a whole."

To make matters worse, the terms included a provision that if the PSF was found to have voilated that anti-DEI diktat, the NSF reserved the right to claw back any previously disbursed funds, Crary explained. "This would create a situation where money we'd already spent could be taken back, which would be an enormous, open-ended financial risk," the PSF director added. The PSF's mission statement enshrines a commitment to supporting and growing "a diverse and international community of Python programmers," and the Foundation ultimately decided it wasn't willing to compromise on that position, even for what would have been a solid financial boost for the organization. "The PSF is a relatively small organization, operating with an annual budget of around $5 million per year, with a staff of just 14," Crary added, noting that the $1.5 million would have been the largest grant the Foundation had ever received - but it wasn't worth it if the conditions were undermining the PSF's mission. The PSF board voted unanimously to withdraw its grant application.

Long-time Slashdot reader theodp took a good look at the images on a promotional web page for Databricks' "context-aware AI assistant": If there was an AI Demo Hall of Shame, the first inductee would have to be Amazon. Their demo tried to support its CEO's claims that Amazon Q Code Transformation AI saved it 4,500 developer-years and an additional $260 million in "annualized efficiency gains" by automatically and accurately upgrading code to a more current version of Java. But it showcased a program that didn't even spell "Java" correctly. (It was instead called 'Jave')...

Today's nominee for the AI Demo Hall of Shame inductee is analytics platform Databricks for the NYC Taxi Trips Analysis it's been showcasing on its Data Science page since last November. Not only for its choice of a completely trivial case study that requires no 'Data Science' skills — find and display the ten most expensive and longest taxi rides — but also for the horrible AI-generated bar chart used to present the results of the simple ranking that deserves its own spot in the Graph Hall of Shame. In response to a prompt of "Now create a new bar chart with matplotlib for the most expensive trips," the Databricks AI Assistant dutifully complies with the ill-advised request, spewing out Python code to display the ten rides on a nonsensical bar chart whose continuous x-axis hides points sharing the same distance. (One might also question why no annotation is provided to call out or explain the 3 trips with a distance of 0 miles that are among the ten most expensive rides, with fares of $260, $188, and $105).

Looked at with a critical eye, these examples used to sell data scientists, educators, management, investors, and Wall Street on AI would likely raise eyebrows rather than impress their intended audiences.

The Register reports: Over the past two years, the open source curl project has been flooded with bogus bug reports generated by AI models. The deluge prompted project maintainer Daniel Stenberg to publish several blog posts about the issue in an effort to convince bug bounty hunters to show some restraint and not waste contributors' time with invalid issues. Shoddy AI-generated bug reports have been a problem not just for curl, but also for the Python community, Open Collective, and the Mesa Project.

It turns out the problem is people rather than technology. Last month, the curl project received dozens of potential issues from Joshua Rogers, a security researcher based in Poland. Rogers identified assorted bugs and vulnerabilities with the help of various AI scanning tools. And his reports were not only valid but appreciated. Stenberg in a Mastodon post last month remarked, "Actually truly awesome findings." In his mailing list update last week, Stenberg said, "most of them were tiny mistakes and nits in ordinary static code analyzer style, but they were still mistakes that we are better off having addressed. Several of the found issues were quite impressive findings...."

Stenberg told The Register that about 50 bugfixes based on Rogers' reports have been merged. "In my view, this list of issues achieved with the help of AI tooling shows that AI can be used for good," he said in an email. "Powerful tools in the hand of a clever human is certainly a good combination. It always was...!" Rogers wrote up a summary of the AI vulnerability scanning tools he tested. He concluded that these tools — Almanax, Corgea, ZeroPath, Gecko, and Amplify — are capable of finding real vulnerabilities in complex code.
The Register's conclusion? AI tools "when applied with human intelligence by someone with meaningful domain experience, can be quite helpful."

jantangring (Slashdot reader #79,804) has published an article on Stenberg's new position, including recently published comments from Stenberg that "It really looks like these new tools are finding problems that none of the old, established tools detect."

IEEE Spectrum ranks the popularity of programming languages — but is there a problem? Programmers "are turning away from many of these public expressions of interest. Rather than page through a book or search a website like Stack Exchange for answers to their questions, they'll chat with an LLM like Claude or ChatGPT in a private conversation." And with an AI assistant like Cursor helping to write code, the need to pose questions in the first place is significantly decreased. For example, across the total set of languages evaluated in the Top Programming Languages, the number of questions we saw posted per week on Stack Exchange in 2025 was just 22% of what it was in 2024...

However, an even more fundamental problem is looming in the wings... In the same way most developers today don't pay much attention to the instruction sets and other hardware idiosyncrasies of the CPUs that their code runs on, which language a program is vibe coded in ultimately becomes a minor detail... [T]he popularity of different computer languages could become as obscure a topic as the relative popularity of railway track gauges... But if an AI is soothing our irritations with today's languages, will any new ones ever reach the kind of critical mass needed to make an impact? Will the popularity of today's languages remain frozen in time?
That's ultimately the larger question. "how much abstraction and anti-foot-shooting structure will a sufficiently-advanced coding AI really need...?" [C]ould we get our AIs to go straight from prompt to an intermediate language that could be fed into the interpreter or compiler of our choice? Do we need high-level languages at all in that future? True, this would turn programs into inscrutable black boxes, but they could still be divided into modular testable units for sanity and quality checks. And instead of trying to read or maintain source code, programmers would just tweak their prompts and generate software afresh.

What's the role of the programmer in a future without source code? Architecture design and algorithm selection would remain vital skills... How should a piece of software be interfaced with a larger system? How should new hardware be exploited? In this scenario, computer science degrees, with their emphasis on fundamentals over the details of programming languages, rise in value over coding boot camps.

Will there be a Top Programming Language in 2026? Right now, programming is going through the biggest transformation since compilers broke onto the scene in the early 1950s. Even if the predictions that much of AI is a bubble about to burst come true, the thing about tech bubbles is that there's always some residual technology that survives. It's likely that using LLMs to write and assist with code is something that's going to stick. So we're going to be spending the next 12 months figuring out what popularity means in this new age, and what metrics might be useful to measure.
Having said that, IEEE Spectrum still ranks programming language popularity three ways — based on use among working programmers, demand from employers, and "trending" in the zeitgeist — using seven different metrics.

Their results? Among programmers, "we see that once again Python has the top spot, with the biggest change in the top five being JavaScript's drop from third place last year to sixth place this year. As JavaScript is often used to create web pages, and vibe coding is often used to create websites, this drop in the apparent popularity may be due to the effects of AI... In the 'Jobs' ranking, which looks exclusively at what skills employers are looking for, we see that Python has also taken 1st place, up from second place last year, though SQL expertise remains an incredibly valuable skill to have on your resume."

Long-time Slashdot reader theodp says America's Patent and Trademark Office (USPTO) has granted a patent to Tableau (Salesforce's visual analytics platform) — for a patent covering "Data Processing For Visualizing Hierarchical Data": "A provided data model may include a tree specification that declares parent-child relationships between objects in the data model. In response to a query associated with objects in the data model: employing the parent-child relationships to determine a tree that includes parent objects and child objects from the objects based on the parent-child relationships; determining a root object based on the query and the tree; traversing the tree from the root object to visit the child objects in the tree; determining partial results based on characteristics of the visited child objects such that the partial results are stored in an intermediate table; and providing a response to the query that includes values based on the intermediate table and the partial results."

A set of 15 simple drawings is provided to support the legal and tech gobbledygook of the invention claims. A person can have a manager, Tableau explains in Figures 5-6 of its accompanying drawings, and that manager can also manage and be managed by other people. Not only that, Tableau illustrates in Figures 7-10 that computers can be used to count how many people report to a manager. How does this magic work, you ask? Well, you "generate [a] tree" [Fig. 13] and "traverse a tree" [Fig. 15], Tableau explains. But wait, there's more — you can also display the people who report to a manager in multi-level or nested pie charts (aka Sunburst charts), Tableau demonstrates in Fig. 11.

Interestingly, Tableau released a "pre-Beta" Sunburst chart type in late April 2023 but yanked it at the end of June 2023 (others have long-supported Sunburst charts, including Plotly). So, do you think Tableau should be awarded a patent in 2025 on a concept that has roots in circa-1921 Sunburst charts and tree algorithms taught to first-year CS students in circa-1975 Data Structures courses?

An anonymous reader quotes a report from The Register: Renewable energy sources could power datacenters at a lower cost than relying on nuclear generation from small modular reactors (SMRs), claims a recently revealed study. ... [A]nalysis from the Centre for Net Zero (CNZ) says it would cost 43 percent less to power a 120 MW data facility with renewables and a small amount of gas-generated energy, when compared with an SMR. It claims that a microgrid comprising offshore wind, solar, battery storage, and backed up by gas generation, would be significantly cheaper to run annually than procuring power sourced from a nuclear SMR.

[...] CNZ describes itself as an open research institute, founded by Octopus Energy Group in the UK, and claims to advise the State of California and Europe's International Energy Agency as well as the British government. While CNZ's study applies to the UK sector, where energy costs are among the highest in the industrialized world, it is likely that the overall conclusion would still be valid in other countries as well. Its analysis shows that renewables can meet 80 percent of the constant demand from a large datacenter over the course of a year. Offshore wind can provide the majority of load requirements, with gas generation backed by battery storage as a stopgap source of power representing the most cost-optimal mix.

Greater capacity in the on-site battery storage system would reduce the reliance on gas power, and this would likely happen over time as the cost of such systems is expected to come down, the report claims. But perhaps the real kicker is that CNZ estimates that microgrids powered largely by renewables could be built in approximately five years, while operational SMRs are not expected to be widely available until sometime in the next decade. CNZ says that it calculated the typical yearly resource cost (capex and opex) of powering a datacenter with a nuclear SMR, and modeled this using Python for Power System Analysis (PyPSA), an open source energy modeling tool, against two renewable energy scenarios. One was the wind, solar, battery, and gas mix, while the other omitted solar.

BrianFagioli shares a report from NERDS.xyz: The Fedora Project has announced Fedora Linux 43 Beta, giving users and developers the opportunity to test the distribution ahead of its final release. This beta introduces improvements across installation, system tools, and programming languages while continuing Fedora's pattern of cleaning out older components. The beta can be downloaded in Workstation, KDE Plasma, Server, IoT, and Cloud editions. Spins and Labs are also available, though Mate and i3 are not provided in some builds. Existing systems can be upgraded with DNF system-upgrade. Fedora CoreOS will follow one week later through its "next" stream. The beta brings enhancements to its Anaconda WebUI, moves to Python 3.14, and supports Wayland-only GNOME, among many other changes. A full list of improvements and system enhancements can be found here.

The official release should be available in late October or early November.

TIOBE attempts to calculate programming language popularity using the number of skilled engineers, courses, and third-party vendors.

And the eight most popular languages in September's rankings haven't changed since last month:

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

But by TIOBE's ranking, Perl is still the #10 most-popular programming in September (dropping from #9 in August). "One year ago Perl was at position 27 and now it suddenly pops up at position 10 again," marvels TIOBE CEO Paul Jansen. The technical reason why Perl is rated this high is because of its huge number of books on Amazon. It has 4 times more books listed than for instance PHP, or 7 times more books than Rust. The underlying "real" reason for Perl's increase of popularity is unknown to me. The only possibility I can think of is that Perl 5 is now gradually considered to become the real Perl... Perl 6/Raku is at position 129 of the TIOBE index, thus playing no role at all in the programming world. Perl 5 on the other hand is releasing more often recently, thus gaining attention.
An article at the i-Programmer blog thinks Perl's resurgence could be from its text processing capabilities: Even in this era of AI, everything is still governed by text formats; text is still the King. XML, JSON calling APIs, YAML, Markdown, Log files..That means that there's still need to process it, transform it, clean it, extract from it. Perl with its first-class-citizen regular expressions, the wealth of text manipulation libraries up on CPAN and its full Unicode support of all the latest standards, was and is still the best. Simply there's no other that can match Perl's text processing capabilities.
They also cite Perl's backing by the open source community, and its "getting a 'proper' OOP model in the last couple of years... People just don't know what Perl is capable of and instead prefer to be victims of FOMO ephemeral trends, chasing behind the new and shiny."

Perl creator Larry Wall answered questions from Slashdot's readers in 2016. So I'd be curious from Slashdot's readers about Perl today. (Share your experiences in the comments if you're still using Perl -- or Raku...)

Perl's drop to #9 means Delphi/Object Pascal rises up one rank, growing from 1.82% in August to 2.26% in September to claim September's #9 spot. "At number 11 and 1.86%, SQL is quite close to entering the top 10 again," notes TechRepublic. (SQL fell to #12 in June, which the site speculated was due to "the increased use of NoSQL databases for AI applications.")

But TechRepublic adds that the #1 most popular programming language (according to TIOBE) is still Python: Perl sits at 2.03% in TIOBE's proprietary ranking system in September, up from 0.64% in January. Last year, Perl held the 27th position... Python's unstoppable rise dipped slightly from 26.14% in August to 25.98% in September. Python is still well ahead of every other language on the index.

"From a side project in Amsterdam to powering AI at the world's biggest companies — this is the story of Python," says the description of a new 84-minute documentary.

Long-time Slashdot reader destinyland writes: It traces Python all the way back to its origins in Amsterdam back in 1991. (Although the first time Guido van Rossum showed his new language to a co-worker, they'd typed one line of code just to prove they could crash Python's first interpreter.) The language slowly spread after van Rossum released it on Usenet — split across 21 separate posts — and Robin Friedrich, a NASA aerospace engineer, remembers using Python to build flight simulations for the Space Shuttle. (Friedrich says in the documentary he also attended Guido's first in-person U.S. workshop in 1994, and "I still have the t-shirt...")

Dropbox's CEO/founder Drew Houston describes what it was like being one of the first companies to use Python to build a company reaching millions of users. (Another success story was YouTube, which was built by a small team using Python before being acquired by Google). Anaconda co-founder Travis Oliphant remembers Python's popularity increasing even more thanks to the data science/macine learning community. But the documentary also includes the controversial move to Python 3 (which broke compatability with earlier versions). Though ironically, one of the people slogging through a massive code migration ended up being van Rossum himself at his new job at Dropbox. The documentary also includes van Rossum's resignation as "Benevolent Dictator for Life" after approving the walrus operator. (In van Rossum's words, he essentially "rage-quit over this issue.")

But the focus is on Python's community. At one point, various interviewees even take turns reciting passages from the "Zen of Python" — which to this day is still hidden in Python as an import-able library as a kind of Easter Egg.
"It was a massive undertaking", the documentary's director explains in a new interview, describing a full year of interviews. (The article features screenshots from the documentary — including a young Guido van Rossum and the original 1991 email that announced Python to the world.) [Director Bechtle] is part of a group that's filmed documentaries on everything from Kubernetes and Prometheus to Angular, Node.js, and Ruby on Rails... Originally part of the job platform Honeypot, the documentary-makers relaunched in April as Cult.Repo, promising they were "100% independent and more committed than ever to telling the human stories behind technology."
Honeypot's founder Emma Tracey bought back its 272,000-subscriber YouTube channel from Honeypot's new owners, New Work SE, and Cult.Repo now bills itself as "The home of Open Source documentaries."

Over in a thread at Python.org, language creator Guido van Rossum has identified the Python community members in the film's Monty Python-esque poster art. And core developer Hugo van Kemenade notes there's also a video from EuroPython with a 55-minute Q&A about the documentary.

An anonymous reader quotes a report from CBS News: They look, move and even smell like the kind of furry Everglades marsh rabbit a Burmese python would love to eat. But these bunnies are robots meant to lure the giant invasive snakes out of their hiding spots. It's the latest effort by the South Florida Water Management District to eliminate as many pythons as possible from the Everglades, where they are decimating native species with their voracious appetites. In Everglades National Park, officials say the snakes have eliminated 95% of small mammals as well as thousands of birds. "Removing them is fairly simple. It's detection. We're having a really hard time finding them," said Mike Kirkland, lead invasive animal biologist for the water district. "They're so well camouflaged in the field."

The water district and University of Florida researchers deployed 120 robot rabbits this summer as an experiment. Previously, there was an effort to use live rabbits as snake lures but that became too expensive and time-consuming, Kirkland said. The robots are simple toy rabbits, but retrofitted to emit heat, a smell and to make natural movements to appear like any other regular rabbit. "They look like a real rabbit," Kirkland said. They are solar powered and can be switched on and off remotely. They are placed in small pens monitored by a video camera that sends out a signal when a python is nearby. "Then I can deploy one of our many contractors to go out and remove the python," Kirkland said. The total cost per robot rabbit is about $4,000, financed by the water district, he added.

More than 30,000 Python developers from around the world answered questions for the Python Software Foundation's annual survey — and PSF Fellow Michael Kennedy tells the Python community what they've learned in a new blog post. Some highlights: Most still use older Python versions despite benefits of newer releases... Many of us (15%) are running on the very latest released version of Python, but more likely than not, we're using a version a year old or older (83%). [Although less than 1% are using "Python 3.5 or lower".] The survey also indicates that many of us are using Docker and containers to execute our code, which makes this 83% or higher number even more surprising... You simply choose a newer runtime, and your code runs faster. CPython has been extremely good at backward compatibility. There's rarely significant effort involved in upgrading... [He calculates some cloud users are paying up to $420,000 and $5.6M more in compute costs.] If your company realizes you are burning an extra $0.4M-$5M a year because you haven't gotten around to spending the day it takes to upgrade, that'll be a tough conversation...

Rust is how we speed up Python now... The Python Language Summit of 2025 revealed that "Somewhere between one-quarter and one-third of all native code being uploaded to PyPI for new projects uses Rust", indicating that "people are choosing to start new projects using Rust". Looking into the survey results, we see that Rust usage grew from 27% to 33% for binary extensions to Python packages... [The blog post later advises Python developers to learn to read basic Rust, "not to replace Python, but to complement it," since Rust "is becoming increasingly important in the most significant portions of the Python ecosystem."]

PostgreSQL is the king of Python databases, and only it's growing, going from 43% to 49%. That's +14% year over year, which is remarkable for a 28-year-old open-source project... [E]very single database in the top six grew in usage year over year. This is likely another indicator that web development itself is growing again, as discussed above...

[N]early half of the respondents (49%) plan to try AI coding agents in the coming year. Program managers at major tech companies have stated that they almost cannot hire developers who don't embrace agentic AI. The productive delta between those using it and those who avoid it is simply too great (estimated at about 30% greater productivity with AI).
It's their eighth annual survey (conducted in collaboration with JetBrains last October and November). But even though Python is 34 years old, it's still evolving. "In just the past few months, we have seen two new high-performance typing tools released," notes the blog post. (The ty and Pyrefly typecheckers — both written in Rust.) And Python 3.14 will be the first version of Python to completely support free-threaded Python... Just last week, the steering council and core developers officially accepted this as a permanent part of the language and runtime... Developers and data scientists will have to think more carefully about threaded code with locks, race conditions, and the performance benefits that come with it. Package maintainers, especially those with native code extensions, may have to rewrite some of their code to support free-threaded Python so they themselves do not enter race conditions and deadlocks.

There is a massive upside to this as well. I'm currently writing this on the cheapest Apple Mac Mini M4. This computer comes with 10 CPU cores. That means until this change manifests in Python, the maximum performance I can get out of a single Python process is 10% of what my machine is actually capable of. Once free-threaded Python is fully part of the ecosystem, I should get much closer to maximum capacity with a standard Python program using threading and the async and await keywords.
Some other notable findings from the survey:

• Data science is now over half of all Python. This year, 51% of all surveyed Python developers are involved in data exploration and processing, with pandas and NumPy being the tools most commonly used for this.

• Exactly 50% of respondents have less than two years of professional coding experience! And 39% have less than two years of experience with Python (even in hobbyist or educational settings)...

• "The survey tells us that one-third of devs contributed to open source. This manifests primarily as code and documentation/tutorial additions."

Last month, Python "reached the highest ranking a programming language ever had in the TIOBE index," according to TIOBE CEO Paul Jansen.

"We thought Python couldn't grow any further, but AI code assistants let Python take yet another step forward." According to recent studies of Stanford University (Yegor Denisov-Blanch), AI code assistants such as Microsoft Copilot, Cursor or Google Gemini Code Assist are 20% more effective if used for popular programming languages. The reason for this is obvious: there is more code for these languages available to train the underlying models. This trend is visible in the TIOBE index as well, where we see a consolidation of languages at the top. Why would you start to learn a new obscure language for which no AI assistance is available? This is the modern way of saying that you don't want to learn a new language that is hardly documented and/or has too few libraries that can help you.
TIOBE's "Programming Community Index" attempts to calculate the popularity of languages using the number of skilled engineers, courses, and third-party vendors. It nows gives Python a 26.14% rating, which TechRepublic notes "is well ahead of the next two programming languages on this month's leaderboard: C++ is at 9.18% and C is 9.03%." But the first top six languages haven't changed since last year...

1. Python
2. C++
3. C
4. Java
5. C#
6. JavaScript

Since August of 2024 SQL has dropped from its #7 rank down to #12 (meaning Visual Basic and Go each rise up one rank from their position a year ago, into the #7 and #8 positions).

In the last year Perl has risen from the #25 position to #9, beating out Delphi/Oracle Pascal at #10, and Fortran at #11 (last year's #10). TIOBE CEO Jansen "told TechRepublic in an email that many people were asking why Perl was becoming more popular, but he didn't have a definitive answer. He said he double-checked the underlying data and found the increase to be accurate, though the reason for the shift remains unclear."

Since 2023 the Python Software Foundation has had a Security Developer-in-Residence (sponsored by the Open Source Security Foundation's vulnerability-finding "Alpha-Omega" project). And he's just published a new 11-page white paper about open source's "phantom dependencies" problem — suggesting a way to solve it.

"Phantom" dependencies aren't tracked with packaging metadata, manifests, or lock files, which makes them "not discoverable" by tools like vulnerability scanners or compliance and policy tools. So Python security developer-in-residence Seth Larson authored a recently-accepted Python Enhancement Proposal offering an easy way for packages to provide metadata through Software Bill-of-Materials (SBOMs). From the whitepaper: Python Enhancement Proposal 770 is backwards compatible and can be enabled by default by tools, meaning most projects won't need to manually opt in to begin generating valid PEP 770 SBOM metadata. Python is not the only software package ecosystem affected by the "Phantom Dependency" problem. The approach using SBOMs for metadata can be remixed and adopted by other packaging ecosystems looking to record ecosystem-agnostic software metadata...

Within Endor Labs' [2023 dependencies] report, Python is named as one of the most affected packaging ecosystems by the "Phantom Dependency" problem. There are multiple reasons that Python is particularly affected:

- There are many methods for interfacing Python with non-Python software, such as through the C-API or FFI. Python can "wrap" and expose an easy-to-use Python API for software written in other languages like C, C++, Rust, Fortran, Web Assembly, and more.

- Python is the premier language for scientific computing and artificial intelligence, meaning many high-performance libraries written in system languages need to be accessed from Python code.

- Finally, Python packages have a distribution type called a "wheel", which is essentially a zip file that is "installed" by being unzipped into a directory, meaning there is no compilation step allowed during installation. This is great for being able to inspect a package before installation, but it means that all compiled languages need to be pre-compiled into binaries before installation...


When designing a new package metadata standard, one of the top concerns is reducing the amount of effort required from the mostly volunteer maintainers of packaging tools and the thousands of projects being published to the Python Package Index... By defining PEP 770 SBOM metadata as using a directory of files, rather than a new metadata field, we were able to side-step all the implementation pain...

We'll be working to submit issues on popular open source SBOM and vulnerability scanning tools, and gradually, Phantom Dependencies will become less of an issue for the Python package ecosystem.
The white paper "details the approach, challenges, and insights into the creation and acceptance of PEP 770 and adopting Software Bill-of-Materials (SBOMs) to improve the measurability of Python packages," explains an announcement from the Python Software Foundation. And the white paper ends with a helpful note.

"Having spoken to other open source packaging ecosystem maintainers, we have come to learn that other ecosystems have similar issues with Phantom Dependencies. We welcome other packaging ecosystems to adopt Python's approach with PEP 770 and are willing to provide guidance on the implementation."

This week Google's Open Source Security Team announced "a new project to strengthen trust in open source package ecosystems" — by reproducing upstream artifacts.

It includes automation to derive declarative build definitions, new "build observability and verification tools" for security teams, and even "infrastructure definitions" to help organizations rebuild, sign, and distribute provenance by running their own OSS Rebuild instances. (And as part of the initiative, the team also published SLSA Provenance attestations "for thousands of packages across our supported ecosystems.") Our aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by making package consumption as transparent as using a source repository. Our rebuild platform unlocks this transparency by utilizing a declarative build process, build instrumentation, and network monitoring capabilities which, within the SLSA Build framework, produces fine-grained, durable, trustworthy security metadata. Building on the hosted infrastructure model that we pioneered with OSS Fuzz for memory issue detection, OSS Rebuild similarly seeks to use hosted resources to address security challenges in open source, this time aimed at securing the software supply chain... We are committed to bringing supply chain transparency and security to all open source software development. Our initial support for the PyPI (Python), npm (JS/TS), and Crates.io (Rust) package registries — providing rebuild provenance for many of their most popular packages — is just the beginning of our journey...

OSS Rebuild helps detect several classes of supply chain compromise:

- Unsubmitted Source Code: When published packages contain code not present in the public source repository, OSS Rebuild will not attest to the artifact.

- Build Environment Compromise: By creating standardized, minimal build environments with comprehensive monitoring, OSS Rebuild can detect suspicious build activity or avoid exposure to compromised components altogether.

- Stealthy Backdoors: Even sophisticated backdoors like xz often exhibit anomalous behavioral patterns during builds. OSS Rebuild's dynamic analysis capabilities can detect unusual execution paths or suspicious operations that are otherwise impractical to identify through manual review.


For enterprises and security professionals, OSS Rebuild can...

— Enhance metadata without changing registries by enriching data for upstream packages. No need to maintain custom registries or migrate to a new package ecosystem.

— Augment SBOMs by adding detailed build observability information to existing Software Bills of Materials, creating a more complete security picture...

- Accelerate vulnerability response by providing a path to vendor, patch, and re-host upstream packages using our verifiable build definitions...


The easiest (but not only!) way to access OSS Rebuild attestations is to use the provided Go-based command-line interface.
"With OSS Rebuild's existing automation for PyPI, npm, and Crates.io, most packages obtain protection effortlessly without user or maintainer intervention."

Google has announced OSS Rebuild, a new project designed to detect supply chain attacks in open source software by independently reproducing and verifying package builds across major repositories. The initiative, unveiled by the company's Open Source Security Team, targets PyPI (Python), npm (JavaScript/TypeScript), and Crates.io (Rust) packages.

The system, the company said, automatically creates standardized build environments to rebuild packages and compare them against published versions. OSS Rebuild generates SLSA Provenance attestations for thousands of packages, meeting SLSA Build Level 3 requirements without requiring publisher intervention. The project can identify three classes of compromise: unsubmitted source code not present in public repositories, build environment tampering, and sophisticated backdoors that exhibit unusual execution patterns during builds.

Google cited recent real-world attacks including solana/webjs (2024), tj-actions/changed-files (2025), and xz-utils (2024) as examples of threats the system addresses. Open source components now account for 77% of modern applications with an estimated value exceeding $12 trillion. The project builds on Google's hosted infrastructure model previously used for OSS Fuzz memory issue detection.

An anonymous reader shared this report from InfoWorld: Tiobe CEO Paul Jansen says Ada, a system programming language whose initial development dates back to the late 1970s, could outlast similarly aged languages like Visual Basic, Perl, and Fortran in the language popularity race.

In comments on this month's Tiobe language popularity index, posted July 9, Jansen said the index has not seen much change among leading languages such as Python, C#, and Java over the past two years. But there is more movement among older languages such as Visual Basic, SQL, Fortran, Ada, Perl, and Delphi, said Jansen. Every time one of these languages is expected to stay in the top 10, it is replaced by another language, he said. Even more remarkably, newer languages have yet to rise above them. "Where are Rust, Kotlin, Dart, and Julia? Apparently, established languages are hot."
"Which one will win? Honestly, this is very hard to tell," Jansen writes, "but I would put my bets on Ada. With the ever-stronger demands on security, Ada is, as a system programming language in the safety-critical domain, likely the best survivor."

Perhaps proving his point, one year ago, Ada was ranked #24 — but on this month's index it ranks #9. (Whereas the eight languages above it all remain in the exact same positions they held a year ago...)

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