News: 0178852942

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Survey Finds More Python Developers Like PostgreSQL, AI Coding Agents - and Rust for Packages (jetbrains.com)

(Monday August 25, 2025 @03:44AM (EditorDavid) from the survey-says dept.)


More than 30,000 Python developers from around the world answered questions for the Python Software Foundation's [1]annual survey — and PSF Fellow Michael Kennedy [2]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 [3]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."



[1] https://lp.jetbrains.com/python-developers-survey-2024/

[2] https://blog.jetbrains.com/pycharm/2025/08/the-state-of-python-2025/

[3] https://pyfound.blogspot.com/2025/06/python-language-summit-2025-what-do-core-developers-want-from-rust.html



Python is scripting, not a programming language (Score:2)

by nextTimeIsTheLast ( 6188328 )

As I always thought, Python is a scripting language that is used to stitch together programs written in 'real' languages - 'rust is how we speed up Python now.

Re: (Score:3)

by PDXNerd ( 654900 )

This is not flamebait, I'm genuinely curious - what do you consider to be the difference between a real language and a scripting language? Compilation support? Typing? I always considered bash a 'scripting language' and not a 'real' language, whereas things like perl/ruby/python fall someplace in the middle, useful for both systems scripting (compilation of other lower level languages) and also useful for real world applications.

When you say 'rust is how we speed up python now' who is we, and why are they

Re: (Score:2)

by h33t l4x0r ( 4107715 )

OP is just a cranky a C coder who needs to feel superior to entire swaths of colleagues. Which is ridiculous because we Assembly coders know that C isn't even a real programming language.

Re: (Score:2)

by nextTimeIsTheLast ( 6188328 )

Afraid not, I am a cranky old BASIC, Assembler, Pascal, C, BLISS( Work that one out!), Cobol, PL/1, Java, Oracle SP, Bash, Ruby, Python, Swift, Dart, Rust programmer (in time sequence order) thank you very much. You are clearly a chip-on-the shoulder python dev pretending to be an Assembler coder in an attempt at faux credibility.

Re: (Score:2)

by PDXNerd ( 654900 )

Hah, was waiting for the cranky assembly programmer to show up and bash on C ;) degree of difficulty seems to be most people's definitions of 'scripting' vs 'real' programming language, but that degree of difficulty is relative to programmer and experience.

Re: (Score:2)

by bjoast ( 1310293 )

Considering how modern CPUs work, assembly should be considered a high level language.

Re: (Score:1)

by Alien among you ( 4022205 )

Great to see you still active! I do think modern processors are too specialized to write assembly code.

However that is why Flight Simulator needs 16GB ram. And simple web pages occupy 15 MB.

ASM to speed up crucial parts of C

C to speed up crucial parts of python

python to speed up development

rust to speed up... python?

So where do object-oriented design, pair programming and the other buzzwords fit in?

Re: (Score:2)

by arcade ( 16638 )

I'm not OP, but I can give you my answer to what you're asking:

A script mainly executes *external commands*.

Most languages can be used to write scripts. They can also be used as a "real" language. Some with more difficulty than others. Bash being an extreme example. You can do a heck of a lot in "pure bash" w/o relying on unix commands. Most people don't bother though. Thus, they write scripts.

When I started using perl some ~27 years ago, a lot of my initial stuff was scripts. I used backticks throug

Re: (Score:2)

by PDXNerd ( 654900 )

That has been my way of defining the two as well - you can turn a C program into a program that just executes other programs as well, and I have unfortunately seen a few of these over the years.... :(

Re: (Score:2)

by nextTimeIsTheLast ( 6188328 )

'rust os how we speed up Python' is a quote from the article.

A 'real' language (quotes were deliberate), is one that realistically supports large scale general purpose development. I would be surprised if anyone would decide to develop, for example, a core banking system in Python.

Things I would pinpoint that exclude Python are:

General culture of hacking rather than planned development (encouraged by no types, whitespace significance, interpreted) which encourages sloppiness

Whitespace significance - intro

Re: (Score:2)

by fluffernutter ( 1411889 )

You have probably used applications done with Python/qt/qml without even knowing it.

Re: (Score:2)

by Entrope ( 68843 )

When your entire argument is "you probably ___", you should just keep it to yourself. Posting it only makes you sound retarded, especially when most of the stack you cite is made up of heavy lifting code written in C++ (two-thirds by name and much more by functionality, but probably much less by execution time thanks to Python's poor efficiency).

Re: (Score:2)

by fluffernutter ( 1411889 )

Well I have to say probably because I don't know. Also I don't see why it matters that the heavy lifting is done in c++. The point is that python is still useful for the logic.

Re: (Score:2)

by Entrope ( 68843 )

Yes, exactly: You don't know, and you don't have any good evidence to back up an argument. You only have your guess, and that's why you should have kept it to yourself.

All scripting languages are useful because they let you express some kind of high-level logic (that relies on code written in other languages to actually execute). That doesn't change what they are.

Re: (Score:2)

by fluffernutter ( 1411889 )

Except that doesn't really fit with Python either because there are no native tokens that allows you to run external commands in Python like in perl. So by that definition Python isn't a scripting language.

Re: (Score:2)

by pjt33 ( 739471 )

Python has duck typing inherently, which makes it better than most "real" languages for some purposes. It's become my language of choice for most Project Euler problems because I can have a library of e.g. matrix operations without caring explicitly about the type of the elements in the matrix. The only statically typed languages which I know of that can do the same thing flexibly are Haskell and its imitators. In addition, Python does support type annotations which can be statically checked. They're a bit

Re: (Score:2)

by registrations_suck ( 1075251 )

Oh, look! One of those......

Survey Finds most surveys are just flamebate (Score:1)

by Anonymous Coward

Designed to annoy and antagonise the groups that don't agree that what ever the Survey finds. A staple of click bate sites like /.

The rising popularity of Rust (not just inside Pyt (Score:2)

by Viol8 ( 599362 )

... is due to C++ jumping the shark. The latter is so complex now that no one who has other things to do in life can spend enough time to learn the language & library functionality and the increasingly esoteric syntax to a point that you can approach most modern C++ code without going WT actual F? I've been doing C++ for 25 years and it's how I earn my living (along with some Python and straight C) , but if I was starting out today I wouldn't go within a mile of itm I'd probably head towards Rust too af

Re: (Score:2)

by MilliMicro ( 6251190 )

I'm a hobby programmer who has never gotten on with C/++. I dipped my toes into Rust recently and oh my god the tooling is so much better. The fact that Cmake (not just a build tool, a META build tool) was necessary enough that someone made it is a bit mad, but the syntax of it is horrendous. Compiler errors in Rust are so much more concise and helpful too. I know there are criticisms of Cargo etc., but it feels much easier to focus on the code and not the tooling with Rust. As a newbie, hell yeah it feels

Performance (Score:2)

by phantomfive ( 622387 )

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

The author might be surprised how short a time your 10 core machine can actually run at full performance without overheating.

Re: (Score:2)

by Entrope ( 68843 )

The rest of us are surprised how dumb your argument is. I haven't seen numbers for Apple silicon, but for x86 desktops, often only one core at a time can boost to the maximum clock speed. However, that's usually less than 20% faster than the all-core boost speed, and less than 50% faster than what can be sustained for all cores. Having just two cores running code more than makes up for those clock-speed differences. So Python's painful multiprocessing support leaves a huge amount of performance on the t

Rust has broken pythons platform independence (Score:2)

by fluffernutter ( 1411889 )

The problem with using rust in Python is that while python is platform independent, rust is not. I recently had to rewrite an entire script for a platform using an entirely different technology because the original technology needed rust way down in the dependencies which I couldn't get to work without a commercial compiler. I wish people could at least wait until rust was universally available everywhere.

"Most still use older Python versions " (Score:2)

by drolli ( 522659 )

That is a sign of the sucess of the language. It means that there are a lot of envitonments in which it runs productively with a well defined scope, very often embedded into an bigger system or package.

Military intelligence is a contradiction in terms.
-- Groucho Marx