Solidity Developer Survey 2022 Results

The 2022 Solidity Developer Survey results are in! In this post, we will be summarizing and analyzing them.

First of all, a big thank you to everybody who took the time and participated and to everybody who helped us spread the word about it! This year, we received a smashing 1401 responses. That is more than a 3x in responses compared to the previous survey and we couldn't be happier with the turnout. Your input is invaluable to us and plays a crucial role in helping to continuously improve the Solidity developer experience as a whole.

Before we get started, here are a few useful links:

• In the spirit of open source, you can find all raw data of the survey results here and all graphs here.
• Since this is already our third time conducting a yearly survey, it may be interesting for you to compare the outcome to the previous surveys. The results from the 2021 developer survey are available here and from 2020 here.

Without further ado, let’s dig into the 2022 results!

Summary & Notable Insights

• Survey Audience: In total, 1401 developers from 100 different countries participated in the 2022 survey. That is more than a 222% increase in responses compared to the previous survey (435 respondents)! The coverage of different geographies also continuously increased from 48 countries in 2020 to 73 countries in 2021 to 100 countries in 2022. Roughly 18% stated to be residing in the US, followed by India (10%) and France (5%).
• Developer Profiles: The level of coding experience remains at a medium to a high level, with the majority of respondents having coded professionally for 3 or more years, 12.5% even more than 15 years.
• Solidity Experience: More than half of all respondents have been using Solidity for less than a year, while 13.8% have been using it for more than 3 years. 41% use Solidity daily, and 37.3% weekly.
• Solidity Expertise: Many deem themselves Solidity experts, with a self-rating in the expertise of 7 or higher (out of 10). 4.6% rate their expertise as a 10 out of 10. 70% of those have been using Solidity for 2-3 years or longer.
• Developer Experience: The majority (+75%) believe that the Solidity developer experience improved in the last year. 0.9% are of the opinion it got worse. Debugging issues are frequently encountered, followed by stack-too-deep errors and bytecode size limitations.
• Future Features: Support for decimal numbers and generics was mentioned most often as the “most anticipated Solidity feature”.
• Liked & Dreaded Features: Respondents most like Solidity's syntax, the simplicity of learning, reading, coding, and compiling, and the static typing. The most significant pain point is “stack-too-deep”, with 33.6% of all votes, followed by missing memory optimizations (waste of memory) (24.4%) and redundant checks (e.g. in checked arithmetic) (11.8%). 9.9% say that compiler performance is their biggest issue.

Demographics of the Survey Audience

⚠️ Be aware that this survey has only been shared in English when interpreting results regarding the distribution of countries of residency and language preferences.

As usual, we begin by looking at the developers who participated in this survey: In this first chapter, we cover general information on the survey audience, which includes residency and spoken languages.

In total, 1401 developers from 100 different countries participated in the 2022 survey. Compared to the previous survey, this represents a 222% increase in responses.

The coverage of different geographies increased from 73 countries in 2021 to 100 countries in 2022.

Residency

Roughly 18% of respondents stated to be residing in the US, followed by India (10%), France (5%), and Nigeria (4.5%).

Language

The diversity of respondents did not only increase in terms of countries of residency but also in terms of the native language. In total, 70 different languages were mentioned as their native languages. That’s a 40% increase compared to the previous year.

31.5% state English as their native language, followed by Indian languages (12.4%), Spanish (8.4%), French (6.9%), Russian (6.4%), and German (4.7%).

ℹ️Hindi, Urdu, Telugu, Bengali, Tamil, Malayalam, Gujarati, Marathi, Kannada, and Odia were clustered as “Indian languages”. Chinese, Cantonese, and Mandarin were clustered as “Chinese languages”. Persian, Pashto, and Ossetian were clustered as “Iranian languages”.

With almost 80%, the majority of respondents predominantly speak English at work. Other languages that are spoken at work: French (3.2%), Russian (3.1%), and Chinese languages (2.3%).

Of the respondents who didn't name English as their native language, 87% are okay with reading the Solidity documentation in English.

12.9% would prefer to read it in their native language, the most mentioned ones being Spanish, Indian languages, and Russian.

ℹ️ Note: This survey has only been conducted in English, which may have impacted the outcome of this question. We still believe internationalization of resources like the Solidity documentation is a crucial factor in lowering the barriers of entry, and we aim to support by helping coordinate the community-driven translation efforts.

Developer Profile

In the second section of the Solidity Developer Survey, we learn more about the professional experience and coding preferences of the survey audience.

Work Experience & Employment

Roughly 71% of respondents were employed at the time of the survey, while roughly 12% stated they were students, and 17% said they were currently not working professionally.

Compared to the previous survey, there is a slight increase in both the number of students and currently unemployed developers.

The employed respondents predominantly work in the “crypto” (58.2%) and technology (21.6%) and financial services (5.4%) sector.

37,1% of all respondents are seniors and have been coding professionally for 6 years or more, 12.5% of them even for 15+ years.

On the other side, roughly 12% are coding newbies and have only coded professionally for less than a year.

With approximately 22%, the biggest group sits in the middle of the distribution and has professional coding experience of 3-5 years.

Overall, the level of coding experience is medium to high with the majority of respondents (59.2%) having coded professionally for 3 or more years. 7.7% have never coded as part of their job, 37% of which are students.

Touch Points with Solidity

As in the previous survey, the majority of respondents (75.7%) still use Solidity for their personal projects.

Roughly 64% of all respondents use Solidity at work.

More than 20% state they are leading a programming team.

Only 23.4% of respondents contribute to open-source projects written in Solidity on a daily or weekly basis. The rest states to do so monthly (27.4%) or never (47.1%).

Programming Language Preferences

Solidity marks the most used programming language for the survey audience (28.6%), closely followed by JavaScript (25.6%) and TypeScript (20.5%).

Other less frequently mentioned languages are Python (8.7%), Rust (2.7%), and Go (2.5%).

Similar to the previous year, the respondents' favorite programming languages are distributed more evenly across various languages.

Solidity is the most popular, scoring 18.8% of all entries, followed by JavaScript (17.3%), Python (15.2%), TypeScript (15.0%), and Rust (8.6%).

Operating System

Most respondents use MacOS as their primary Operating System (41.8%). Windows and Linux seem comparatively popular, with 30.5 and 27.7%, respectively.

Solidity User Profile

In this section of the survey, we asked respondents about their Solidity-specific development experience and usage habits.

Solidity Experience

Almost 50% of all respondents deem themselves Solidity experts, with a self rating in expertise of 7 or higher (scale of 10).

4.6% rate their expertise as a 10 out of 10, and 70% of those have been using Solidity for 2-3 years, or longer.

Roughly 23% can be considered beginners or low-frequency users with a self-rated expertise level of 4 or lower.

The distribution of self rating remained similar to the previous survey, even though the survey audience tripled in size.

Roughly 50% of all respondents have been using Solidity for less than a year, with 13% having just started their Solidity journey (less than three months of experience).

13.83% have been using Solidity for more than 3 years and can thus be considered “Solidity seniors''. To put years into perspective: “Version 0.1.1”, the oldest version of Solidity on solc-bin, is from August 2015 and thus roughly 7.5 year old. The language is still relatively young and continues to evolve. We may add more granular selection options for “more than 3 years” of Solidity experience to distinguish this better in the next survey.

As in previous years, Solidity appears rather easy to learn, with 21.2% of respondents feeling productive in less than a month and 39.3% in less than half a year.

8.1% needed more than a year to feel comfortable with the language.

17.8% don't feel productive yet, out of which more than 74.2% are beginners and have been using Solidity for 6 months or less, and 47% even less than three months.

Solidity User Profile and Usage Habits

With regards to usage frequency, more than 40% of respondents use Solidity on a daily basis!

37.3% use it weekly, and 13.9% on a monthly basis.

Roughly 8% indicated to be using Solidity "rarely" or "never".

Most of them indicated before that they use Solidity for personal projects and code in a different programming language at work.

A striking 81.8% of all respondents use Visual Studio Code as their editor when writing Solidity code. Vim and IntelliJ follow in the second and third ranks with 3.7 and 3.4% usage, respectively.

Compared to the previous survey in 2021, Visual Studio code gained significantly in popularity (from roughly 50% to 81.8%).

Depending on the chosen IDE, we also asked respondents which Solidity-related plugins they use, if any.

“HardHat VSCode” by Nomic Foundation and the “Solidity” extension by Juan Blanco (both for Visual Studio Code) are the most popular.

Hardhat remains the most popular Ethereum-specific development environment, with roughly 75% of all respondents using Hardhat.

Remix follows with 42%. Foundry has significantly increased its share from 1.6% in 2021 to 30% in 2022.

Truffle continues to move more into the background, with 17% of respondents indicating that they use it.

Rather "niche" Ethereum-specific development environments are Brownie (6.7%), Ape (3.3%), Dapptools (2.3%), and Embark (0.8%).

4.4% of respondents are not using any Ethereum-specific development environment.

It’s worth noting that this question was a checkbox question, allowing respondents to select multiple answers.

⚠️ Comparing the results from 2020, 2021, to 2022 may offer some insights like Truffle losing a significant share (2020: 59.3% -> 2021: 26.2% -> 2022: 17%), while Hardhat, and newcomers like Foundry increased their share in users. However, it's important to consider that the previous surveys had significantly fewer responses (2020: 194, 2021: 435, 2022: 1401). A year-on-year comparison can only be interpreted as a loose trend and it’s not the intent of this study to analyze user splits between IDEs in detail.

With roughly 90%, 0.8.x Solidity versions remain to be the by far most used ones. The usage share of both the 0.7.x (10.2%) and the 0.6.x (7.7%) series continues to decrease since the previous survey. Everything older than that is hardly in use anymore.

⚠️ Reminder: Please make sure to frequently update your code (and compiler) to the latest Solidity version. Several important bug fixes and security improvements are added in the newer versions!

Solidity Usage Details

This year, we also asked specific questions about Solidity usage habits.

For charts and figures on those, please refer to the presentation with all graphs and the raw data file.

To summarize:

• Command line: Roughly two thirds of respondents do not use the Solidity compiler directly via the command line. 37.5% do.
• Command line: When using the compiler on the command line, 61.3% still use Standard JSON.
• Optimizer: 93.6% do not disable the optimizer. The 6.4% that enabled the optimizer, stated that they would do so due to contract size limits, slow compilation, in order to pass EtherScan verification, for gas testing purposes or because of security concerns.
• Gas estimator: 23.4% use the gas estimator that is built into the compiler. 25% have tried it, but don’t use it regularly, while 41.5% never use it.
• SMTChecker: 81% of all respondents never use the SMTChecker. 13.7% have tried it and 5.4% use it frequently. You can learn more about the SMTChecker here.
• via-IR compilation pipeline: 70.8% do not know what via-IR is. 18.6% use the via-IR pipeline already. In the following weeks, we will share more context about why you should switch from the legacy compilation pipeline to via-IR and what this means.
• Metadata publication: 53.5% publish the metadata of their smart contracts. 27.8% don’t, while 18.7% don’t know what this means.
• Sourcify: 11% of all respondents use Sourcify for smart contract verification, while 21.2% claim to not need it. 67.8% don’t know what Sourcify is. If you want to learn more about Sourcify, visit sourcify.dev.

Fixed-Point Types

Approximately 91% of all survey respondents don’t use fixed-point types.

The 9% (100 people) that do primarily use PRB Math, solmate’s FixedPointMathLib, and custom implementations.

Other EVM Networks

More than half of all respondents use Solidity outside of Ethereum Mainnet and testnets. When asked which other networks they deploy their smart contracts on, the most popular chain was by far Polygon (formerly Matic Network). Other often mentioned blockchains include Binance Smart Chain, Arbitrum, Avalanche and Optimism.

Other Smart Contract Languages

Half of all respondents use other smart contract languages alongside Solidity. The most used other smart contract language is Yul, an intermediate language for Solidity, with 17.2%, followed by Vyper, a pythonic EVM language, with 10.5%. Cairo (7.1%), a STARK based language targeting StarkNet, and Huff (6.2%), a low-level assembly language for the EVM, are also mentioned several times. Other “newcomers” like Sway (2.4%) and Fe (1.5%) also make it into the chart.

Solidity Developer Experience

76.5% of all respondents believe that the Solidity developer experience generally improved throughout the last year. 25.1% are of the opinion that they noticed a big improvement compared to the previous year.

7.8% say that nothing has changed in their experience, while 0.9% of the respondents think it got worse.

Compared to the previous year’s results, the share of “got worse” and “I don’t know” decreased, while “no change” slightly increased. Overall, the picture is very comparable.

When getting stuck on a Solidity problem, most respondents visit Ethereum StackExchange / StackOverflow for help or search for a solution on the Internet. Many also ask their coworkers for help or watch tutorial videos.

Recurring Issues

60% of respondents don't encounter the same or similar issues multiple times when developing in Solidity.

Amongst the 40% that do, debugging issues are encountered most frequently, followed by stack-too-deep errors and bytecode size limitations.

ℹ️On the topic of debugging issues, we'd like to use the opportunity to highlight a new initiative aimed at defining a common debugging data format for languages built on top of the EVM: ethdebug. The end result will be a specification that will allow debuggers, analyzers, and other tools to reliably map between the EVM bytecode produced by compilers and the high-level language features. This has been a common pain point across the ecosystem for years and is becoming more pressing with the introduction of the new IR-based code generator (i.e. the via-IR pipeline) in Solidity, which often breaks implicit assumptions tools made based on how the legacy pipeline worked. We encourage all developers working on such tools to join the working group. The group has regular bi-weekly meetings and coordinates via the ethdebug channel on Matrix.

Getting Started & Documentation

Most respondents considered it easy or “okay” to get started using the Solidity compiler. 4.2% (55 people) stated that it was difficult for them. When asked what made it difficult to get started, some mentioned a previous lack of technical background or development experience, and others also pointed out a lack of good learning resources or outdated learning resources.

Almost 64% of survey respondents consider the Solidity documentation helpful, followed by 33% who deem it “somewhat” useful. Only 3.3% don’t find it useful at all.

Ideas for improvement most prominently ask for more code examples but also a better high-level overview of syntax, better in-docs search, better SEO, and easier wording.

Biggest Pain Points

Different from the previous years, this year, we tried to structure the question around the “biggest pain points” better and clustered the first step into several prominent categories: Stack-to-deep, gas related issues, compiler performance, and “other”.

The biggest pain point is “stack-too-deep”, with 33.6% of all votes, followed by missing memory optimizations (waste of memory) (24.4%) and redundant checks (e.g. in checked arithmetic) (11.8%). 9.9% say that compiler performance is their biggest issue.

15.8% selected “other” and were able to specify their most significant pain point in a free text field. Most prominently mentioned: Contract size limit, error messages, and issues with debugging.

High-Impact Compiler Bugs

As part of this year’s study, we were also curious to find out whether Solidity developers had been affected by any of the high-impact compiler bugs (codegen bugs that are announced with Security Alerts on the Solidity blog).

Initially, 4.7% said yes. However, when asked which one they were affected by, only two out of the 63 people were able to point to actual Solidity vulnerabilities in the follow-up question. This gives room to assume the actual number of affected developers from this survey is significantly lower than 4.7%, and some respondents may have simply misunderstood the question. We will try to phrase this question more precisely in the next survey.

Language Design & Upcoming Features

Favorite Feature / Solidity Aspect

Respondents most like Solidity's syntax, the simplicity with regards to learning, reading, coding and compiling and static typing.

The most mentioned liked features in descending order were:

• Syntax
• Easy to... read/code/compile/learn
• Simplicity
• Static/strong/strict typing
• Similarity to other languages (most mentioned JS/TS and object-orientedness, also mentioned: Rust, C++, Python)
• Modifiers
• Inline assembly
• Mappings
• Inheritance
• (User-defined) types
• SafeMath / checked and unchecked
• Yul

Most Dreaded Aspect

This year, we asked the survey audience a slightly different question: “If you could change one thing about Solidity, what would it be?”

Most mentioned “change requests” in descending order were:

• Fix stack-too-deep
• Better array handling
• Gas optimizations
• Add fractional numbers (fixed point types / floating types)
• Better error handling, descriptions
• Better debugging
• Higher contact bytecode size limit

Future Features

Most Anticipated Feature

Support for fractional numbers and generics was mentioned most often as the “most anticipated Solidity feature”.

⚠️ Similar to the previous year, we noted that respondents were using various different terms like "floats", "floating point arithmetic", "floating point number", "fixed point numbers", and "fixed point math". We categorized those as "fractional numbers".

Most mentioned anticipated features in descending order:

• Support for fractional numbers (fixed point types / floating points)
• Generics
• Better optimization
• No stack-too-deep
• Better debugging
• Transient storage
• Standard library
• Better error messages

EIP Support

We also wanted to know what Solidity-related EIPs the survey respondents think need support in the compiler.

EIP-2535 “‘Diamonds, Multi-Facet Proxy” was mentioned most often, followed by EIP-1153 “Transient Storage” and EIP-3540 “EOF - EVM Object Format”.

Restrictiveness

Regarding language restrictiveness, roughly 43% of respondents wish that Solidity stays “as is”. 41% tend towards more restrictive/explicit, having more checks, while approximately 16% would like Solidity to be less restrictive.

Solidity Developer Community

Language Design Community Participation

Less than 10% of all respondents ever participated in Solidity language design related efforts.

The distribution between participating in forum discussion and proposing features or language changes as a Github issue is fairly similar, while language design discussions and feedback calls have slightly less participation (all between 80 - 108 people, multiple selections possible).

Of the roughly 90% that did not participate in language design, most state they don’t know how, followed by being “too busy with work or other things”. Roughly 30% say that they are not interested in or qualified for the discussions.

Staying Informed

Similar to the previous years, most people like to stay up-to-date about Solidity versions, security alerts, and announcements by following Solidity on Twitter or Mastodon.

Other often used means for information are the Solidity blog and Solidity GitHub release page.

Interestingly, almost 30% claim to not be doing any of the above.

As part of “other”, respondents specified several community based means to stay up-to-date:

• YouTube
• Crypto Twitter / Community chats
• Solidity docs
• "Week in Ethereum News" Newsletter
• "Crypto influencers" / Popular Solidity developers
• Updating RemixIDE / Hardhat / VS Code
• Coworkers
• Google
• Newsletters
• Conferences / Meetups
• OpenZeppelin forum
• Solidity website
• Reddit

Interaction with Other Solidity Developers

More than half of respondents interact with other Solidity developers.

16.7% don’t interact with other Solidity developers at all.

Like in the previous years, as the last part of the survey, we wanted to hear how many participants agree or disagree with several statements regarding the Solidity community and the work of the Solidity team.

• 66% of respondents feel (somewhat) welcome in the Solidity developer community.
• Roughly 77% agree or somewhat agree that they feel confident in the work of the Solidity team.
• More than half feel welcome to contribute to Solidity, however, only less than 40% say that they know how to contribute ideas or feedback to Solidity.
• Roughly 25% are confident that the Solidity team understands their needs as a developer. Another 35% somewhat agree, while approximately 9% disagree or strongly disagree.

The results of this “community and Solidity team confidence ranking” are very comparable to the previous year.

One can derive that while the community seems confident in the competency/qualification of the Solidity team, the communications around ways to contribute as well as understanding of the community’s needs, can be improved. Those are things that we have been working on improving throughout the last years and will continue to do so.

Thank You & See You Next Year!

Lastly, we want to take the opportunity to thank you for all your lovely and motivating messages and the feedback received. We were overwhelmed by the sheer number of survey responses and hope to continue this trend in the coming years! We hope the insights from this survey were useful to you, as they certainly are for us! We will continue to collect feedback on an ongoing basis.

To not miss anything, make sure to:

• Follow Solidity on Twitter or Mastodon.
• Join the language design discussions in the Solidity forum or provide us feedback there.
• Follow announcements and security alerts on the Solidity blog.
• Follow and ⭐ the Solidity repo on Github.

All graphs can be found here. The raw and analyzed data can be found here.