Python dethrones JavaScript as the most-used language on GitHub There's been an upset in the Octoverse, as Python has unseated JavaScript as the most-used programming language on GitHub. Python's ascendancy from the number-two slot, which it's held since knocking Java from the position in 2019, is largely down to an explosion of generative AI activity on GitHub, the Microsoft-owned coding …
All the fuss about Rust := fust. :)
Sorry, couldn't resist the joke. But seriously, what makes Rust good is what makes it hard. and this will always limit its growth on popularity surveys. The corollary is Rust developers as a rule are pretty sharp. Not a fan of the language though. (a) I'm no longer sharp enough to put in the effort. (b) Anyway the problems Rust solves are not my problems.
“open source maintainers adopting GitHub Copilot as part of our complimentary access program,"
And the evidence for this???
"This suggests AI isn't just helping more people learn to write code or build software faster - it's also attracting and helping more people become developers.”
“AI” is doing no such thing. Even if it were any good (and it isn’t even out of the swamp) how does “Hey AI, write me some code to do this because I’m not educated enough or too lazy to do it myself and I don’t care if it’s actually any good or not” make anyone a software developer?
I’m so tired of reading this tripe
Hey AI
Write me the boring boilerplate stuff I need for an e-commerce site. Create me a data entity model for a basic online shop. Define an interface for searching for products.
This kind of stuff actually works today if you cared to try it. No, it's not perfect. No it won't run straight out the generator. No, the cleaner isn't going to replace the developer who knows what to ask for and how to spot the flaws and fix the 5% of code that doesn't work.
But it will make a team using generative code tools 30% more efficient (that is with today's iterations based on our testing) than a team crafting every line by hand. So teams using such tools will make developers obsolete - those old, lazy ones that can't be bothered to learn new skills and spend their days commenting on Reg articles instead.
A jazzed up search engine that spits out boilerplate? Fine, it's a time saving tool for certain things. I'll take that.
Old, lazy developers? They've seen hype bandwagon-pumped alleged new dawns of humanity four or five times overt their careers probably, so are healthily cynical.
Be careful underestimating AI's ability to code or to get people into coding. As a marketer, turned businesses analyst, turned systems analyst, I managed to come 3rd in a company hackathon with ai assisted coding back in gpt 3.5 days. I've since automated a ton of my day to day tasks using ai code and recently created a fully functional music streaming platform using ai with tens of thousands of lines of code and beautiful architecture. I've had senior architects at my company in awe of what I was able to achieve with very little coding knowledge and ai. I even changed our CTO's stance on ai as an existential threat to traditional developers, who is now encouraging developers to start taking these tools more seriously and learning to use them, lest they become redundant (not sure if I'd go that far yet, personally).
I read on the ai subreddits every day about non-developers creating phenomenal software solutions using ai. I'm not trying to scare you. A developer properly using ai assisted coding could out perform me by far, but if you don't open your mind to the possibility that ai has a significant role in the future of coding, you will be left behind.
This is an interesting observation as it shows the possibility of end users creating good quality software products that meet their exact needs themselves rather than buying/licensing an existing product that may fit most of them.
This should not only worry Devs, but also software houses as only maintenance contracts would make their products desirable.
@tomthebomb perhaps you should write (and sell) a primer book describing how you got AI to make these high quality tools.
Which is one reason I don't believe it. If that happened, I'd be quite happy. I don't like writing that kind of stuff and everyone needs it. People who have made their living on writing that kind of stuff rather than my approach of running as far away as I could (not very far) may be less pleased if that comes to pass. However, I don't think the AI is going to successfully solve the most difficult parts of the process, such as actually understanding what the program needs to do, where the data is and exactly what form it takes, and where the final software is going to run. A lot of software like this is relatively simple to make, but companies end up buying third-party software instead because they aren't good at the maintenance it takes to keep a self-built version correct and operational. At best, AI (a fictional AI that actually works reliably) might make the process of writing the software faster, but it's not going to take vague requirements and make correct technical requirements out of them, process jumbled data into something that fits the selected format, or keep the systems running. You will need at least four different AIs for these tasks, and the LLM approach won't work for any.
>recently created a fully functional music streaming platform using ai with tens of thousands of lines of code and beautiful architecture<
Can you upload that to a public repository so cynic people like me can be convinced this project actually exists?
Sorry, but to me your post looks much more like AI marketing than a description of real AI supported development projects.
The same way "Hey compiler, write me some machine code because I'm not educated enough or too lazy to do it myself." does. How many remember the days of compiler bugs?
'Hey garbage collector, handle my memory management for me because I'm not educated enough or too lazy to do it myself"
Snobs sneering at interpreted languages as not "real" or "toy" languages?
It's turtles all the way down. AI is just another turtle, which has admittedly a long way to go before we trust it the way we trust a compiler. As for actually checking the output - that's literally part of our job. No less than checking what we ourselves wrote.
We are getting paid to solve problems, not show everyone how clever we are.
If compilers changed from run to run between the options of "gets the answer mostly correct, but there is a bug you will find two months later" and "segfaults immediately", then someone would be justified in disliking compilers until that changed. Actual compilers were both deterministic and auditable, meaning that although they had and still have bugs, those bugs can be specifically identified, fixed, proven fixed, and tracked. If those compilers changed what they produced on things that weren't supposed to be syntactically significant, like comments, then that would also be a bug.
There is a difference between a tool which works the same way and can be improved and a tool that is intentionally random. At some point, we will have tools that automate even more of the process of writing software, but categorizing LLMs in the same category as compilers is too broad. Maybe we will eventually have a piece of software which works similarly to an LLM, where you can provide a natural language summary and a program pops out, and if it's wrong you describe how and a new program with the bug fixed pops out. LLMs as we have them don't and won't do that.
Actually, the "batteries included" mantra of Python means that you can do an awful lot without frameworks. And where frameworks are used, these are commonly written in a high-performance language such as C++, Fortran, or nowadays Rust. And this is what has always made Python popular: non-computer science graduates can write usable maintainable code on their own for their job.
I'm not denying that Python has its advantages, I'm currently writing some tools for work with it. But let's be honest, the reason it's popular is primarily because it's easy to learn to an "okay" standard, which appeals to the masses (which isn't the aim of many other languages). Hence why so much of Github consists of it.
But personally, I think there's a lot of questionable syntax/design decisions in Python, it's comparatively slow (hence why they've tried to address that somewhat in recent versions over the years), and hence it needs to rely on a lot of functions/libraries/frameworks written in a higher-level language like C to perform many tasks efficiently, then you can't directly credit the Python language for this aspect.
I'm sure there's some very good frameworks out there, but there's a lot of bloat, especially with web frameworks (seriously, what sane individual would use Django for proper development? People that are desperate to use Python for everything.)
seriously, what sane individual would use Django for proper development?
How about the people behind Instagram, Spotify, Disqus, YouTube, Dropbox or Pinterest?
I think it's more concerning that people are still using React, even when they don't have to support IE11.
But let's be honest, the reason it's popular is primarily because it's easy to learn to an "okay" standard, which appeals to the masses
Not necessarily the masses, but for a language for non-programmers was a design goal and places the language in an illustrious tradition.
I think there's a lot of questionable syntax/design decisions in Python
Ah, yes: you hate significant whitespace and consider it eblematic of "poor design decisions". Significant whitespace seems to be a marmite issue: you either love it or hate it. Personally, I think it visually helps reinforce the structure. But, if you don't like it, you're not going to like Python. I think the same divide probably applies to other "typical" aspects which favour clarity and expression and the fact that "everything is an object". No one will criticise Python code for using an additional line of code to make something clearer.
it's comparatively slow (hence why they've tried to address that somewhat in recent versions over the years)
It's more of a tick-tock approach: new features are implemented in Python and optimised later. I seem to remember Python 2.5 was an optimisation release and we had another one after Python 3 became stable. As for "inherently slow", it depends very much what you're doing and what you're comparing it with. Memory allocation for new objects is noticeably slower than compiled languages and loops are known to be slower. For the vast majority of code it is totally unimportant and the benefits of code that it is easier, to read, test and maintain far outweigh the benefits. In addition, PyPy has shown just how fast things can get if you use a JIT and is, in my view, a reason why there is little or no need to encourage static typing.
hence it needs to rely on a lot of functions/libraries/frameworks written in a higher-level language like C to perform many tasks efficiently, then you can't directly credit the Python language for this aspect.
You say that like it's a bad thing! It was a conscious decision to be so pragmatic that has proved both popular and successful to allow libraries written in other languages to be easily embedded in the language. But it actually serves to mitigate another criticism, the "not invented here" syndrome (NIH), that affects many languages. Contrary to the opinion held by many, for example, most mathematicians are not trained programmers and very happy to be able to use Numpy. They could, of course, use Fortran directly in many situations, but there a good reasons why they don't.
As for Django, I've never really liked it, but it has the same advantage as something like WordPress, in that it automates a lot of common tasks, particularly CRUD, albeit at the price of a dreadfully inefficient ORM (a bad idea in itself). But, while it remains popular, it would be a mistake to consider it the only option: more and more work is being done using headless frameworks like FastAPI which work well with frontend frameworks and allow for a different and more flexible approach to the automated creation of GUI controls.
Python is far from perfect, and some of the recent changes including the faster release and shorter support cycles are not welcome. And, of course, Python processes do not scale multiple CPUs as well as other languages, though again, this not really a problem that people encounter everyday. But, before the GIL is dropped entirely, I think more work needs to be done to make the development of asynchronous and synchronous code within the same codebase. This has been brewing since the introduction of generators (actually a major shift) and is still working its way through. I hope, that in a couple of years, people won't really have to care any more but, at the moment, there's no denying it's a considerable overhead.
Different languages for different targets. The python language has a lot of shortcomings, but the scientific/numeric/math/cuda libraries are very high quality. For example, "mathsage" (overlaps with Mathematica, Macsyma, Maple, etc) exists as a library in python. So you can code your math! (Need >3GB though). Yet python is only now trying to get rid of the Global Interpreter Lock (GIL), and it's going to be hard. Talk about baggage.
The language JS is also complete hack, but it's very useful web pages and web serving because it can coordinate a huge number of tiny asynchronous tasks (waiting for HTTPS responses, io, or even other programs on the same computer) all from a single coordinating thread. Meanwhile the garbage collector is multi threading for efficiency. It's not good for cases where all threads should be at 100% CPU usage on a single computer - that should be traditional IPC multithreading which JS is not. Personally I find JS happens to be pretty useful for shell scripts of a size that bash etc. become spaghetti, because JS is a real language with exception handling etc.
You can code your math? With Yet another math library?
I have never understood this and similar sentiments, as opposed to what? Matlab? Because coding anything, including math, in Matlab is a pita.
You can code your math in most languages. Needing three gigabytes seems like a downside though.
I'll admit that there are legit usecases aswell, but that's not really what you said.. "you can code your math and it'll run on your GPU" on the other hand
Symbolic math, which is why Matlab was not included. There have been numeric libs available since Fortan, at least, as you say. 3Gb is a lot, but it's to nice to have that (Symbolic math) power offline and without a subscription. Hope this clears up the misunderstanding caused by my not giving sufficient details.
You can code your math? With Yet another math library?
I have never understood this and similar sentiments, as opposed to what? Matlab? Because coding anything, including math, in Matlab is a pita.
You can code your math in most languages. Needing three gigabytes seems like a downside though.
I'll admit that there are legit usecases aswell, but that's not really what you said.. "you can code your math and it'll run on your GPU" on the other hand..
That's why Python has managed to be popular with a GIL for decades. Quite often, the presence of a GIL isn't too bad and computers are fast enough that you can survive the performance hit. However, the reason for wanting to dispense with it is when you want to do a lot of stuff and you'd like to use all the hardware you have to do so, and most languages would let you do it. I've frequently sped up software merely by having multiple cores working on something. If you don't have programs that run for a long time, or if they run for that time but aren't using all the CPU they have access to, then that might not be something you need. If you frequently write or run programs that are using 100% of one core, then you might want to see how much faster they can go if they can use all the cores.
TypeScript is JavaScript with syntax for types. It's a superset of JavaScript. So yeah, you count JS and TS separately, as you do with C and C++, but in the end, you shouldn't. It's C/C++ and JS/TS. And, even if I can see no numbers, only a ranking, I'm pretty sure that JavaScript + TypeScript > Python.
And they don't count the line numbers, but the distinct users.
I agree that Typescript and Javascript shouldn't be counted separately and, indeed, it looks like Typescript is due to replace Javascript in popularity, but I don't think the comparison with C and C++ makes sense.
I've not done much in Javascript, but having seen it displace Python in some web stuff because of its use in the front end and ease of use in asynchronous, I'm now seeing it being displaced again as the controller stuff becomes increasingly declarative and the complexity of node based stuff becomes unmanagable.
Upset? But this is good news. And no, I don't mean because of the boom in AI projects, I frankly don't care about that aspect.
Regardless of what spurred its increased usage, Python in itself deserves to be the most-used, given how versatile and articulate the language is.
One versatile aspect of Python worth mentioning is the ability to overload this indexing operator [] and all the different flavors of index notation which allow for numpy and pytorch tensor operations.enourmouly powerful.
It deserves to be used where it is suitable, (but not where it's not).
You should provide examples of why you think it's articulate.
- Personally I think the use of tabs/spaces to structure programs was always a bad idea.
- Comprehensions are often abused and turn into an unreadable mess to anyone else.
- The removal of brackets for conditions achieves nothing apart from tripping up programmers that constantly have to move between using half a dozen different languages
I could go on for a long time. I think most of it comes under personal taste, but I really wouldn't class it as articulate.
I kind of feel that this metric of kinda meaningless especially I'm the context of AI you projects. It's like this decades equivalent to a fart app on the iPhone 15 years ago.
Everyone uses the same templates and goes through a few steps. But do they actually understand what they're doing or making anything different and productive?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
