In our goal of trying to estimate a programming language’s popularity, we realized that no one can look over the shoulder of every person writing code, whether that be a child writing a Java script for a personal Minecraft server, a mobile app developer hoping to hit it big, or an aerospace engineer writing mission-critical code for a voyage to Mars. Our Top Programming Languages interactive tries to tackle the problem of estimating a language’s popularity by looking for proxy signals.

We do this by constructing measures of popularity from a variety of data sources that we believe are good proxies for active interest for each programming language. In total, we identify 63 programming languages. We then weight each data source to create an overall index of popularity, excluding some of the lowest scorers. Below, we describe the sources of data we use to get the measures, and the weighting scheme we use to produce the overall indices.

By popularity, we mean we are trying to rank languages that are in active use. We look at three different aspects of popularity: languages in active use among typical IEEE members and working software engineers (the “Spectrum” ranking), languages that are in demand by employers (the “Jobs” ranking), and languages that are in the zeitgeist (the “Trending” ranking).

We gauged the popularity of languages using the following sources for a total of eight metrics (see below). We gathered the information for all metrics in July—August 2024. The data were gathered manually to avoid results being biased due to API changes or terminations and because many of the programming language’s names (C++, Scheme) collided with common terms found in research papers and job ads or were difficult for a search engine to parse. When a large number of search results made it impractical to resolve ambiguities by examining all of the results individually, we used a sample of each data source, and determined the relevant sample size based on estimating the true mean with 95 percent confidence. Not all data sources contain information for each programming language and we interpret this information as the programming language having “no hits” (that is, not being popular).

The results from each metric are normalized to produce a relative popularity score between 0 and 1. Then the individual metrics are multiplied by a weight factor, combined, and the result renormalized to produce an aggregate popularity score.

In aggregating metrics, we hope to compensate for statistical quirks that might distort a language’s popularity score in any particular source of data. Varying the weight factors allows us to create the different results for the Spectrum, Jobs, and Trending rankings. We fully acknowledge that, while these weights are subjective, they are based on our understanding of the sources and our prior coverage of software topics. Varying the weight factors allows us to emphasize different types of popularity and produce the different rankings. We then combined each weighted data source for each program and then renormalized the resulting frequency to produce an aggregate popularity score.

The Top Programming Languages was originally created by data journalist Nick Diakopoulos. Our statistical methodology advisor is Hilary Wething. Research assistance was provided by Elizabeth Wood. Rankings are computed using R.

Google

Google is the leading search engine in the world, making it an ideal fit for estimating language popularity. We measured the number of hits for each language by searching on the template, “X programming language” (with quotation marks) and manually recorded the number of results that were returned by the search. We took the measurement in July 2024. We like this measure because it indicates the volume of online information resources about each programming language.

Stack Overflow

Stack Overflow is a popular site where programmers can ask questions about coding. We recorded the number of questions tagged to each program within the last week prior to our search (August 2024). For the Mathematica/Wolfram language, we relied on the sister “Stack” for the Mathematica platform and tallied the number of programming-related questions asked in the past week. These data were gathered manually. This measure indicates what programming languages are currently trending.

IEEE Xplore Digital Library

IEEE maintains a digital library with millions of conference and journal articles covering a wide array of scientific and engineering disciplines. We searched for articles that mention each of the languages in the template “X programming” for the years 2023 and 2024, because this is the smallest timeframe for which we could access articles. For search results that returned thousands of articles, we identified the correct sample size for a 95 percent confidence interval (usually a little over 300) and pulled that number of articles. For each language we sampled, we identified the share of articles that utilize the programming language and then multiplied the total number of articles by this share to tally the likely total number of articles that reference a given programming language. We conducted this search in July 2024. This metric captures the prevalence of the different programming languages as used and referenced in engineering scholarship.

IEEE Job Site

We measured the demand for different programming languages in job postings on the IEEE Job Site. For search results that returned thousands of listings, we identified the correct sample size for a 95 percent confidence interval (usually around 300 results) and pulled that number of job listings to manually examine. For each language we sampled, we identified the share of listings that utilize the programming language and then multiplied the total number of job listings by this share to tally the likely total number of job listings that reference a given programming language. Additionally, because some of the languages we track could be ambiguous in plain text—such as lD, Go, J, Ada, and R—we searched for job postings with those words in the job description and then manually examined the results, again sampling entries if the number of results was large. The search was conducted in July 2024. We like the IEEE Job Site for its large number of non-U.S. listings, making it an ideal to measure global popularity.

CareerBuilder

We measured the demand for different programming languages on the CareerBuilder job site. We searched for “Developer” jobs offered within the United States, as this is the most popular job title for programmers. We sampled 400 job ads and manually examined them to identify which languages employers mentioned in the postings. The search was conducted in July 2024. We like the career builder site to identify the popularity of programmer jobs in the United States.

GitHub

GitHub is a public repository for many volunteer-driven open-source software projects. We used data gathered by GitHut 2.0, which measures the top 50 languages used by the number of repositories tagged with that language and draws from GitHub’s public API. We use two metrics from GitHub: repositories that have been “starred” by users to reflect long-term interests, and the number of pull requests to indicate current activity. The data cover the second quarter of 2024. These measures indicate what languages coders choose to work in when they have a personal choice.

Trinity College Dublin Library

The library of Trinity College Dublin is one of six legal deposit libraries in Ireland and the United Kingdom. A copy must be deposited with the library of any book published or distributed in Ireland, and on request any U.K. publisher or distributor must also deposit a book. We searched for all books published in the year to date that had their subject matter categorized as computer programming and totaled the number of returns. The search was conducted in June 2024. We like this library collection because it represents a large and categorized sample of works, primarily in the English language.

Discord

Discord is popular chat-room platform where many programmers exchange information. We counted the number of tags that correspond to each language. In the case of languages that could also be names of nonprogramming topics, (many nonprogramming-related topics also have dedicated Discord servers; for example, “Julia” could refer to the programming language or the Sesame Street puppet), results were manually examined. Disboard was searched in August 2024. Disboard lists many public discord servers and many young coders use the site, contributing a different demographic of coders.

Welcome to IEEE Spectrum’s 11th annual rankings of the most popular programming languages. As always, we combine multiple metrics from different sources to create three meta rankings. The “Spectrum” ranking is weighted towards the profile of the typical IEEE member, the “Trending” ranking seeks to spot languages that are in the zeitgeist, and the “Jobs” ranking measures what employers are looking for.

You can find a full breakdown of our methodology here, but let’s jump into our results. At the top, Python continues to cement its overall dominance, buoyed by things like popular libraries for hot fields such as AI as well as its pedagogical prominence. (For most students today, if they learn one programming language in school, it’s Python.) Python’s pretty popular with employers too, although there its lead over other general purpose languages is not as large and, like last year, it plays second fiddle to the database query language SQL, which employers like to see paired with another language. SQL popularity with employers is a natural extension of today’s emphasis on networked and cloud-based system architectures, where databases become the natural repository for all the bytes a program’s logic is chewing on.

Top Programming Languages 2024 is brought to you by the IEEE Computer Society. Get connected with the world’s largest community empowering computer science and engineering professionals.

Stalwarts like Java, Javascript, and C++ also retain high rankings, but it’s what’s going on a little further down that’s particularly interesting. Typescript—a superset of Javascript—moves up several places on all the rankings, especially for Jobs, where it climbs to fourth place, versus 11th last year. Typescript’s primary differentiator over Javascript is that it enforces static typing of variables, where the type of a variable—integer, floating point, text, and so forth—must be declared before it can be used. This allows for more error checking when Typescript programs are compiled to Javascript, and the increase in reliability has proven appealing.

Another climber is Rust, a language aimed at creating system software, like C or C++. But unlike those two languages, Rust is “memory safe”, meaning it uses a variety of techniques to ensure programs can’t write to locations in memory that they are not supposed to. Such errors are a major source of security vulnerabilities. Rust’s profile has been rising sharply, boosted by things like a February cybersecurity report from the White House calling for memory safe languages to replace C and and C++. Indeed, C’s popularity appears to be on the wane, falling from fourth to ninth place on the Spectrum ranking and from 7th to 13th on the Jobs ranking.

Two languages have entered the rankings for the first time: Apex and Solidity. Apex is designed for building business applications that use a Salesforce server as a back end, and Solidity is designed for creating smart contracts on the Ethereum blockchain.

This year also saw several languages drop out of the rankings. This doesn’t mean a language is completely dead, it just means that these languages’ signal is too weak to allow them to be meaningfully ranked. Languages that dropped out included Forth, a personal favorite of mine that’s still popular with folks building 8-bit retro systems because of its tiny footprint. A weak signal is also why we haven’t included some buzzy languages such as Zig, although those proficient in it can apparently command some high salaries.

As these other languages come and go from the rankings, I have to give the shout out to the immortals, Fortran and Cobol. Although they are around 65 years old, you can still find employers looking for programmers in both. For Fortran, this tends to be for a select group of people who are also comfortable with high-energy physics, especially the kind of high-energy physics that goes boom (and with the security clearances to match). Cobol is more broadly in demand, as many government and financial systems still rely on decades-old infrastructure—and the recent paralyzing impact of the Cloudstrike/Microsoft Windows outage incident probably hasn’t done much to encourage their replacement!

You have a closed box. There may be a live cat inside, but you won’t know until you open the box. For most people, this situation is a theoretical conundrum that probes the foundations of quantum mechanics. For me, however, it’s a pressing practical problem, not least because physics completely skates over the vital issue of how annoyed the cat will be when the box is opened. But fortunately, engineering comes to the rescue, in the form of a new US $50 maker-friendly pulsed coherent radar sensor from SparkFun.

Perhaps I should back up a little bit. Working from home during the pandemic, my wife and I discovered a colony of feral cats living in the backyards of our block in New York City. We reversed the colony’s growth by doing trap-neuter-return (TNR) on as many of its members as we could, and we purchased three Feralvilla outdoor shelters to see our furry neighbors through the harsh New York winters. These roughly cube-shaped insulated shelters allow the cats to enter via an opening in a raised floor. A removable lid on top allows us to replace straw bedding every few months. It’s impossible to see inside the shelter without removing the lid, meaning you run the risk of surprising a clawed predator that, just moments before, had been enjoying a quiet snooze.

The enclosure for the radar [left column] is made of basswood (adding cat ears on top is optional). A microcontroller [top row, middle column] processes the results from the radar module [top row, right column] and illuminates the LEDs [right column, second from top] accordingly. A battery and on/off switch [bottom row, left to right] make up the power supply.James Provost

Feral cats respond to humans differently than socialized pet cats do. They see us as threats rather than bumbling servants. Even after years of daily feeding, most of the cats in our block’s colony will not let us approach closer than a meter or two, let alone suffer being touched. They have claws that have never seen a clipper. And they don’t like being surprised or feeling hemmed in. So I wanted a way to find out if a shelter was occupied before I popped open its lid for maintenance. And that’s where radar comes in.

SparkFun’s pulsed coherent radar module is based on Acconeer’s low-cost A121 sensor. Smaller than a fingernail, the sensor operates at 60 gigahertz, which means its signal can penetrate many common materials. As the signal passes through a material, some of it is reflected back to the sensor, allowing you to determine distances to multiple surfaces with millimeter-level precision. The radar can be put into a “presence detector” mode—intended to flag whether or not a human is present—in which it looks for changes in the distance of reflections to identify motion.

As soon as I saw the announcement for SparkFun’s module, the wheels began turning. If the radar could detect a human, why not a feline? Sure, I could have solved my is-there-a-cat-in-the-box problem with less sophisticated technology, by, say, putting a pressure sensor inside the shelter. But that would have required a permanent setup complete with weatherproofing, power, and some way of getting data out. Plus I’d have to perform three installations, one for each shelter. For information I needed only once every few months, that seemed a bit much. So I ordered the radar module, along with a $30 IoT RedBoard microcontroller. The RedBoard operates at the same 3.3 volts as the radar and can configure the module and parse its output.

If the radar could detect a human, why not a feline?

Connecting the radar to the RedBoard was a breeze, as they both have Qwiic 4-wire interfaces, which provides power along with an I2C serial connection to peripherals. SparkFun’s Arduino libraries and example code let me quickly test the idea’s feasibility by connecting the microcontroller to a host computer via USB, and I could view the results from the radar via a serial monitor. Experiments with our indoor cats (two defections from the colony) showed that the motion of their breathing was enough to trigger the presence detector, even when they were sound asleep. Further testing showed the radar could penetrate the wooden walls of the shelters and the insulated lining.

The next step was to make the thing portable. I added a small $11 lithium battery and spliced an on/off switch into its power lead. I hooked up two gumdrop LEDs to the RedBoard’s input/output pins and modified SparkFun’s sample scripts to illuminate the LEDs based on the output of the presence detector: a green LED for “no cat” and red for “cat.” I built an enclosure out of basswood, mounted the circuit boards and battery, and cut a hole in the back as a window for the radar module. (Side note: Along with tending feral cats, another thing I tried during the pandemic was 3D-printing plastic enclosures for projects. But I discovered that cutting, drilling, and gluing wood was faster, sturdier, and much more forgiving when making one-offs or prototypes.)

The radar sensor sends out 60-gigahertz pulses through the walls and lining of the shelter. As the radar penetrates the layers, some radiation is reflected back to the sensor, which it detects to determine distances. Some materials will reflect the pulse more strongly than others, depending on their electrical permittivity. James Provost

I also modified the scripts to adjust the range over which the presence detector scans. When I hold the detector against the wall of a shelter, it looks only at reflections coming from the space inside that wall and the opposite side, a distance of about 50 centimeters. As all the cats in the colony are adults, they take up enough of a shelter’s volume to intersect any such radar beam, as long as I don’t place the detector near a corner.

I performed in-shelter tests of the portable detector with one of our indoor cats, bribed with treats to sit in the open box for several seconds at a time. The detector did successfully spot him whenever he was inside, although it is prone to false positives. I will be trying to reduce these errors by adjusting the plethora of available configuration settings for the radar. But in the meantime, false positives are much more desirable than false negatives: A “no cat” light means it’s definitely safe to open the shelter lid, and my nerves (and the cats’) are the better for it.

Open Call for Applications and Nominations:

Do you know of a passionate disabled writer who is eager to explore the intersection of journalism, technology and disability? Do you aspire to shed a critical light on the impact of assistive technologies and mainstream technologies through a disabled lens? If so, we invite you to apply or nominate a deserving candidate for IEEE Spectrum’s Taenzer Fellowship for Disability-Engaged Technology Journalism.

About the Fellowship:

Our Fellowship for Disability-Engaged Journalism was created to resource new, early- and mid-career disabled journalists as they produce compelling narratives that spotlight the everyday and unique challenges and ideas that disabled people encounter with technology. Whether you’re an experienced journalist or an emerging writer, this fellowship offers a unique opportunity to develop your craft, while being supported with the accommodations you need to pursue stories. The Fellowship will run through the end of 2025.

Benefits of the Fellowship:

• Stipend: Fellows will receive a $2500 one-time stipend to support their commitment to investigative reporting on disability-related tech topics.

• Compensation: Ordinary professional freelance compensation will be provided by contract for the stories developed during the fellowship period, ensuring that fellows are recognized for their valuable contributions.

• Coverage of Assistive Services: We understand the importance of accessibility in journalism. Therefore, as part of assignment contracts, the fellowship will cover expenses for assistive services required by fellows to pursue their stories. These services include but are not limited to American Sign Language (ASL) interpreters, mobility aids, and document conversion.

• Schedule Flexibility: This fellowship will represent a part-time commitment, and as such can be maintained alongside other part-time work, freelance or gig work, and other schedule obligations. The requirement is that Taenzer Fellows have sufficient time to engage with the program through development workshops and report and write multiple news stories and one feature-length article during the course of their 18-month fellowship period. The scheduling will be as flexible as possible.

Eligibility Criteria:

- Journalists at early- to mid-career stages, including freelancers, are encouraged to apply, or those interested in entering journalism.
- Demonstrated interest or experience in writing about technology, disability rights, or related topics.

- Capacity to commit to the fellowship’s duration and deliver high-quality journalistic work.

How to Apply or nominate a candidate:

To apply or to nominate a deserving candidate for this fellowship, please submit the following materials:

1. A resume or curriculum vitae highlighting the candidates journalism experience and relevant achievements, or an email address where we can request a resume from nominees.

2. A statement of interest (500 words maximum) outlining your motivation for nominating someone or applying, your/their experience or interest in disability-engaged journalism, and what areas of technology you/they are interested in examining.

3. Three samples of the candidate’s published writing, preferably showcasing their ability to cover topics related to assistive technologies, disability rights, or technology through a disability lens. Self-published items, such as blog posts, or items written for limited circulation venues, such as an organizational newsletter will be considered.

Submission Deadline: August 15st, 2024.

Please send your application materials to cass.s@ieee.org with the subject line “Taenzer Fellowship Application.”

Contact Information:

For inquiries or further information, please contact Stephen Cass at cass.s@ieee.org or Margo Anderson at m.k.anderson@ieee.org.

Join us in making a meaningful impact through storytelling that fosters understanding, empathy, and inclusivity in journalism. Nominate someone now for the IEEE Spectrum Taenzer Fellowship for Disability-Engaged Technology Journalism and be a catalyst for change in the technology media world today!

Oh me, oh mesh! Many journalists in this business have at least one pet technology that’s never taken off in the way they think it should. Hypersonic passenger planes, deep-sea thermal-energy power plants, chording keyboards—all have their adherents, eager to jump at the chance of covering their infatuation. For me, it’s mesh radio systems, which first captivated me while I was zipping around downtown Las Vegas back in 2004. In that pre-smartphone, practically pre-3G era, I was testing a mesh network deployed by a local startup, downloading files at what was then a mind-boggling rate of 1.5 megabits per second in a moving car. Clearly, mesh and its ad hoc decentralized digital architecture were the future of wireless comms!

Alas, in the two decades since, mesh networking has been slow to displace conventional radio systems. It’s popped up on a small scale in things like the Zigbee wireless protocol for the Internet of Things, and in recent years it’s become common to see Wi-Fi networks extended using mesh-based products such as the Eero. But it’s still a technology that I think has yet to fulfill its potential. So I’ve been excited to see the emergence of the open-source Meshtastic protocol, and the proliferation of maker-friendly hardware around it. I had to try it out myself.

Meshtastic is built on top of the increasingly popular LoRa (long-range) technology, which relies on spread-spectrum methods to send low-power, low-bandwidth signals over distances up to about 16 kilometers (in perfect conditions) using unlicensed radio bands. Precise frequencies vary by region, but they’re in the 863- to 928-megahertz range. You’re not going to use a Meshtastic network for 1.5-Mb/s downloads, or even voice communications. But you can use it to exchange text messages, location data, and the like in the absence of any other communications infrastructure.

The stand-alone communicator [bottom of illustration] can be ordered assembled, or you can build your own from open-source design files. The RAKwireless Meshtastic development board is based around plug-in modules, including the carrier board, an environmental sensor, I/O expander board, radio module, OLED screen, and LoRa and Bluetooth modules.James Provost

To test out text messaging, I bought three HelTXT handheld communicators for US $85 each on Tindie. These are essentially just a battery, keyboard, small screen, ESP32-based microcontroller, and a LoRa radio in a 3D-printed enclosure. My original plan was to coerce a couple of my fellow IEEE Spectrum editors to spread out around Manhattan to get a sense of the range of the handhelds in a dense urban environment. By turning an intermediate device on and off, we would demonstrate the relaying of signals between handhelds that would otherwise be out of range of each other.

This plan was rendered moot within a few minutes of turning the handhelds on. A test “hello” transmission was greeted by an unexpected “hey.” The handhelds’ default setting is to operate on a public channel, and my test message had been received by somebody with a Meshtastic setup about 4 kilometers away, across the East River. Then I noticed my handheld had detected a bunch of other Meshtastic nodes, including one 5 km away at the southern tip of Manhattan. Clearly, range was not going to be an issue, even with a forest of skyscrapers blocking the horizon. Indeed, given the evident popularity of Meshtastic, it was going to be impossible to test the communicators in isolation! (Two Spectrum editors live in Minnesota, so I hope to persuade them to try the range tests with fewer Meshtastic users per square kilometer.)

I turned to my next test idea—exchanging real-time data and commands via the network. I bought a $25 WisBlock meshtastic starter kit from RAKwireless, which marries a LoRA radio/microcontroller and an expansion board. This board can accommodate a selection of cleverly designed and inexpensive plug-in hardware modules, including sensors and displays. The radio has both LoRa and Bluetooth antennas, and there’s a nice smartphone app that uses the Bluetooth connection to relay text messages through the radio and configure many settings. You can also configure the radios via a USB cable and a Python command-line-interface program.

In addition to basic things like establishing private encrypted channels, you can enable a number of software modules in the firmware. These modules are designed to accomplish common tasks, such as periodically reading and transmitting data from an attached environmental sensor plug-in. Probably the most useful software module is the serial module, which lets the Meshtastic hardware act as a gateway between the radio network and a second microcontroller running your own custom IoT application, communicating via a two- or three-wire connection.

The Meshtastic protocol has seen significant evolution. In the initial system, any node that heard a broadcast would rebroadcast it, leading to local congestion [top row]. But now, signal strength is used as a proxy for distance, with more-distant nodes broadcasting first. Nodes that hear a broadcast twice will not rebroadcast it, reducing congestion [bottom row].James Provost

For my demo, I wired up a button and an LED to an Adafruit Grand Central board running CircuitPython. (I chose this board because its 3.3-volt levels are compatible with the RAKwireless hardware.) I programmed the Grand Central to send an ASCII-encoded message to the RAKwireless radio over a serial connection when I pressed the button, and to illuminate the LED if it received an ASCII string containing the word “btn.”

On the radio side, I used a plug-in I/O expander to connect the serial transmit and receive wires. The tricky part was mapping the pin names as labeled on the adapter with the corresponding microcontroller pins. You need to know the microcontroller pins when setting up the receive and transmit pins with the serial module, as it doesn’t know how the adapter is set up. But after some paging through the documentation, I eventually found the mapping.

I pressed the button connected to my Grand Central microcontroller, and “button down” instantly popped up on my handheld communicators. Then I sent “btn,” and the LED lit up. Success! With that proof of concept done, pretty much anything else is doable as well.

Will makers building applications on top of Meshtastic lead to the mesh renaissance I’ve been waiting for? With more hands on deck, I hope to see some surprising uses emerge that will make the case for mesh better than any starry-eyed argument from me.