Categories
Community

Exploring the adoption of Go and Rust among backend developers

Among the many languages used in backend development, Go and Rust emerge as compelling options, each with its own unique strengths. Go, created by Google, is known for its simplicity and performance in distributed systems and microservices. Meanwhile, Rust, developed by Mozilla, has gained attention for its focus on safety and memory management.

In this post, we explore the current adoption of Go and Rust among backend developers, drawing insights from SlashData’s latest Developer Nation survey, which ran in Q3 2024 and reached more than 2,700 backend developers worldwide. We’ll dive into key questions like: How popular are Go and Rust in the backend developer community? How has their usage evolved over time? In which geographic regions are these programming languages more popular?

According to our latest survey data, 11% of backend developers currently use Go, while only 5% use Rust. Despite their appeal to developers working on scalable, high-performance applications, more versatile languages like JavaScript/TypeScript (41%), Java (39%), or Python (37%) dominate the space, with over a third of backend developers using them. 

Over the past 2.5 years, the adoption of Go and Rust among backend developers has remained stable, with no significant variations in their usage. However, while the share of backend developers using these programming languages hasn’t increased, the size of both the Go and Rust communities has grown alongside the overall increase in the backend developer population, which has grown by over 700,000 developers during this period.

The “Adoption of programming languages among backend developers” study, based on a sample size of 2,754 respondents, asked the question: “Which programming languages do you use to write code that runs on the server or in the cloud?” and provides an overview of the percentage of backend developers using various programming languages.

Regional adoption of Go and Rust among backend developers

Examining the adoption of Go and Rust from a regional perspective reveals some interesting patterns. Western Europe leads with the highest adoption rates of both Go (15%) and Rust (8%), indicating a strong interest in these programming languages. In addition to Western Europe, East Asia, and the Middle East & Africa show average or above-average adoption rates for both languages.

On the other hand, both Go and Rust see below-average adoption among backend developers in South America, North America, South Asia, and China. These lower adoption rates may reflect regional preferences for different technology stacks or a slower adoption of these newer technologies. Notably, Go’s adoption is lowest in China (5%), while Rust has its weakest presence in South Asia, where only 2% of backend developers use it.

The “Regional adoption of Go and Rust” report, based on a sample of 2,754 backend developers, examines the percentage of developers in each region using these languages for server or cloud code, as outlined in the “regions” tab.

The usage of Go and Rust among professional backend developers

The backend development community has one of the highest concentrations of professionals in the software development ecosystem, with 85% of backend developers involved professionally in the space. This trend is even more pronounced in the adoption of Go and Rust, as both are more likely to be used by professional backend developers than hobbyists and students, in contrast to other languages like JavaScript/TypeScript, Python, or C++.

When analysing Go and Rust adoption across companies of different sizes, we observe opposite trends. The usage of Go increases with company size, rising from 7% among freelance backend developers to 13% among those working for large enterprises with over 1,000 employees. In contrast, the adoption of Rust halves, from 6% among freelancers to only 3% within large organisations.

By creating Go, Google aimed to address the challenges of building large, efficient, and scalable systems. With its focus on simplicity, performance, concurrency, and developer productivity, Go becomes increasingly attractive to larger enterprises, especially those that manage vast cloud infrastructures, microservices, or backend systems where scalability and performance are critical.

On the other hand, smaller companies, particularly startups or niche firms, often focus on highly specialised areas such as blockchain, security, and performance-critical applications, where Rust truly shines. Moreover, smaller companies tend to be less bound by legacy systems or established tech stacks, allowing developers to experiment more freely with modern languages like Rust, which has been around for less than a decade.

Finally, let’s conclude this blog post by comparing the industries with the highest adoption rates of Go and Rust. Our data reveals that Go is most popular among backend developers working for companies in the tourism and hospitality (19%), automotive and marine (18%), and telecommunications and networks (18%) industries. Conversely, Rust enjoys its highest popularity among backend developers in automotive and marine (12%), hardware products (12%), and insurance (10%).

The “Adoption of Go and Rust by company size” analysis, based on a sample of 2,475 professional backend developers, details the percentage of developers using these languages across different company sizes for server or cloud code, as shown in the “csize” tab.

Are you a Go or Rust user? We would love to hear from you. Participate in our latest survey, help shape the future of technology and win great prizes.

About the author

Álvaro Ruiz Cubero

Market Research Analyst

Álvaro is a market research analyst with a background in strategy and operations consulting. He holds a Master’s in Business Management and believes in the power of data-driven decision-making. Álvaro is passionate about helping businesses tackle complex strategic business challenges and make strategic decisions that are backed by thorough research and analysis.

Categories
Tips

Five backend books you should read in 2021.

Powering up your backend knowledge? Our friends at Packt have shared five backend books you should read in 2021.

Node Cookbook, Fourth Edition

Discover solutions, techniques, and best practices for server-side web development with Node.js 14

What reviews say:

“Want to learn Node.js, brush up on your skills, or discover the latest features of Node 14 and beyond? This book is for you! Written by a senior developer and Red Hatter, With a thorough presentation of everything Node, Bethany Griggs delivers from cover to cover in this latest Node Cookbook edition.

Node.js Web Development, Fifth Edition

Server-side web development made easy with Node 14 using practical examples

What reviews say:

“This book is great. I had some knowledge about full-stack JavaScript, but this book has already taught me a lot. I wouldn’t say that this book is for a complete beginner to software development (coding), but it’s definitely good if you need to deepen your understanding of JavaScript, or if you’re interested in getting started with JavaScript from another backend language like Python, C#, Ruby, etc.”

ASP.NET Core 5 and React

Full-stack web development using .NET 5, React 17, and TypeScript 4

What reviews say:

“The book had a very methodical approach to building single-page applications through React. I am familiar with React and .NET separately and partly why I could pick up the concepts in the book faster but I believe otherwise too, things are laid out very clearly. Recommend it for beginners.”

Full-Stack React, TypeScript, and Node

Build cloud-ready web applications using React 17 with Hooks and GraphQL

What reviews say:

“Nook has a philosophy of “learning by doing” “

Building Vue.js Applications with GraphQL

Develop a complete full-stack chat app from scratch using Vue.js, Quasar Framework, and AWS Amplify

What reviews say:

“This book is a fantastic deep dive into building an end-to-end application on AWS. I really like the fact that he dove deep into many topic areas, showing how to tie everything together to build something that is a real-world use case. The information in this book can also be used in many other areas so the knowledge is very transferable to other scenarios and use cases.”

What titles do you recommend? Share your thoughts in the comments.  Looking for more inspiration? Here are more book recommendations.

Categories
Analysis

Why do developers adopt or reject cloud technologies?

In the nearly fifteen years since Amazon AWS cracked open the cloud market by releasing S3 – and changed the world by doing so – there has been huge growth in the variety of cloud solutions available for developers to use. We examine the different reasons that developers give for adopting or rejecting cloud technologies. The findings shared in this post are based on the Developer Economics survey 19th edition which ran during June-August 2020 and reached more than 17,000 developers in 159 countries.

Of the new cloud technologies which have appeared over the last fifteen years, containers have arguably had the greatest impact. With 60% of developers using this technology, the benefits are clearly widely recognised. However, with just under 30% of developers using container orchestration tools and management platforms, there is still room for this technology to develop.

In second position, with 45% of cloud developers using this technology, Database-as-a-Service (DBaaS) is also very widely used, and data storage and retrieval will continue to be an important issue, albeit in a much more sophisticated form than S3 originally offered. Cloud Platform-as-a-Service (PaaS) sits in a distant third place. A third of backend developers are using PaaS, putting this technology slightly ahead of the other ones we ask about – between 21-27% of developers use them.

Why do developers adopt or reject cloud technologies - containers is the cloud technology that is most widely used by backend developers.

Abstraction and simplification are two of the main drivers for the mass adoption of cloud technologies, but we can’t overlook the role that flexibility plays. Spinning up instances to cope with variable demand, creating temporary testing environments, and adding storage as required is immensely powerful. But one often-overlooked aspect of this flexibility is that developers and organisations have the flexibility to choose. They are not restricted to the expensive, bare metal they bought ten years ago, and they are less constrained by monolithic purchasing processes, because, to put it simply, these decisions matter less. In a world where infrastructure can be provisioned and destroyed at will, and where data and server configurations can be transferred easily between homogeneous systems, cloud providers have to find other areas of differentiation in order to compete. Vendor lock-in is much less of an issue for users than it once was, and the rise of the developer as a decision-maker has put even more power into their hands. Note the adoption and rejection reasons for DBaaS and orchestration platforms come from our previous survey, fielded in Q1 2020.

“Pricing and support/documentation are most important to developers”

For every cloud technology, with the exception of orchestration tools, pricing and support/documentation are the two most important factors that developers consider when adopting that technology. For the most part, these two factors switch between first and second place, however, pricing drops to fifth place for developers considering adopting an orchestration tool, whereas support/documentation remains at the top by a large margin. Around three in ten of these developers selected ease and speed of development (32%), integration with other systems (31%), community (30%), and pricing (29%) as reasons for adoption, with pricing being around 15 percentage points lower for orchestration tools than for other technologies. On the other hand, community and scalability are generally more important for developers selecting an orchestration tool.

Much of this distinction is driven by the dominance of Kubernetes. With 57% of backend developers who are using an orchestration tool choosing Kubernetes, it is the single most popular orchestration tool, and importantly, it’s free and open source. It stands to reason, therefore, that pricing is simply not an issue for developers using Kubernetes, instead they value the community support that helps them master such a complex tool.

Indeed, as well as pricing being much less important for these developers, the learning curve is also less important. It seems that these developers understand that they are dealing with high levels of complexity and abstraction and accept that there is a lot to learn in this space. But for those developers that want the abstraction and simplicity offered by a commercial container management system, many paid options exist, and pricing is still an important factor in this space.

Why do developers adopt or reject cloud technologies - Ranking of reasons for adoption

Taking developers’ reasons for rejection into account let us view the decision-making process from the other side. Immediately, we see that pricing is the dominant factor when rejecting every technology. Taking a closer look at the data shows the true extent of this – for DBaaS and Infrastructure-as-a-Service (IaaS), developers were more than twice as likely to select pricing as a rejection reason than the second- and third-placed reasons of support/documentation, and the learning curve, respectively. Amongst the remaining technologies, the smallest difference was 8 percentage points, for developers rejecting orchestration tools.

Further down the list, there is a lot of variability between the different technologies. For example, the learning curve was the second most popular rejection reason for developers choosing IaaS, with a quarter of them doing so. This suggests that the learning curve for IaaS is quite steep and that this is a barrier for many developers. This is not the case for DBaaS however, where only 15% of developers stated this as a reason for rejection.

“Suitability, feature set and performance are hygiene factors”

Suitability and feature set has middling importance for developers choosing to adopt a technology, but for many technologies, it is a more important reason for rejection. This shows that suitability and feature set is a hygiene factor – there are relatively few cases where this is of paramount importance, but many where a technology does not meet the needs and is therefore rejected.

Finally, performance sits very low in the hierarchy for developers adopting and rejecting cloud solutions. This indicates that, for the vast majority of uses cases, the range of performance options provided by vendors is sufficient. This suggests that many cloud computing products are, to some extent, homogenous, and that developers are more concerned with the ‘soft’ features, such as support/documentation, community, or learning curve. These features make for a fulfilling development experience, and in the age of the developer as a decision-maker, experience is everything.

Why do developers adopt or reject cloud technologies - ranking of reasons for rejection.

What are your reasons for adopting or rejecting cloud technologies? You can let us know your reasons here!