2024年Solidity开发者调查结果

我们很高兴与大家分享 Solidity 开发者调查 2024 的结果！在这篇博文中，我们将回顾调查的各个部分的主要见解和详细分析。

在深入探讨之前，我们要感谢所有提交调查回复并帮助我们触达目标受众的人。你们的意见对我们来说非常宝贵，并且对于推动重要的语言设计决策和改进作为开源项目的 Solidity 至关重要。

今年，我们收到了总共 684 份回复。让我们从一些有用的链接开始：

• 本着开源的精神，你可以在此处找到调查结果的所有原始数据，并在此处找到所有图表。
• 这是我们的第五次年度调查。你可以通过查看下面的博文将 2024 年的结果与往年进行比较：
  • 2023
  • 2022
  • 2021
  • 2020

事不宜迟，让我们深入研究 2024 年的结果！

摘要 & 显著见解

该调查包括 6 个部分，即：[1] 人口统计信息，[2] 开发者和用户概况，[3] Solidity 背景，[4] Solidity 开发者体验，[5] 语言设计，以及 [6] Solidity 开发者社区。

让我们看看 2024 年调查中这些不同部分的摘要中的一些主要见解。

• 人口统计信息：总共有来自 91 个不同国家的 684 名开发者参与了 2024 年的调查。回复者数量最多的是美国 (10.8%)，其次是印度和尼日利亚，各占 7.8%。这与去年的见解保持一致，只是今年尼日利亚与印度并列第二位。
• 开发者和用户概况：Solidity 仍然是回复者使用最多的语言，其次是 TypeScript 和 JavaScript。 大多数 Solidity 专家（自评为 10）使用该语言已超过 5 年。
• Solidity 背景：76.6% 的用户每天或每周定期使用 Solidity。此外，Foundry 今年攀升至使用最多的 Ethereum IDE，获得 51.1% 的选票。
• Solidity 开发者体验：绝大多数（66.8%）的调查参与者认为 Solidity 开发者体验在过去一年中总体有所改善。 Mappings (21.8%)、contracts as objects (20.4%) 和 modifiers (15%) 连续两年以完全相同的顺序成为最受欢迎的 Solidity 功能。
• 语言设计：在今年最受期待的功能/更新中，消除 stack-too-deep (18.2%)、更好的调试工具 (16.9%) 和 gas 优化 (13.2%) 的排名最高。
• Solidity 开发者社区：Solidity Twitter/Mastodon 取代 GitHub Releases 成为用于了解 Solidity 公告的最受欢迎的来源。

人口统计信息

⚠️ 仅供参考 - 此调查仅以英文分享。在解释有关居住国家和语言偏好的分布结果时，请考虑到这一点。

我们将首先回顾调查的第一部分的结果，该部分涵盖调查回复者的人口统计信息。

总共有来自 90 个不同国家的 684 名参与者参与了 2024 年的调查。

不同地区的覆盖范围从 2021 年的 73 个国家增加到 2022 年的 100 个国家，然后在 2023 年回落到 71 个国家，今年已增加到 90 个国家。值得注意的是，与 2023 年相比，今年调查受众的地域多样性有所增加。

居住地

大多数（10.8%）的回复者提到他们居住在美国，其次是印度和尼日利亚，各占 7.8%，而法国今年以 3.8% 的选票超过了德国。

除了法国今年的排名高于德国之外，前 5 个居住国家/地区的顺序与 2023 年相似。但是，个人数字发生了变化。例如，调查参与者中美国居民的比例有所下降，而尼日利亚的比例则有所上升。

供参考，请参阅世界地图和图表，其中列出了居住地超过 13 个回复的国家/地区。

语言

在 2024 年的调查中，总共提交了 75 种语言作为回复者的母语。

26% 的参与者以英语为母语，9.3% 的人说印度语言，8.3% 的人说西班牙语，6.5% 的人说俄语，6.1% 的人说法语，葡萄牙语和非洲语言各占 4.4%，3.7% 的人说德语，2.8% 的人说汉语。

请注意，今年俄语已攀升至第 4 位，非洲语言的排名也略高于去年，而汉语的选票与 2023 年相比有所下降。

ℹ️ 注意：印地语、乌尔都语、孟加拉语、泰卢固语、卡纳达语、泰米尔语、古吉拉特语、马拉雅拉姆语和马拉地语被归类为“印度语言”。斯瓦希里语、豪萨语、伊博语、约鲁巴语、卢干达语、南非荷兰语、坎巴语、斯瓦希里语、马达加斯加语、米纳语、绍纳语和西斯瓦蒂语被归类为“非洲语言”。粤语、汉语和普通话被归类为“汉语”。

值得注意的是，今年有更多的非洲语言进入了调查结果。

虽然今年的分布几乎相同，但在工作中说其他语言（50.6%）的参与者比例略高于在工作中说母语的参与者（49.4%）。与去年相比，这种趋势发生了变化。

总共有 76.7% 的回复者表示他们在工作中主要说英语，其次是印度语言、法语、汉语、俄语、西班牙语、葡萄牙语等。除了英语之外，所有这些语言在该图表中都紧随其后。

总共有 88% 的参与者表示他们可以接受阅读英文的 Solidity 文档。这个数字略高于去年。

但是，12% 的参与者更喜欢以他们的母语阅读文档。

ℹ️ 注意：此调查仅以英语进行，这可能会影响此问题的结果。我们仍然认为 Solidity 文档等资源的国际化是降低入门门槛的关键因素，我们的目标是通过帮助协调社区驱动的翻译工作来支持这一点。

开发者和用户概况

在调查的下一节中，我们将介绍开发者和用户的专业背景，并分享他们对编码语言、开源贡献、操作系统等的偏好。

就业和工作经验

66.6% 的回复者在调查时已就业，而 14% 的人表示他们是学生。19.4% 的人报告说他们在调查时未就业。

与之前的调查相比，总体分布几乎相同。

在接受调查时已就业的总参与者中，有 71% 的人在“加密货币”领域工作，而 16.4% 的人在一般技术领域工作，5.1% 的人在金融服务领域工作。只有一小部分人在教育/学术界和媒体/游戏领域工作（各占 1.9%）。

同样，这种趋势与前一年的结果几乎相同，只是各个百分比略有变化。

虽然总共有 41.5% 的回复者被认为是其领域的高级人员，拥有超过 6 年的专业编码经验，但 7% 的人从未在工作中进行过编码。在 41.5% 的高级人员中，甚至有 13.4% 的人已经编码了 15 年以上。

大多数回复者（占 27%）是具有 3-5 年经验的中级程序员，而只有 8.8% 的人专业编码经验不到一年。

总体而言，专业编码经验的水平为中等到高，大多数回复者（68.6%）拥有 3 年以上的专业编码经验。

虽然该图表与去年相比保持了其形状，但不同年份的经验的各个数据略有不同。例如，拥有 15 年以上经验的回复者比例高于去年。

开发者概况

当被问及哪个开发者概况最能描述参与者时，大多数人选择了全栈开发者，这是我们今年新添加的选择，目的是让参与者能够更准确地表明其技术背景。

由于今年出现了不同的分布，因此发现 24.1% 的回复者是审计员/安全专家，紧随其后的是 22.6% 的智能合约开发者、11.5% 的学术研究人员和仅 5.2% 的工具开发者。

大多数（45.5%）的参与者在工作和个人项目中都使用 Solidity。其余的回复者几乎平均分布在使用 Solidity 工作（27%）和使用 Solidity 进行个人项目（27.6%）之间。这种趋势与去年相似，只是各个数字略有变化。

总共有 25.8% 的用户定期（每天和每周）为用 Solidity 编写的开源项目做出贡献，而 28.4% 的用户仅每月贡献一次。

另一方面，45.7% 的用户报告说他们从未为用 Solidity 编写的开源项目做出贡献。

与往年相比，我们遗憾地看到为用 Solidity 编写的开源项目做出贡献的用户的数量呈下降趋势。

编程语言偏好

与往年一样，Solidity 在参与者中使用最多的编程语言中排名第一（42.4%），这个数字与去年几乎相同，其次是 TypeScript (21.5%) 和 JavaScript (15%)。

前 3 种最常用的语言的顺序与去年相同。

其他不常提及的语言包括 Python (10.3%)、Rust (4.4%)、Go (2%)、C# (1.7%) 和 Java (1.7%)。

由于去年 Go 作为“其他”响应指定的次数几乎与 Java 相同，因此已将其作为语言列表中的一个选项引入，并且排名高于 C# 和 Java。

请注意，由于空间限制，该图表中未显示其他语言的缺失标签。你可以在分析表中找到完整列表。

当被问及参与者最喜欢的语言时，Solidity 以 32.7% 的选票位居榜首，略高于去年，其次是 Python (13.9%)、TypeScript (12.8%)、Rust (11.3%) 和 JavaScript (9.9%)。JavaScript 在今年的列表中下降了几位。

但是，列表中其他较少提及的语言的受欢迎程度顺序与去年一致，Go 占 5.2%，C++ 占 3.7%，Java 占 3.2%，C# 占 2.3%，C 占 1.4%。

首选操作系统

大多数参与者使用 macOS 作为其主要操作系统 (43%)，其次是 Windows (29.2%) 和 Linux (27.8%)。

去年发现 Linux 和 Windows 同样受欢迎。

Solidity 背景

在调查的下一部分中，我们收集了有关参与者的 Solidity 特定开发经验和使用习惯的信息。

Solidity 专业知识

几乎 60% 的回复者认为自己是 Solidity 专家，其专业知识的自我评级为 7 或更高（10 分制），其中自我评级为 8 的参与者数量最多。

23.4% 的人对自己 Solidity 专业知识的评分为 10，其中大约 84% 的人使用 Solidity 已超过 2 年。

大约 20% 的回复者仍处于其 Solidity 之旅的开始阶段，自我评分为 4 或更低。

我们询问了参与者使用 Solidity 的时间。几乎 30% 的回复者使用 Solidity 不到一年，其中 10% 的人使用 Solidity 的经验不到三个月。

回复者人数最多 (24.5%) 的是具有 2-3 年 Solidity 经验的用户。

大约 24% 的用户可以被认为是生态系统中的高级人员，因为他们表示他们使用 Solidity 已超过 3 年。

当被问及回复者开始对 Solidity 感到满意需要多长时间时，大多数人 (36.7%) 报告说他们用了不到 6 个月的时间。

17.8% 的人甚至说他们只用了不到一个月的时间。

12.7% 的人需要一年以上的时间才能对该语言感到满意。这个数字略高于去年。

17.4% 的人仍然感到不满意，其中 76.7% 的人仍处于 Solidity 之旅的开始阶段（<=6 个月），45% 的人甚至不到三个月。

Solidity 用户概况和使用习惯

43.7% 的回复者每天使用 Solidity，其次是 32.9% 的人每周使用它，只有 14.5% 的人每月使用它。自去年以来以来，这些数字略有变化，但顺序（每天 > 每周 > 每月）保持不变。

只有 0.9% 的人表示他们从不使用 Solidity，自去年以来进一步减少了 1%。8.1% 的用户表示他们很少使用它。

与往年一样，我们询问了调查对象他们如何获得 Solidity 二进制文件。提及最多的来源按从高到低的顺序排列：

• 通过框架/IDE (38.5%) -0.3%📉
• 使用 npm (16.1%) -2.5%📉
• GitHub Releases (11.1%) -1.5%📉
• 我们今年添加作为选择的 solc-select (7.5%)
• 从源代码构建 (7.1%) -2.2%📉
• Homebrew (5.7%) -0.4%📉
• solc-bin (5.5%) -1.3%📉

其他不太突出的来源包括用于 Ubuntu 的 Ethereum PPA、用于 Linux 发行版的软件包管理器、Dockerhub 和 svm-rs。

在编写 Solidity 代码时，90.1% 的回复者使用 Visual Studio Code 作为其编辑器，今年增加了近 20%。

自去年以来互换了位置，IntelliJ 和 Vim 分别以 3.9% 和 2.4% 的用户数位居第二和第三位。

如下所示，Atom 和 Visual Studio 在此图表中的排名仍然最低。

根据所选的编辑器，我们还询问了回复者他们使用哪些与 Solidity 相关的插件（如果有）。

就像去年一样，“HardHat VSCode”（由 Nomic Foundation 提供）和 Juan Blanco 的“Solidity”扩展被认为是 Solidity 开发者中最受欢迎的。

我们想知道我们的调查参与者使用哪个 Ethereum 特定的开发环境。

今年，Foundry 取代 Hardhat 成为最流行的 Ethereum 特定 IDE，用户比例最高 (51.1%)。Foundry 的受欢迎程度从 2021 年的 1.6% 上升到 2022 年的 30% 和 2023 年的 32%，在 Solidity 社区和整个 Ethereum 生态系统中，获得了越来越多的用户。

Hardhat 今年落后了，有 32.9% 的用户，仍然与去年相当。自 2022 年的结果以来，Hardhat 用户的百分比一直呈下降趋势，当时大约 75% 的回复者报告说他们使用了 Hardhat。

今年另一个有趣的发现是，虽然 Remix 去年紧随 Hardhat 和 Foundry 之后，获得了 25.8% 的选票，并且今年仍然是第三大最受欢迎的选择，但它只获得了总选票的 8%。

Truffle 在此列表中的排名较低，只有 2.4% 的回复者表示使用了它，紧随其后的是 Wake，有 2.1% 的选票。

Ape、Brownie 和 Dapp 今年的用户百分比相同 (0.6%)，这使它们成为列表中其他选项中不太为人所知/使用的选择。

只有 1.3% 的回复者根本不使用任何 Ethereum 特定的开发环境。

今年，我们引入了一些后续问题，以了解这些工具的使用模式。

当被问及调查参与者是独立使用这些工具还是在工作中使用这些工具时，大多数人 (62%) 表示他们独立使用这些工具，而 38% 的人表示他们在工作中使用这些工具。

我们还要求他们从一系列选项中选择他们使用这些工具的目的。以下是我们的发现：

大多数参与者使用它们进行测试 (28.3%)，其次是生产部署 (24.6%)、快速原型制作 (18.6%)、gas 优化 (15.5%) 和 CI/CD 测试网 (12%)。

在表示他们也使用其他 IDE 的 30.9% 的回复者中，45.5% 的人投票支持 Remix，其次是 Hardhat (24.5%) 和 Foundry (18.8%) 作为他们的第二选择。

只有 2.9% 的人投票支持 Truffle，1.9% 的人投票支持 Ape。

与去年类似，0.8.x Solidity 版本仍然是最常用的版本。但是，今年有 88.9% 的回复者表示他们使用编译器的 v0.8.x 版本，与[去年 (81.85%)] (https://soliditylang.org/img/2024/survey/Slide30.png)相比，这是一个显着增加。

请注意，这是一个多响应类型的问题，允许读者选择多个版本系列。

虽然 0.7.x (4.8%) 版本系列的使用份额今年或多或少保持不变，但自之前的调查以来，0.6.x (2.63%) 系列的使用份额持续下降。其余的旧版本很少使用。

⚠️ 重要提醒：请务必经常将你的代码（和编译器）更新到最新的 Solidity 版本。新版本中添加了几个重要的错误修复和安全改进！

Solidity 使用详情

每年，我们通过分析我们关于 Solidity 使用趋势的调查的回复来了解更多关于我们的社区如何使用 Solidity 的信息：

CLI

我们询问了参与者是否直接在命令行上调用编译器二进制文件，76.6% 的人否认了这一点（与去年相比增加了近 17%），而 23.4% 的人确认了这一点。今年这种分布发生了重大变化。

在命令行上使用编译器时，67.1% 的人喜欢 CLI 而不是用于脚本编写的标准 JSON。这个数字比去年高 8.2%。

当被问及 CLI 选项和输出的破坏性更改对回复者来说有多大时，64.7% 的人回答说“可以接受”（与去年几乎相同），16.3% 的人回答说“完全没有破坏性”。

但是，19% 的人认为这些更改具有破坏性，与去年相比增加了近 10%。

旧的 EVM 版本

虽然 26.3% 的总体回复者仍依赖于旧的 EVM 版本，但大多数 (73.7%) 的人声称他们不再需要编译器支持旧的 EVM 版本，自去年以来略有增加。

在那些依赖于旧版本的人中，8% 的人仍然依赖于已弃用的 EVM 版本。自去年以来这个数字呈预期的下降趋势。

ABIEncoderV1

虽然 61.7% 的人未使用 ABIEncoderV1，但只有 3.8% 的人了解它并使用它。34.5% 的人似乎不知道它的存在或它的作用，与前一年相比略有增加。

SMTChecker

74.1% 的总回复者从未使用过 SMTChecker。19.5% 的人尝试过，6.4% 的人经常使用它。你可以在此处了解有关 SMTChecker 的更多信息。

虽然总体使用模式与前几年相同，但今年经常使用的用户的百分比略有增加。

IR 编译管道

今年，我们再次询问了参与者他们是否使用新的 IR 管道进行编译，虽然比去年略低，但仍有 46.4% 的人不知道 via-IR 是什么。多年来，这个数字呈下降趋势，这意味着用户社区对 IR 管道的认识有所提高。

24.4% 的人已经在使用 IR 管道，而 29.2% 的人尚未尝试使用它。去年，我们撰写了一篇关于 via-ir 的解释性博文。阅读它以了解更多关于它是什么以及为什么你应该使用它来编译你的合约。

当被问及哪些问题阻碍用户通过 via-IR 编译其合约时，19.3% 的人将编译时间长标记为原因，18.9% 的人声称它还没有必要或实际用例。

虽然 13% 的人仍在等待 IR 管道成为默认管道，但 11.5% 的人还不确定是什么让他们无法使用它。

更多问题包括稳定性/安全性问题（9%，几乎是去年的一半）、验证/编译失败（6.8%）和文档不足（5.6%）。

当被问及使用 via-IR 管道编译合约代码所花费的时间时，大多数回复者表示花费的时间在 1 到 10 分钟之间，就像去年一样。

一些用户还报告说，可能需要 15 分钟到 50 分钟不等的时间。

请注意，在分析此数据时，应考虑到数据还取决于用户的硬件功能和规范。

元数据发布

当被问及参与者是否在 IPFS 上发布其元数据输出时，我们标记了与去年相比的巨大变化。

67.1% 的回复者表示他们不公布其智能合约的元数据，与去年的 30.3% 相比，这个数字显着上升。

公布其元数据的用户的百分比从 55.2% 下降到今年的 14.9%。18.1% 的人仍然不知道这意味着什么。

Sourcify

当被问及 Sourcify 的使用情况时，17.4% 的所有回复者使用 Sourcify 进行智能合约验证（与去年相比略有增加），而 26.9% 的人声称不使用它。

55.7% 的人不知道 Sourcify 是什么，这与去年非常相似。

今年，与去年相比，通过 Foundry 使用 Sourcify 的用户显着增加 (35%)，其次是通过 Hardhat 使用 Sourcify 的用户 (34.2%) 和通过 Remix 使用 Sourcify 的用户 (14.5%)。12.8% 的人直接通过 Sourcify 使用它。要了解更多关于 Sourcify 的信息，请访问 sourcify.dev。

appendCBOR: false 或 bytecodeHash: none

60.9% 的用户不知道 appendCBOR: false 或 bytecodeHash: none 是什么，而 27.9% 的人知道但不使用它。一小部分（等于 11.2%）的人经常或有时使用它。 使用模式与去年类似。

扁平化合约

48.8% 的受访者不扁平化他们的合约，而 25% 的人会这样做。26.2% 的人不知道那是什么。

大多数扁平化合约的用户提到，他们这样做是为了方便验证 (50%)，其次是手动审查 (27%) 和易于调试 (16.5%)。

其他 EVM 网络

超过一半的受访者 (62.3%) 在 以太坊主网 和 测试网 之外使用 Solidity。

当被问及他们在哪些其他网络上部署智能合约时，相同数量的参与者 (14.6%) 回复了 Base 和 Polygon（前身为 Matic Network）。

其他经常被提及的区块链包括 Arbitrum (14.3%)、Optimism (12.0%)、Binance (8.4%)、zkSync (7.1%)、Avalanche (6.5%) 等，如下图所示。

其他智能合约语言

我们很好奇 Solidity 用户和开发者更喜欢哪些其他智能合约语言，以下是我们发现的：

大多数受访者 (37.9%) 表示他们不使用 Solidity 以外的任何语言。

Yul，一种 Solidity 的中间语言，仍然是除 Solidity 之外使用最多的智能合约语言，有 18.5% 的选民；与去年相比略有下降。

Vyper，一种基于 Python 的 EVM 语言，是除 Solidity 之外使用第二多的语言，占比 14.4%。

除了略有增加外，这一趋势与去年相似。

Cairo (8.8%) 和 Huff (8.1%) 在调查受众中拥有几乎相等数量的用户。

今年我们在列表中添加了一个新的选择，Noir，有 4.3% 的受访者选择了它。

Sway (1.4%) 和 Fe (1.4%) 在列表中共享一个位置。

Solidity 开发者体验

在本期调查中，我们将回顾用户社区的开发者体验。

我们询问了 Solidity 开发者体验的总体改进情况。

66.8% 的受访者普遍认为，在过去一年中有所改善，其中 24.2% 的人甚至认为这是一个重大改进。

只有 1.5% 的受访者认为开发者体验变得更糟。

再次出现的问题

当被问及参与者是否遇到再次出现的问题时，60.7% 的受访者表示，他们在 Solidity 中进行开发时，不会多次遇到相同或类似的问题。

在遇到再次出现的问题的 39.3% 的人中，最常遇到的是堆栈太深问题，其次是调试问题、字节码大小限制和与优化器相关的问题。

ℹ️ 注意： 关于调试问题，我们想提醒你注意 ethdebug 标准开发工作组，这是一项旨在为构建在 EVM 之上的语言定义通用调试数据格式的倡议：ethdebug。

我们鼓励所有从事此类工具开发的开发人员加入该工作组。该小组定期举行双周会议，并通过 ethdebug Matrix 频道 进行协调。

编译器入门

53.8% 的受访者认为 Solidity 编译器的入门体验“还可以”，而 43.6% 的人认为非常容易。

只有 2.6% 的人认为编译器的入门体验“困难”。当被问及是什么让入门变得困难时，一些人提到文档是一个问题。

最喜欢的方面/特性和痛点

25% 的受访者最喜欢 Solidity 与其他编程语言的相似之处。众所周知，该选项在去年的结果中也排名最高。

其他最喜欢的方面包括其简单性 (20.5%)、易于学习该语言 (18.3%) 及其语法 (11.6%)。

一些人还认为静态类型 (10.9%) 和易于阅读 (10.4%) 是最令人喜欢的方面。

今年，21.8% 的受访者选择 mappings 作为他们最喜欢的功能，其次是 20.4% 的人选择 contracts 作为对象。虽然这些功能连续两年以相同的顺序排在最受喜爱的位置，但今年的百分比与去年相比相当低。

Modifiers (15.1%)、带有自定义错误的 require (13.7%) 和 Inline Assembly (9.8%) 也经常被提及。

一些用户报告说，用户定义的类型 (5.8%)、动态数组 (3.9%)、瞬态存储 (3.4%) 以及 using for (2.6%) 是他们最喜欢的功能。

我们再次询问了参与者关于 Solidity 的最大痛点，以下是我们发现的：

堆栈太深错误今年再次排名最高，占总票数的 31.9%，尽管百分比远低于去年，其次是字节码大小限制 (19.6%)、一个新增加的选项，缺少内存优化 (19.6%) 和编译器性能 (10%)。

8.3% 的受访者表示，冗余检查（例如，在已检查的算术中）是他们最大的问题。

略高于 9% 的人选择了“其他”，并指定了一些他们最显着的痛点，例如错误报告和缺乏更好的调试工具。

文档

当被问及参与者是否认为官方文档有帮助时，认为 Solidity 文档有帮助的调查受访者有所增加 (79.8%)，其次是 17.7% 的人认为它有些用处。

只有 2.5% 的人认为他们根本找不到这些文档的用处，与过去一年相比略有减少。

改进的建议最突出的是要求提供更多代码示例，但也要提供更深入的 Yul 和汇编文档、更好的文档内搜索和导航以及总体上更好的 UI/UX。

高影响编译器错误

与往年一样，我们很好奇 Solidity 开发人员是否受到任何高影响编译器错误的影响（codegen 错误已通过 Solidity 博客上的 安全警报 发布）。

虽然 94.7% 的人（与去年非常相似）表示他们没有受到影响，但 5.3% 的人声称他们受到了影响。

以下是受影响的 34 位参与者报告的错误分布（以及受影响的用户数量）：

• AbiEncodeCallLiteralAsFixedBytesBug：6
• VerbatimInvalidDeduplication：6
• MissingSideEffectsOnSelectorAccess：6
• InlineAssemblyMemorySideEffects 6
• KeccakCaching：5
• StorageWriteRemovalBeforeConditionalTermination：5
• DirtyBytesArrayToStorage：4
• SignedImmutables：4
• AbiReencodingHeadOverflowWithStaticArrayCleanup 4
• FullInlinerNonExpressionSplitArgumentEvaluationOrder 3
• DataLocationChangeInInternalOverride 3
• NestedCalldataArrayAbiReencodingSizeValidation 3
• ABIDecodeTwoDimensionalArrayMemory 3
• UserDefinedValueTypesBug 2
• 我不记得了。9
• 其他：1（“在 solidity 0.8.16 中，我在从 mapping 中删除项目时遇到了问题。它没有删除位置，只是将其归零。”）

请注意，上述关于高影响编译器错误名称的后续问题是一个多项选择题。

外部库

与过去几年相比略有上升，大多数调查受访者 (45.5%) 表示他们将外部库用于代理模式、合约拆分等目的，并按提及最多的用例排序。

44.2% 的人报告说他们根本不使用它们，而 10.3% 的人仍然不知道它们是什么或用于什么。

语言设计和即将推出的功能

在调查的下一部分中，我们将带你了解我们从询问参与者关于他们对 Solidity 语言设计更新和工作的想法和参与度中得出的见解。

最受期待的功能

自去年以来，在最受期待的功能方面似乎发生了重大转变，其中泛型从 23.2% 下降到今年的 7.6%。

因此，今年最受期待的更新是消除堆栈太深错误 (18.2%)，其次是 16.9% 的人报告他们期待更好的调试工具。

调查受访者最期待的其他功能按降序排列为：

• Gas 优化 (13.2%)
• 支持十进制数和动态内存数组 (12.2%)
• 可调整大小的动态内存数组 (8.7%)
• EVM 对象格式 (7.7%)

... 以及更多，如下图所示。

关于新功能/改进的反馈

与前两年一样，我们询问了参与者关于 Solidity 中函数式元素的想法，总体反馈仍然相似，只是各个数字略有变化：

虽然大多数 51.7% 的用户认为 Solidity 中的函数式元素（例如 Lambda 函数）很棒，但 14.6% 的人坚持反对它们，33.6% 的人对它们漠不关心。

去年，我们询问了参与者关于 EIP-1153：“瞬态存储”的想法，结果令人大开眼界。

今年，我们再次询问他们是否需要在瞬态存储中使用复杂类型。想要此功能的受访者人数从去年的 40.4% 减半至 20.2%。但是，我们看到表示漠不关心的人数增加至 48.1%，而 31.7% 的人断言他们不需要复杂类型。

我们还为 2024 年的调查在本节中引入了一些新问题。让我们看看我们发现了什么。

当被问及 traits/typeclasses 和继承之间的偏好时，大多数 (37.8%) 的调查对象表示他们不熟悉这个概念，而只有 25.9% 的人投票支持 traits/typeclasses，其余 (36.3%) 的人断言他们更喜欢继承。

我们跟进询问了受访者认为使用 traits 风格系统重写代码库的过程有多困难，范围从 1 到 10。

39.4% 的受访者将其评为中等难度级别 5。总共有 20.6% 的受众将其评为高难度，介于 8 到 10 之间。相反，只有 7.7% 的人将其标记为以 traits 风格系统替换继承的低难度任务。

可以公平地得出结论，大多数人认为这要么是一个重要的过程，要么是一个高度困难和参与的过程。

接下来，我们尝试评估对拥有代数数据类型的兴趣。虽然超过一半 (51.4%) 的受众表示他们对拥有此类数据类型感兴趣，但只有 22.3% 的人仍然不感兴趣。但是，多达 26.3% 的人不知道什么是代数数据类型。这使团队可以考虑在博客上撰写更多相关内容。

我们还很好奇我们的用户是否尝试过使用模式匹配的语言，以及他们是否对在 Solidity 中使用此功能感兴趣。

34% 的人报告说他们以前使用过模式匹配，并且有兴趣在 Solidity 中使用该功能。但是，26.4% 的用户表示他们没有使用过，其次是 20.9% 的用户使用过但不需要该功能，最后是 18.8% 的用户不理解这个问题。

我们询问了受访者关于在 EOF 和遗留 EVM 之间保持 CREATE2 兼容性对 Solidity 中加盐创建的重要性。

虽然大多数 42.6% 的人确认这不会影响他们的工作，但 23.1% 的人仍然认为这对于他们所做的工作至关重要。但是，34.3% 的人表示他们不熟悉这个概念。

作为后续，我们询问了关于在每次合约创建时提供显式 salt 的烦恼程度。

47.3% 的人确认他们对此可能的改变持中立态度，其次是 26.4% 的人保证这根本不会令人烦恼。但是，20.3% 的受访者断言，他们必须在每次合约创建时提供显式 salt 会让他们感到非常烦恼。6.1% 的受众仍然不确定。

语言设计相关工作

我们再次与受访者核实了他们是否曾经或继续参与语言设计工作，以下是我们发现的：

• 超过 85% 的受访者表示他们不参与，因为他们要么太忙、不感兴趣/不合格，要么不知道如何参与。
• 14.8% 的受访者表示，他们通过加入电话会议、论坛讨论或在 GitHub 上提出新功能或语言更改来定期参与语言设计工作。

在 Solidity，我们已经并将继续努力使我们的社区更容易更积极地参与这些讨论，并感到有足够的能力为语言设计决策做出贡献。

Solidity 开发者社区

保持最新

与往年略有不同的趋势是，今年，大多数人报告说，他们喜欢通过关注 Solidity Twitter 或 Mastodon 来了解 Solidity 版本、安全警报和公告，其次是 Solidity 博客。

另一种经常被提及的信息来源是 Solidity GitHub Releases 页面。

有趣的是，大约 21.2% 的人声称没有做上述任何一项。

作为“其他”的一部分，受访者指定了几种基于社区的方式来保持最新：

• Cyfrin Updraft 关于 Solidity 的课程
• “加密货币影响者”/受欢迎的 Solidity 开发者
• Discord 服务器
• 谷歌
• 加密货币 Twitter/社区聊天/Farcaster 频道
• 新闻通讯
• 加密货币博客
• Solidity 文档
• Solidity 网站
• YouTube 上的教程
• Reddit
• VSCode 通知
• “以太坊新闻周刊”新闻通讯

与其他 Solidity 开发者的互动

超过一半（53.8%）的受访者与其他 Solidity 开发者互动，而 31.1% 的人承认他们很少与其他 Solidity 开发者互动。

与去年相比略有增加，该图表中较小的一部分 (17.5%) 根本不与其他 Solidity 开发者互动。

与往年类似，我们希望以一个问题结束调查，以帮助我们了解社区对 Solidity 团队工作的信心。我们询问了参与者是否同意以下陈述：

陈述 1： 我在 Solidity 开发者社区中感到受欢迎。

大多数 42.6% 的受访者同意他们在 Solidity 开发者社区中感到受欢迎，26% 的人有些同意该陈述。然而，超过 6% 的人仍然感到不受欢迎，而 25% 的人不确定他们的感受。

陈述 2： 我对 Solidity 核心团队的工作充满信心。

大约 78.3% 的人完全或有些同意他们对 Solidity 团队的工作充满信心。然而，7% 的调查对象不同意这一陈述。多达 14.6% 的人仍然不确定。

陈述 3： Solidity 团队了解我作为开发者的需求。

大多数 64.8% 的人同意或有些同意上述陈述。虽然 27.4% 的人不知道他们对此有何感受，但 77.3% 的受众普遍不同意。

陈述 4： 我清楚地知道如何向 Solidity 贡献想法或反馈的选项。

今年，多达 28.4% 的人表示他们“不知道”，这意味着他们不清楚如何贡献想法和反馈。

几乎 47% 的调查对象普遍同意，他们清楚如何向团队贡献想法或反馈的选项。然而，很大一部分受众 (24.6%) 也不同意该陈述。

陈述 5： 我正在从 Solidity 团队收到关于在 GitHub 和/或论坛帖子中提出的问题的充分反馈。

多达 50.3% 的受众不知道如何评价该陈述。

虽然 40.8% 的受访者普遍对他们从 Solidity 团队收到的关于他们贡献的反馈和意见感到满意，但总共有 8.8% 的人仍然不同意该陈述。

这种“社区和 Solidity 团队信心排名”的结果与 2023 年的结果非常一致。

我们在调查结束时添加了另一个问题，尽管在响应收集过程的后期，关于与具有大量使用量和/或 TVL 的项目的关联。我们调查了大约 480 名参与者，提出了以下问题：

你是否在一个具有大量使用量和/或由其处理或锁定了大量资金的项目中工作？ 在 480 名参与者中，有 417 名参与者对此做出了回应，其中大多数 45% 的人报告说他们没有从事此类项目，几乎 30% 的人不想分享，大约 25% 的人确认了他们与高使用量/TVL 项目的关联。

致敬！

最后但并非最不重要的一点是，我们要非常感谢大家完成调查并向我们提供反馈。我们希望我们的调查结果继续对 Solidity 生态系统和社区与对我们一样有价值。

我们的目标是继续收集你的意见并改进 Solidity 作为一个开源项目。

要及时了解所有与 Solidity 相关的公告和更新，请确保：

• 在 Twitter 或 Mastodon 上关注 Solidity。

• 加入 Solidity 论坛 中的语言设计讨论，或在那里向我们提供反馈。

• 关注 Solidity 博客 上的公告和安全警报。

• 关注并 ⭐ Github 上的 Solidity 存储库。

• • *

所有图表都可以在此处找到。原始和分析数据可以在此处找到。

• 原文链接： soliditylang.org/blog/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～