diff --git a/2023/w28_Go_Developer_Survey_2023_H2_Results.md b/2023/w28_Go_Developer_Survey_2023_H2_Results.md index 5e4d386..694b7de 100644 --- a/2023/w28_Go_Developer_Survey_2023_H2_Results.md +++ b/2023/w28_Go_Developer_Survey_2023_H2_Results.md @@ -43,23 +43,23 @@ Go 开发者对 Go 生态系统依旧反馈了高满意度。绝大多数受访 我们继续看到，Go 社区中较新的成员更有可能在 Windows 上进行工作，而不是经验丰富的 Go 开发者。我们将这解读为在新开发者加入 Go 生态系统时，基于 Windows 的开发至关重要，而这也是我们团队希望在 2024 年更加关注的一个话题。 -![image-20231217101802712](C:\Users\zhengxm\Documents\notes\Go开发者调查\2.png) +![image-20231217101802712](../static/images/2023/w28/2.png) -![image-20231217101849547](C:\Users\zhengxm\Documents\notes\Go开发者调查\3.png) +![image-20231217101849547](../static/images/2023/w28/3.png) 受访者继续高度关注 Linux 部署。考虑到 Go 在云开发和容器化工作负载中的普及，这并不令人意外，但仍然是一个重要的确认。根据组织规模或经验水平等因素，我们发现了很少有意义的差异；事实上，尽管新手 Go 开发者似乎更有可能在 Windows 上开发，但仍有 92% 的人部署到 Linux 系统上。也许从这个分析中最有趣的发现是，经验丰富的 Go 开发者表示他们部署到更多类型的系统上（尤其是 WebAssembly 和 IoT），尽管目前尚不清楚这是因为这些部署对于新手 Go 开发者来说具有挑战性，还是因为经验丰富的 Go 开发者在更广泛的背景下使用 Go。我们还观察到，近年来 IoT 和 WebAssembly 的使用稳步增长，分别从 2021 年的 3% 上升到 2023 年的 6% 和 5%。 -![image-20231217101920680](C:\Users\zhengxm\Documents\notes\Go开发者调查\4.png) +![image-20231217101920680](../static/images/2023/w28/4.png) 在过去几年中，计算架构格局发生了变化，我们看到这种变化反映在当前 Go 开发者表示他们所使用的架构上。虽然兼容 x86 架构的系统仍然占据了大多数开发（89%），但 ARM64 现在也被多数受访者所采用（56%）。这种采用似乎部分受到了 Apple Silicon 的推动；现在，macOS 开发者更有可能表示他们为 ARM64 而非基于 x86 的架构进行开发（76% 对 71%）。然而，驱动 ARM64 采用的因素并不仅限于 Apple 硬件：在根本不会在 macOS 上进行开发的受访者中，仍有 29% 表示他们在为 ARM64 进行开发。 -![image-20231217102049776](C:\Users\zhengxm\Documents\notes\Go开发者调查\5.png) +![image-20231217102049776](../static/images/2023/w28/5.png) 在 Go 开发者调查受访者中，最常见的代码编辑器仍然是 [VS Code](https://code.visualstudio.com/)（44%）和 [GoLand](https://www.jetbrains.com/go/)（31%）。这两个比例与 2023 上半年略有下降（分别为 46%和 33%），但仍在本次调查的误差范围之内。在“其他”类别中，[Helix](https://helix-editor.com/) 占据了大部分。与上述操作系统的结果类似，我们认为这并不代表代码编辑器使用情况发生了实质性的变化，而是展示了我们在这类社区调查中预期看到的一些变化性。特别地，我们在这个问题上排除了来自 VS Code 的随机抽样受访者，因为我们知道该群体对 VS Code 有很大偏好。然而，这也导致了这些结果每年更容易出现变化。 我们还根据受访者所偏好使用的编辑器，观察了他们对 Go 满意度的水平。在控制经验长度后，我们并未发现任何差异：我们认为人们并不因为使用不同的代码编辑器而更多或更少地享受使用 Go。这并不一定意味着所有的 Go 编辑器都是相同的，而可能反映了人们找到最适合自己需求的编辑器。这表明了 Go 生态系统拥有多样化的不同编辑器，针对不同的使用情景和开发者偏好。 -![image-20231217102238469](C:\Users\zhengxm\Documents\notes\Go开发者调查\6.png) +![image-20231217102238469](../static/images/2023/w28/6.png) ## 技术栈 @@ -67,31 +67,31 @@ Go 开发者对 Go 生态系统依旧反馈了高满意度。绝大多数受访 首先，我们可以有信心地说，Go 是一种面向现代云端开发的语言。事实上，有 75%的受访者在使用与云服务集成的 Go 软件。近一半的受访者涉及到 AWS（48%），几乎三分之一的人在他们的 Go 开发和部署中使用了 GCP（29%）。对于 AWS 和 GCP，使用情况在大型企业和小型组织中均衡。微软 Azure 是唯一一个在大型组织（拥有超过 1000 名员工的公司）中使用可能性明显高于较小机构的云服务提供商；其他提供商在使用上并未因组织规模而有显著差异。 -![image-20231217102455262](C:\Users\zhengxm\Documents\notes\Go开发者调查\7.png) +![image-20231217102455262](../static/images/2023/w28/7.png) 数据库是软件系统中极为常见的组件，我们发现有 91%的受访者表示他们所开发的 Go 服务中至少使用了一个数据库。最常用的是 PostgreSQL（59%），但有双位数的受访者报告使用了其他六种数据库，因此可以肯定地说，并非只有几种标准的数据库供 Go 开发者考虑。根据组织规模的不同，我们再次看到差异，较小组织的受访者更有可能报告使用 PostgreSQL 和 Redis，而较大组织的开发者更有可能使用特定于其云服务提供商的数据库。 -![image-20231217102851910](C:\Users\zhengxm\Documents\notes\Go开发者调查\8.png) +![image-20231217102851910](../static/images/2023/w28/8.png) 另一个受访者报告常用的组件是缓存或键值存储；有 68%的受访者表示他们参与的 Go 软件至少使用了其中一种。Redis 显然是最常见的（57%），其次是 etcd（10%）和 memcached（7%）。 -![image-20231217102912484](C:\Users\zhengxm\Documents\notes\Go开发者调查\9.png) +![image-20231217102912484](../static/images/2023/w28/9.png) 与数据库类似，调查受访者告诉我们他们使用了一系列不同的可观测性系统。Prometheus 和 Grafana 是最常被提及的（都为 43%），但 Open Telemetry、Datadog 和 Sentry 的使用率也都达到了两位数。 -![image-20231217102943491](C:\Users\zhengxm\Documents\notes\Go开发者调查\10.png) +![image-20231217102943491](../static/images/2023/w28/10.png) 如果有人想知道“我们是不是将所有东西都转换成了 JSON？”…… 是的，确实是这样。几乎每位受访者（96%！）表示他们的 Go 软件使用了 JSON 数据格式；这几乎是自我报告数据中最接近普遍的情况了。YAML、CSV 和 Protocol Buffers 也大约被一半的受访者使用，还有两位数的比例使用 TOML 和 XML。 -![image-20231217103018153](C:\Users\zhengxm\Documents\notes\Go开发者调查\11.png) +![image-20231217103018153](../static/images/2023/w28/11.png) 在认证和授权服务方面，我们发现大多数受访者都是基于诸如[JWT](https://jwt.io/introduction)和[OAuth2](https://oauth.net/2/)等标准来构建的基础。这似乎也是一个领域，组织的云服务提供商解决方案与大多数即插即用的替代方案一样受欢迎。 -![image-20231217103103082](C:\Users\zhengxm\Documents\notes\Go开发者调查\12.png) +![image-20231217103103082](../static/images/2023/w28/12.png) 最后，我们有一些不太适合上述分类的其他服务。我们发现将近一半的受访者在他们的 Go 软件中使用了 gRPC（47%）。对于基础架构即代码的需求，约四分之一的受访者选择了 Terraform 作为工具。其他与 Go 一起常见使用的技术包括 Apache Kafka、ElasticSearch、GraphQL 和 RabbitMQ。 -![image-20231217103208810](C:\Users\zhengxm\Documents\notes\Go开发者调查\13.png) +![image-20231217103208810](../static/images/2023/w28/13.png) 我们还研究了哪些技术倾向于一起使用。虽然没有明显类似于经典的 LAMP 堆栈（Linux + Apache + MySQL + PHP）的模式出现在这项分析中，但我们确实确定了一些有趣的模式： @@ -109,7 +109,7 @@ Go 开发者对 Go 生态系统依旧反馈了高满意度。绝大多数受访 对于经验不到两年的 Go 开发者来说，更有可能遇到这些挑战：分别增加到了 59%和 53%。这正是我们希望通过 gonew 原型改进的两个方面：模板可以为新 Go 开发者提供经过充分测试的项目结构和设计模式，初始实现采用符合惯用法的 Go 编写。这些调查结果帮助我们的团队将 gonew 的目标集中在 Go 社区最困扰的任务上。 -![image-20231217105326006](C:\Users\zhengxm\Documents\notes\Go开发者调查\14.png) +![image-20231217105326006](../static/images/2023/w28/14.png) 大多数受访者告诉我们，他们在启动新的 Go 项目时要么使用模板，要么从现有项目中复制+粘贴代码（58%）。在经验不到五年的受访者中，这个比例增加到了将近三分之二（63%）。这是一个重要的确认，表明 gonew 中基于模板的方法似乎符合开发者目前的使用情况，将一种常见的非正式方法与 go 命令风格的工具对齐。这进一步支持了针对项目模板的常见功能请求：大多数受访者请求 @@ -118,13 +118,13 @@ Go 开发者对 Go 生态系统依旧反馈了高满意度。绝大多数受访 这些结果与开发者在前面部分所面临的挑战非常一致。对这个问题的回答也有助于区分项目结构和设计模式之间的差异，几乎有两倍的受访者表示他们希望 Go 项目模板提供前者而不是后者。 -![image-20231217105527148](C:\Users\zhengxm\Documents\notes\Go开发者调查\15.png) +![image-20231217105527148](../static/images/2023/w28/15.png) -![image-20231217105816020](C:\Users\zhengxm\Documents\notes\Go开发者调查\16.png) +![image-20231217105816020](../static/images/2023/w28/16.png) 大多数受访者告诉我们，能够对模板进行更改并将这些更改传播到基于该模板的项目是至关重要的。据我们所知，目前我们还没有与任何具有自制模板方法的开发者讨论过这种功能，但这表明这是未来发展的一个有趣方向。 -![image-20231217105908061](C:\Users\zhengxm\Documents\notes\Go开发者调查\17.png) +![image-20231217105908061](../static/images/2023/w28/17.png) ## 开发者对错误处理的目标 @@ -142,7 +142,7 @@ Go 开发者对 Go 生态系统依旧反馈了高满意度。绝大多数受访 Go 团队没有计划在语言中添加 exceptions，但由于这在实践中是一个常见的请求，我们将其作为一个响应选择包括在内。只有十分之一的受访者表示他们希望能在 Go 中使用 exceptions，而这与经验成反比 — 更有经验的 Go 开发者对 exceptions 的兴趣不及较新加入 Go 社区的受访者。 -![image-20231217110317767](C:\Users\zhengxm\Documents\notes\Go开发者调查\18.png) +![image-20231217110317767](../static/images/2023/w28/18.png) ## 了解 ML/AI 用例 @@ -173,7 +173,7 @@ Go 团队正在考虑新的 ML/AI 技术发展如何影响软件开发的两个 然而，这项调查只是一个在快速发展的研究领域中的数据点，因此最好将这些结果放在适当的背景下进行考虑。 -![image-20231217111047321](C:\Users\zhengxm\Documents\notes\Go开发者调查\19.png) +![image-20231217111047321](../static/images/2023/w28/19.png) ### 将 AI 功能引入应用和服务 @@ -181,7 +181,7 @@ Go 团队正在考虑新的 ML/AI 技术发展如何影响软件开发的两个 > “我想使用 Go 集成 ETL [提取、转换和加载] 部分，以保持一致、稳健、可靠的代码库。” — 拥有 3 到 4 年经验的专业 Go 开发者 -![image-20231217111115418](C:\Users\zhengxm\Documents\notes\Go开发者调查\20.png) +![image-20231217111115418](../static/images/2023/w28/20.png) ## 工具链错误信息 @@ -197,9 +197,9 @@ Go 团队正在考虑新的 ML/AI 技术发展如何影响软件开发的两个 我们希望在 2024 年专注于改进工具链的错误消息。这些调查结果表明，这是所有经验水平的开发者都感到沮丧的地方，尤其有助于让新手开发者更好地开始使用 Go。 -![image-20231217111400437](C:\Users\zhengxm\Documents\notes\Go开发者调查\21.png) +![image-20231217111400437](../static/images/2023/w28/21.png) -![image-20231217111638468](C:\Users\zhengxm\Documents\notes\Go开发者调查\22.png) +![image-20231217111638468](../static/images/2023/w28/22.png) 为了了解这些消息如何可以改进，我们向调查受访者提出了一个开放式问题：“如果您可以许一个愿望并改进 Go 工具链中的一个错误消息，您会改变什么？”。回应基本上符合我们的假设，即良好的错误消息既易于理解又可操作。最常见的回应是某种形式的“帮助我理解导致此错误的原因”（36%），21%的受访者明确要求提供解决问题的指导，还有 14%的受访者提到诸如 Rust 或 Elm 等语言，因为它们努力做到了这两点。一位受访者说道： @@ -211,7 +211,7 @@ Go 团队正在考虑新的 ML/AI 技术发展如何影响软件开发的两个 > > “通过`go help run`获取帮助时，会显示一大堆文本，带有链接到进一步阅读以查找可用命令行标志的链接。或者它了解`go run –help`，但不是显示帮助，而是说‘请使用 go help run’。只需显示`go run –help`中的标志列表。” — 拥有 3-4 年经验的专业 Go 开发者 -![image-20231217111700700](C:\Users\zhengxm\Documents\notes\Go开发者调查\23.png) +![image-20231217111700700](../static/images/2023/w28/23.png) ## 微服务 @@ -219,51 +219,51 @@ Go 团队正在考虑新的 ML/AI 技术发展如何影响软件开发的两个 大多数受访者表示他们主要开发微服务（43%），还有四分之一的受访者表示他们同时开发微服务和单体应用。只有约五分之一的受访者主要开发单体式的 Go 应用程序。这是我们看到根据受访者所在组织规模而有所不同的少数几个领域之一——大型组织似乎更有可能采用微服务架构，而不是较小的公司。大型组织（>1,000 名员工）的受访者中，最可能表示他们在开发微服务（55%），而仅有 11%的这些受访者主要从事单体式应用程序的开发。 -![image-20231217111941582](C:\Users\zhengxm\Documents\notes\Go开发者调查\24.png) +![image-20231217111941582](../static/images/2023/w28/24.png) 在 Go 平台中，我们看到微服务数量存在一些分歧。一组是由少数（2 到 5 个）服务组成的（40%），而另一组是更大的集合，至少包含 10 个组件服务（37%）。微服务的数量似乎与组织规模没有相关性。 -![image-20231217112037815](C:\Users\zhengxm\Documents\notes\Go开发者调查\25.png) +![image-20231217112037815](../static/images/2023/w28/25.png) 绝大多数受访者使用某种形式的直接响应请求（例如 RPC、HTTP 等）进行微服务通信（72%）。较少的比例使用消息队列（14%）或发布/订阅方法（9%）；同样，我们在这方面没有看到与组织规模有关的差异。 -![image-20231217112111719](C:\Users\zhengxm\Documents\notes\Go开发者调查\26.png) +![image-20231217112111719](../static/images/2023/w28/26.png) 大多数受访者在构建微服务时使用多种语言，只有约四分之一的人完全使用 Go。Python 是最常用的辅助语言（33%），其次是 Node.js（28%）和 Java（26%）。同样，根据组织规模存在差异，较大的组织更有可能集成 Python（43%）和 Java（36%）微服务，而较小的组织更有可能仅使用 Go（30%）。其他语言在组织规模方面似乎使用相同。 -![image-20231217112143892](C:\Users\zhengxm\Documents\notes\Go开发者调查\27.png) +![image-20231217112143892](../static/images/2023/w28/27.png) 总体而言，受访者告诉我们，在编写基于微服务的应用程序时，测试和调试是他们面临的最大挑战，其次是操作复杂性。许多其他挑战在图表中占据了较长的尾部，尽管“可移植性”对大多数受访者来说并不是问题。我们理解为这样的服务并不打算可移植（除了基本的容器化）；例如，如果一个组织的微服务最初由 PostgreSQL 数据库支持，开发人员并不担心将来可能将其转移到 Oracle 数据库上。 -![image-20231217112222563](C:\Users\zhengxm\Documents\notes\Go开发者调查\28.png) +![image-20231217112222563](../static/images/2023/w28/28.png) ## 模块的创作和维护 Go 拥有一个充满活力的由社区驱动的模块生态系统，我们想了解维护这些模块的开发人员所面临的动机和挑战。我们发现大约五分之一的受访者维护（或曾经维护过）一个开源的 Go 模块。这个比例让人惊讶地高，可能是由于我们分享这份调查的方式造成的：模块的维护者可能更有可能密切关注 Go 博客（这里发布了这项调查）而不同于其他 Go 开发人员。 -![image-20231217112308089](C:\Users\zhengxm\Documents\notes\Go开发者调查\29.png) +![image-20231217112308089](../static/images/2023/w28/29.png) 模块的维护者似乎在很大程度上是自我激励的 — 他们表示在个人（58%）或工作（56%）项目中需要这些模块，他们之所以这样做是因为他们喜欢从事这些模块的工作（63%），并且喜欢成为公共 Go 社区的一部分（44%），他们从模块维护中学到了有用的技能（44%）。更多的外部动机，比如获得认可（15%）、职业发展（36%）或金钱回报（20%），在名单的底部。 -![image-20231217112417233](C:\Users\zhengxm\Documents\notes\Go开发者调查\30.png) +![image-20231217112417233](../static/images/2023/w28/30.png) 维护模块的内在动机形式显示出，模块维护者面临的一个关键挑战是找到时间来专注于他们的模块（41%）。虽然这似乎不是一个可操作的发现（我们不能为 Go 开发人员多增加一两个小时，对吧？），但这是一个有益的视角，用来看待模块的工具和开发 — 这些任务很可能在开发者已经忙于其他事情的情况下进行，也许已经过去了几周或几个月，因此他们的记忆已经不新鲜了。因此，易于理解和操作的错误消息等方面可能会特别有帮助：与其要求某人再次搜索特定的 go 命令语法，也许错误输出可以直接在终端提供他们所需要的解决方案。 -![image-20231217112455280](C:\Users\zhengxm\Documents\notes\Go开发者调查\31.png) +![image-20231217112455280](../static/images/2023/w28/31.png) ## 工作信息统计 大多数调查受访者表示他们主要工作中使用 Go（78%），而且多数（59%）称他们在个人或开源项目中使用 Go。实际上，受访者通常在工作和个人/开源项目中都使用 Go，有 43% 的受访者表示他们在这两种情况下都在使用 Go。 -![image-20231217112558356](C:\Users\zhengxm\Documents\notes\Go开发者调查\32.png) +![image-20231217112558356](../static/images/2023/w28/32.png) 绝大多数受访者使用 Go 语言的时间不超过五年（68%）。和之前的调查相比，通过 VS Code 渠道发现此次调查的人员往往经验较少。 针对不同经验水平的受访者使用 Go 的情况，有两个显著的发现。首先，各经验水平的受访者中，大多数表示他们在专业领域使用 Go；事实上，对于那些有超过两年经验的人，绝大多数都在工作中使用 Go（85% - 91%）。类似的趋势也存在于开源开发中。第二个发现是，相较于经验更丰富的 Go 开发者，经验较少的开发者更有可能使用 Go 来扩展自己的技能（38%），或者在工作中评估它的使用情况（13%）。我们解读这一发现意味着，许多 Go 开发者最初将 Go 视为“技能提升”或拓展其软件开发理解的一部分，但在一两年内，他们更多地将 Go 视为一种实际应用工具而非学习工具。 -![image-20231217112738341](C:\Users\zhengxm\Documents\notes\Go开发者调查\33.png) +![image-20231217112738341](../static/images/2023/w28/33.png) -![image-20231217112927644](C:\Users\zhengxm\Documents\notes\Go开发者调查\34.png) +![image-20231217112927644](../static/images/2023/w28/34.png) Go 语言最常见的使用情景仍然是 API/RPC 服务（74%）和命令行工具（62%）。人们告诉我们，选择 Go 用于这些类型的软件有几个原因，包括其内置的 HTTP 服务器和并发原语、跨平台编译的便捷性，以及单一二进制部署的简易性。 @@ -271,13 +271,13 @@ Go 语言最常见的使用情景仍然是 API/RPC 服务（74%）和命令行 我们还根据受访者在 Go 使用经验和组织规模上的不同来寻找差异。更有经验的 Go 开发者表示他们在 Go 中构建了更多不同类型的应用和服务；这种趋势在每个应用或服务类别中都是一致的。根据组织规模，我们并未发现受访者在构建的应用和服务方面有明显的差异。 -![image-20231217112946280](C:\Users\zhengxm\Documents\notes\Go开发者调查\35.png) +![image-20231217112946280](../static/images/2023/w28/35.png) -![image-20231217113036351](C:\Users\zhengxm\Documents\notes\Go开发者调查\36.png) +![image-20231217113036351](../static/images/2023/w28/36.png) 受访者在首次回答 Go 开发者调查和之前参与调查的比例大致相同。通过 Go 博客了解本次调查的人中，有 61% 报告曾经参与过此项调查，而通过 VS Code 的通知了解本次调查的人中，只有 31% 表示之前曾参与过。我们并不期望人们完美地记得他们在互联网上参与过的每一项调查，但这让我们对于每次调查都能听取到新旧受访者的均衡意见感到有些信心。此外，这也告诉我们，结合社交媒体发布和编辑器随机抽样对于听取到多元化的 Go 开发者意见是必要的。 -![image-20231217113107813](C:\Users\zhengxm\Documents\notes\Go开发者调查\37.png) +![image-20231217113107813](../static/images/2023/w28/37.png) ## 组织的特征和特性 @@ -285,11 +285,11 @@ Go 语言最常见的使用情景仍然是 API/RPC 服务（74%）和命令行 这与过去几年的 Go 开发者调查数据统计基本保持不变——我们继续听取来自不同国家、不同规模和行业的人们的声音，比例保持了一致。 -![image-20231217120123708](C:\Users\zhengxm\Documents\notes\Go开发者调查\38.png) +![image-20231217120123708](../static/images/2023/w28/38.png) -![image-20231217120210172](C:\Users\zhengxm\Documents\notes\Go开发者调查\39.png) +![image-20231217120210172](../static/images/2023/w28/39.png) -![image-20231217120226631](C:\Users\zhengxm\Documents\notes\Go开发者调查\40.png) +![image-20231217120226631](../static/images/2023/w28/40.png) ## 调查方法 @@ -311,7 +311,7 @@ Go 语言最常见的使用情景仍然是 API/RPC 服务（74%）和命令行 > > “请保持 Go 与早些时候确定的长期价值观一致 —— 语言和库的稳定性。[……] 这是一个我可以依赖的环境，它不会在 2 到 3 年后破坏我的代码。为此，非常感谢。” — 有 10 年以上经验的专业 Go 开发者 -![image-20231217120430504](C:\Users\zhengxm\Documents\notes\Go开发者调查\41.png) +![image-20231217120430504](../static/images/2023/w28/41.png) 以上就是 Go 开发者调查的全部内容。感谢每一个分享他们对 Go 的反馈的人，我们非常感谢你花时间帮助塑造 Go 的未来，我们希望你能在这份报告中看到你自己的一些反馈。🩵