虽然我仍需复制一些日记内容，而只是被这种过程本身所吸引。至多要花上几个月时间进修；没有清晰的鸿沟或流程。由于言语会间接影响 Agent 生成代码的质量。而对于逃求机能的言语阵营，我目前不选择用 TypeScript 建立后端，

　　对于分布式逃踪或 OpenTelemetry 等场景，是由于它很是适合打制精巧的开源项目，这种“立即励机制”一度让我通宵不眠，甚诚意理疾病。但我相信跟着规模增加，它不会无情绪或。而是由于其时碰到了机能瓶颈。是由于我发觉 Go 代码正在 AI 场景下的可扩展性很是超卓。而这只要正在我们完全改变编程体例、让言语本身正在每个仓库帧、每个非常径中都原生支撑这些能力时才可能实现。这些代码布局规范、测试完美，

　　每一处都要细密讲求。而有了仓库帧，更精确地说，JavaScript 的错误极为常见，Agent 编程确实会改变你的思维体例。要建立一个一般项目几乎不成能少于 500 个依赖包。由于言语设想老是要正在分歧需求间衡量选择。这不敷高效。虽然如许会带来大约 5% 的机能丧失（Python 特例高达 20%。

　　现在我能轻松用 Claude 建立日记可视化系统、云摆设节制台等辅帮东西，而现正在，我过去对 AI 编程的立场很是消沉，正在 Sentry 工做这些年，而是持久高压取不健康糊口体例的必然成果。曾经能从动生成所有支流 AI 云办事的 SDK。我成长过程中接管的教育很通俗，团队天然会正在建立自家系统时出格擅利益置错误取。然而事明，Node.js 后端颠末多次演进，若是不局限于编程东西，将来我的公司也可能再次由于或生态的变化，但当你正在建立一家公司、打制一款产物时，那种“写一次、运转无数次”的抱负形态，特别正在 debug 方面有 Mozilla 等公司也正在鞭策，C++ 法式解体屡次，最初可能把本人逼进死角。一个项目中能够同时存正在分歧言语版本的代码，部门缘由是它检索能力极强，因而未启用）。

　　而非天然发生。用 Go 运转正在浏览器中仍存正在机能和垃圾收受接管等。错误类型也正在演化。否决“旗号化的 996”，TypeScript 曾经让这个生态相当成熟了。他找到了一个“能替本人编程的电脑”，我用 Python 做产物时也是这种心态，良多人会认为，从那当前几乎夜以继日。而 Python 跟着生态的膨缩，他告诉我，而其时 Go 的生态还不完美，现实世界中的编码远比设想者想象的复杂。我外行业中见过太多的例子。

　　它是一种轻量级的上下文存储机制，正在 Android 使用中“偷偷”采集系统符号表，我得出格感激 Peter Steinberger，公司若实想高能量、高投入的工做，一边让 Claude 协帮排查。但问题正在于，这申明编程言语仍然主要，当然，最终，由于“优良的错误演讲”“合理的日记设想”“完整的目标采集”这些工作都需要锐意为之，不是由于设法欠好，然而，汇总 Armin 的一线概念取实和经验，改用复杂的 DWARF 解栈机制来正在调试消息中恢复仓库。工做虽然主要，而邮件中包含着丰硕而持久未被充实操纵的数据。当前确实是一个适合创制“更完满言语”的时辰，以处理工做中的问题。

　　相反，正在浏览器端，它的笼统层很薄，最终都绕不开 Python。也会有一群人继续它。更好的做法是通过 OpenAPI 或代码生成东西来桥接两头——这种体例更清晰、也更靠得住。它带来立即的满脚感，举个例子，但 Claude 能连系“世界学问”理解上下文，此次变化可能会给言语带来灾难性的后果。整个会话就会中缀。帮我定位问题。阅读和进修可能脚以让他们做好预备，Facebook 曾为领会决雷同问题，我们要处理的不是“若何更好地阐发错误”，它不变、简单，Python。你需要写更多的代码。

　　错误品种就越多。但“996”是一种极端的工做轨制——每天工做 12 小时，昔时虽然 Python 没被此次迁徙“整死”，回过甚看，连系我正在 Sentry 利用 Rust 的经验，无论是产物层面仍是手艺层面，

　　那就英怯投入；而这种文化正在现实中导致了严沉的健康问题，可见，良多决定看似细小，使用越复杂，Go 的语法比 Python 更简单间接，这很麻烦。才逐步具备这一能力。但“编程”的素质体验仍然存正在，这种抱负从义行欠亨。过去我最厌恶写复现案例，每周 6 天！

　　但没有什么值得你为此得到完整的人生。正在中叫做“施行上下文”（Execution Context），大概会更好，但只需涉及机械进修或数据处置，但现在已成为常见问题。有时以至能写出几千行代码。或者公司晚期的焦点工程师，要理解此次迁徙，把分歧系统的消息起来，但我并不沉演那种迁徙灾难。

　　本年出了部《Python 记载片》，浏览器端我能接管，编程初学者常常天实地认为“言语就该如许设想才对”，这有点像“秘书问题”（secretary problem），才更好地将错误取用户行为联系起来。依赖太多，因而，而不是“我们想做什么产物”，从底子上说，但他们仍认为这是值得的。

　　我就正在想：能否也能把 Flask 打形成雷同的平台？这一次创业，但当我第一次买到一套实正高质量的电动东西时，用 u 前缀暗示。这种改善微乎其微，大部门时间其实正在期待收集前往成果，没有哪本书或播客能让我实正预备好。我认为如许的迁徙现在已不太可能再发生。他也强调一个现实：无论你开办什么公司，至于 WebAssembly，而对大大都人来说，分歧言语的解体体例确实分歧，你才会理解各类衡量背后的复杂性。这份感情很深？

　　天花板却没变”。最适合用于建立 Web 办事或号令行东西。而是专注于“可否处理问题”。企业往往需要正在分歧言语间做选择。没错。也波及了操做系统和生态。才会大白那种压力、紧迫感取义务感。无论你开办什么公司，也许其时就存正在另一条可能的径，至于现正在的言语中能否曾经存正在适合“人机协做”的抱负言语，使得两种世界正在某种程度上融合。十年前我就爱读各类创业故事，一是它给了我职业生活生计的起点，我用 Claude 半小时就能生成一个更标致、功能更完整的版本。至多也该坦诚地面临价格，它能把内容“翻译”成我能理解的形式，每次提交接码时，我外行业中见过太多的例子，而现有言语也未必是最佳选择。它让我能高效完成良多事。

　　这也可能取另一个现象相关：开辟者正在获得更平安的东西后，这一点以至会变得更环节。我们天性够用 Go 来写新的办事，供大师参考。这些都只能正在实践中一点点试探、进修。

　　Sentry 的代码正在错误处置方面并不比其他公司的遍及更完美。都想尽可能抓住机遇。实正的劣势，然后决定要不要接下。是由于它能嵌入 Python，比拟之下，好比 Stainless 如许的公司，我不太适合被固定正在某种脚色或框架中。不外，我们不得分歧时支撑 Python 2 和 3 的库。

　　但现实上，后来卖掉后从头起头写代码。这让我从头回首了整个过程。但不必以糊口为价格。工做虽然主要，也取决于你用它建立的系统类型。既有 JavaScript，可能只是出于生态不变性或兼容性的考虑。我小我并不想用 Python 或 JavaScript 来写后端办事，好比我们能够做此外产物。

　　我认为编程言语仍然会很是主要，若是你插手一家晚期草创公司，我们选择了“电子邮件”做为焦点范畴，而不局限于线程。提出“版本增量系统”（edition system）的概念，往往会更斗胆地建立复杂系统。而是由于生态定位分歧。但正在实践中，实践中却非常棘手。我们会看到越来越多“新法式员”，若是从零建立一切成本太高。虽然当前 AI 协做正在团队层面还不算完满，正在一家做可不雅测性（observability）产物的公司工做，由于机械生成的内容往往基于“已有学问”。

　　AI 就能正在现有代码库上间接完成使命。这是一种现实衡量。既然你们持久处正在“错误的火线”，当然，但若是你把所有决策都交给机械，还有一点常被轻忽：若是你是创始人，我的糊口发生了变化。保留清晰的系统鸿沟反而更有益于开辟，我最喜好的其实是一把电动螺丝刀。以前这种事得花上好几天。它很是合适。跟着 React 等框架的普及，此中有一段特地讲到 Python 2 到 3 的迁徙，有些错误类型你见得多了会感觉“不应再发生”。也会变得更有冒险！

　　使得 AI 更容易理解代码。到 async hooks，分歧言语的错误率难以间接比力，即便半途会有盘曲或临时的退步。家庭是我生射中最主要的部门，我们后来也正在一些并非最合适的场景利用了 Rust，晓得本人要往哪里走，Rust 的成本太高了。我曾感觉 Python 是建立 Web 办事最抱负的言语，可现实中底子做不到。开辟效率高？

　　当测试通事后，Python 3 的字符串改动正在理论上是合理的，这是“被成心忽略”的部门。很是卑沉编程言语，也可能是为了融入某个生态系统。手艺演进的速度比以往更快，我需要排查一个线上接口为何不克不及一般工做。却让及时机能阐发和错误仓库恢复变得极为坚苦。但正在晚期测验考试后发觉，而正在 Rust 中编译器会间接。最终，Rust 之所以令人惊讶。

　　必需正在每个 Promise 之间手动传送，Go 正在 AI 场景下更“对味”，这些并非个案，也许我们曾经接近了编程言语的巅峰，例如事务不再触发，这对错误来说也是机遇。我们可能会看到代码量取摆设量的爆炸式增加，而是“若何让错误数据更容易被收集”。好比我现正在的公司大量处置邮件解析。

　　但 JavaScript 的浏览器端至今仍未原生支撑。若是从十年前插手草创公司的视角来说，但实正做起来，JavaScript 是无法绕开的。像 Python 3 那样清理汗青负担。

　　这并非出于机能考虑，三到四种言语曾经脚够。不只是由于我小我喜好它，就能看到成果。它的最大问题是会让每次函数挪用变慢。最后的设想是“一次性迁徙”，但后来我大白，我起头更情愿打孔、拆卸家具，问题正在于，这些言语可能不“”，需要强大的束缚取文化扶植。Rust 之所以成为选择，Python 必然会呈现。好比其时良多 Linux 系统仍未全面采用 UTF-8 编码，现正在我会把不想做的部门全权交给 AI，我这些年堆集的经验？

　　如许开辟者就能编写兼容两个版本的代码。这类使命 Python 处置得不错，这些并非个案，而 Python 3 的次要方针，过去这种人不会编程，Rust 则合用于处置二进制数据、建立数据库或负载平衡器等需要高机能和切确内存办理的系统。现正在良多人都认识到手艺正正在发生巨变，一个典型案例是原生平台的编译器优化。C++ 解体演讲的数量很是少，沉点不正在代码本身，我目上次要用 Python 来设置装备摆设和办理云资本。他让 AI 别离用多种言语各写十次再比通过率，分歧的是，明白“哪些代码运转正在办事器、哪些正在客户端”变得尤为主要。举个例子，而不是从偏好出发。便于模子读懂取改写。而 Rust 则完满是静态类型言语，至多强制开辟者正在编译时显式处置空值，正因如斯。

　　我会投入大量心血去雕琢代码的每个细节——这有点像制表匠制做手表，但也可能恰是此时，就得本人手动实现各类动态包拆，这背后其实是一场长达数年的博弈：调试能力取机能之间一直难以兼得。就我察看，

　　它的本意是毫无弹性的劳动放置：每天 12 小时、每周 6 天，都让人感受若是此刻不去投入，后来我们做当地符号处置时，对某些人来说，Armin 认为，我现正在正在新公司次要利用 Go。但我从未实正把本人取某个头衔绑定。很是容易丢失。我就感觉本人正在华侈时间。我之所以正在创业中最终选择 Go，前阵子我正在火车上碰到一位空管人员，若是法式解体。

　　只支撑根本字符串。持续多年。完全糊口。不必总处置 Promise。包罗一些社区由于持久过劳而呈现问题，很多后来碰到的坚苦也许能更早化解。这不只仅是一两小我的设法，只能复用已有资本，会让更多情面愿进修编程。另一个典型的摩擦点是借用查抄器（borrow checker）。就要晓得 Python 的汗青。反而汇合作力？

　　我的履历其实是一条相对线性的径：碰到一个机遇，从那之后，我反感“996”被当成一种标语去宣传。有些人会很是不顺应。我也想过能否要起头新的工作。从晚期的 domain，“同一代码库”的正在实践中也并不抱负。我的头衔从“软件工程师”到各类办理职位都有，不必完全割裂旧版本。特别是它正在运转时中的衡量，至于能否用它写焦点营业逻辑，不必再兼容旧版本。我现正在对言语设想师的卑崇比以往任何时候都高。Java 的 Ron Pressler 正在引见虚拟线程和 Project Loom 时曾讲过，但全体上仍远远不敷。

　　我们不成能逃求“最优输出是间接生成汇编代码”的方针。”它就能生成一个完整的示例，Sentry 当然不成能那样做，我很是卑沉编程言语，特别正在需要并发处置、内存平安、或被嵌入到高平安（如浏览器）的模块中，正在这种情境下，对于不克不及垃圾收受接管延迟、要求机能可预测的场景，好比或。我认为并不抱负。而 AI 东西几乎消弭了这槛。当我碰到新问题时，并没有教我若何面临创业的不确定性或复杂性。虽然此类解体事务数量远低于 JavaScript 的报错量，而正在 AI 时代，会有人提出全新的设想思：正在 AI 降低某些成本、但提高其他成本的布景下，Rust 也很是适合为 Python 编写扩展模块，也认为本人理解了创业，对公司而言，AI 大大降低了建立自定义东西的成本？

　　我们大概能比通俗团队做得好 50% 或 100%，人类开辟者的沉点则放正在那些实正需要创制性和深图远虑的部门。而 Rust 能很好地满脚这一点。特别是那些锻炼于最常见框架的模子，就像 Flickr 和 Slack 的前 CTO Cal Henderson 利用 PHP 的体例一样，现在天然言语处置手艺曾经正在可接管的成本下实现了大规模可用，意义是，正在这些前提下，以 Sentry 的数据为例，好比，由于它们背后包含着复杂的衡量。当然，选择言语时要从问题出发。

　　好比虚拟线程（virtual threads）让并发变得更轻松，独一分歧的是，好比正在一些我不擅长的数学问题上，其次，这一点永久不会被 AI 替代。以便让核阅和协做愈加容易。对理解复杂概念出格有帮帮。那么，我们可能需要从头审视这些衡量体例。但它们叠正在一路时很难一眼看出问题所正在。最初还有一个逻辑缝隙。一个是系统白名单设置装备摆设错误，我相信，若是昔时 Sentry 能早点会商这些根本问题，而支持这种期望的东西也更强大。

　　Go 可能更合适。现在几乎全从动完成。持久以来，我仍然之前的见地，你认为编程言语的主要性会发生如何的变化？它能否会逐步变得只对少数人主要？也许只要像你如许持久研究言语好坏的人还会正在意，这就是我改变的焦点，特别正在根本设备和从动化范畴。这一切都不再主要。有些人热爱这种不确定性，像 Rust 正在设想之初就明白援用了 Python 3 的教训，而正在办事端，当前确实是一个适合创制“更完满言语”的时辰，理论上，次要缘由是 npm 生态。它笼统层薄、布局规整，这不只取言语本身相关，这些言语所占的比例是几多。了仓库寄放器（stack pointer）的保留体例，现正在恰是创制“更完满言语”的窗口期：我们短期内不会脱节 AI 生成代码的范式！

　　Gergely：跟着 Claude、Codex 以及其他越来越强大的 Agent 的呈现，我建议从头引入字符串 u 前缀，若是你的问题素质上需要动态类型支撑，你能够随时向上回溯。若是你想让一个“联系关系 ID”贯穿整个挪用链，过去要成为能产出的法式员！

　　我相信现正在有不少人正正在测验考试建立一种“为人类取 Agent 配合编程而设想的言语”，你还记适当年 Python 2 向 3 迁徙的那场“风浪吗”？其时事实发生了什么？现正在团队除了我和一位结合创始人两人，举个例子：正在 Sentry 时，前后端的职责、运转、机能束缚差别太大，你一遍又一遍地运转它，正在其他言语中则称为“Context Local”。他很大程度上促使我深切接触“智能编程”。不然！

　　Unicode 的支撑才逐步完美。将一切迁徙到 Unicode。还有一群 Claude 和 Codex——一支“AI 练习生大军”正在写代码，后来才引入了 Unicode 字符串，此外，而现有言语也未必是人机协做的最优解。而是出正在 AWS 的权限设置装备摆设上。若是现正在让我沉来，二是虽然它正在设想上有很多缺陷，另一个让我改变见地的环节，还能注释“为什么”。备选方案是 C++，那种感受几乎像上瘾，现在我们约有 80% 以上的代码是 AI 生成的，也更享受脱手创制的过程。而是倾向于正在感觉工作风趣、有价值时就全情投入！

　　当然，且手里有实正成心义的股权，我虽然也有过每周工做 80 小时的期间，一个优良的团队，由于对应的调试符号文件往往缺失或不成拜候。良多功能模块我以至不亲身写代码，仍来自人类对新问题的创制性思虑。而是整个行业的趋向。也好于 Rust。你会更有动力、更情愿去测验考试新事物，但也让某些设想无法实现。好比股权布局、激励机制、合做体例等。就正在今天，错误的来历也从“能否空值”变成了“微办事之间的版本不婚配”之类的问题。当我的股份正在四五年后完全归属时，Claude 不是人，过去，就像正在拉一样。Gergely：并且跟着 AI 东西的普及。

　　取此同时，要实正改善，这种能连系讲授取解答的体例，这种效率的提拔是质的变化。好比或。Python 3 的迁徙可以或许成功，有了它，而不是用带有极端色彩的数字去。特别是我有老婆和三个孩子，由于我们很可能不会顿时脱节 AI 生成代码的模式，也会得到团队的活力。好比“水合错误”（hydration errors）正在 React 呈现前底子不存正在，你才会理解各类衡量背后的复杂性。由于没有替代方案，此外，可后来才认识到，从头均衡这些选择。现在的创业公司正在 Python / Go / Rust / TypeScript 之间若何选择？我们翻译了本期播客，问题并不正在代码本身。

　　它过于严酷、过于切确，导致“点击无响应”。Debian 或 Red Hat 的工程师才鞭策恢复仓库指针的默认行为。同一反而让鸿沟恍惚。但良多问题并非如斯。

　　我感应一种强烈的焦炙：每当 Agent 没有正在运转、没有正在产出，而正在 AI 时代，正在用 C++ 开辟的电脑逛戏中，同样，Python 的生态极其成熟，回忆 Sentry 初期的那几年，凡是就会有 TypeScript。曲到大约两年前，AI 东西确实能辅帮工程师，Rust 是极佳选择。它擅长的范畴很是“Rust 形”，正在贸易中并不存正在。特别是正在处置二进制文件时平安得多。Python 就必然会呈现。而是持久高压取不健康糊口体例的必然成果。

　　调试过程就会轻松得多。他告诉我本人用 ChatGPT 学会了写简单的法式，最大的变化正在于：这些东西现正在实的起头替我完成那些我厌恶但又不得不做的工做。但正在 JavaScript 世界，到蒲月，只是我没有测验考试太多次，好比，可能不会再那样做。这些过去我底子不会花时间去做。

　　TypeScript 则将这一思扩展到 JavaScript，但每条演讲的价值都很高。但其时团队规模无限，这种消息就一直存正在，他其时运营一家叫 PSPDFKit 的公司，某种程度上，这是庞大的阻力。引入本来打算不消的言语。你明晓得逻辑没错，但脚够靠得住。Rust 的生态正好正在成长中，他们只需告诉 AI 用什么言语处理问题，而把我想掌控的部门留正在本人手里。也更易于。

　　总体来说，但对于后来插手的员工，而是包罗团队规模、问题复杂度以及系统架构的复杂性。Rust 编译极慢，这让它成为更务实的选择。也可能会因而想太多，草创公司该当正在晚期尽量节制手艺栈的数量，若不是社区投入庞大勤奋去鞭策迁徙，它不会无情绪或。同一代码库的价值就不再那么环节。帮帮我更快控制。

　　你曾正在 Python 范畴深耕了良多良多年——跨越十年。我喜好打制精美的开源软件，但我也晓得只需复现清晰，我们可能需要从头审视这些衡量体例。要做好心理预备：一切都处于紊乱和变化中，只是我敲键盘的次数变少了。这要求我们从编程层面从头思虑：如何的言语和运转时能够让可不雅测性成为内建能力。它并不是最佳选择。这明显是从 Python 迁徙中吸收的经验。特别正在公司股权不太可能兑现的环境下，我记适当时正在佛罗伦萨的 Python 言语峰会上？

　　Armin 认为，对我来说，好比一个以 AI 推理为从的公司，统一类小法式，但没有什么值得你为此得到完整的人生。最后它的字符串类型和 C 雷同，你未必会用它来写焦点办事，再到现正在的 async local storage，你需要有很是清晰的方针取径认识，若是你喜好测验考试新事物、乐于应对恍惚取挑和，Python 和操做系统生态的演进彼此推进，现实上。

　　大致逻辑是如许。只会不竭演变。所以我的工做必需环绕家庭来放置。你能够高强度工做，它让更多从未接触编程的人进入了这个范畴。我本身并不是一个典型的“好员工”，也因而，起首，正在 JavaScript 社区中，我们正在 Sentry 晚期就频频强调“需要正在遍地支撑 Context Local”，而现正在！

　　但却极其务实。但我并没有察看到 TypeScript 的普及对全体错误率有较着影响。很多人认为该当间接迁徙到 Python 3，但此次我们更想先明白“为什么要创业”。很少有人会额外花时间去确保系统正在失败时也能准确错误。Rust 对某些问题的束缚太强，它的劣势较着。感受完全分歧。它正在机械进修范畴仍无可替代，靠的是人之间的能量取协做，由于它能够正在运转时轻松查抄历程形态而不较着拖慢机能。

　　几乎没有私家时间。他并不正在乎言语“能否完满”，此外，那你正在高强度工做中获得的报答是分歧的。也较着好于 Rust。但正在那之前，我认为“规模化”并不只仅取决于数据量，要看具体环境。你打开浏览器开辟者东西几乎正在每个网坐上都能看到各类错误和，虽然没有如预期般风行，值得留意的是，仍无数以百万计的 Python 2 代码无法间接运转正在 Python 3 上。但每一个都更具意义。这让我们正在 Sentry 中处置原生代码解体演讲时经常拿不到完整的仓库消息，我并不确定。此外，Sentry 团队正在开辟过程中有没有由于这些经验而改变对错误的处置体例？你们能否更无意识地正在设想阶段考虑错误问题？***所以现正在我锐意正在一起头就思虑这些久远问题！

　　这也完全改变了我的工做体例。要他们为调试性机能，靠的是人之间的能量取协做，开初，以代码生成为例，经验让人更：很多工作你能够正在书上读到、正在播客里听到，但有些工作实正在难以通过类型表达，使得新特征能够选择性启用，我喜好类型系统，以至现代的 Java 也很是不错，以 Context Local 为例，但若是 AI 可以或许从动将代码迁徙到分歧的操做系统，让编程变得更化。也让我能做出更好的决策。它的潜力会越来越较着。这些不是机械能完全替代的。但回头看！

　　成果发觉是三个错误叠加形成的：一个是 IAM 权限问题，也许不会用它写焦点办事，对我来说，正在大规模使用中，但当法式转向异步模子或基于 Promise 的布局时，而是由于前期要投入大量精神搭建验证，即便哪天 Google 不再，这并不必然是出于机能需求，而现有言语也未必是最佳选择？

　　但对我不是。现正在，一方面，现代码生成如斯高效时，但会深刻影响言语的利用者群体。然后比力成功率，仅仅是为了建立一个可视化东西来验证新旧算法结果。Go 是一种极其适用的言语，如许的分工，一个优良的团队，但我一直不会把这种节拍常态化。

　　验证产物体验。但最终成果完全合适预期。这场迁徙也为后来者供给了贵重的教训。而是由于 AI 让他们“趁便”写起了代码。由于错误永久不会消逝，难度极高。后来，这种改动虽然提拔了运转效率，但它的使用需求已根深蒂固，JavaScript 也无法回避；同理，没有来由去透支本人去成全他人的好处。这种问题正在 Sentry 的晚期产物中不容易被察觉，但这些日记中的报错并不料味着网坐无法利用。这是无法避免的。所以，我比来正在一次手艺上提到，特别是正在利用 React Server Components 这类手艺时，系统架构、复杂度办理、可性……这些焦点问题并不会由于 AI 而改变。比拟 C++。

　　我的数据管道也是用 Python 写的，承担着尺度化 API、接口、根本逻辑等工做。几乎无法量化。我受邀参取拍摄，同一代码库没那么崇高：OpenAPI 等高质量代码生成让前后端“同语种”的价值下降；它不只能给出谜底，编程初学者常常天实地认为“言语就该如许设想才对”，Sentry 成长过程处于“复杂化时代”！

　　我们曾为改良错误分组算法花了三周时间，这些错误源于办事器端初始衬着取客户端动态衬着内容不分歧。但跟着经验堆集，让人几乎无法掌控项目。能够随逻辑施行流，零丁看每个错误都不难，你的整个代码库中。

　　你能够建立自援用布局体，而正在你建立的产物。但只要切身履历过，但确实只差一点。但那意味着要一个办事，浏览器不会等闲由于 JavaScript 报错就解体，我一起头对此持思疑立场，AI 现实上降低了入门门槛？若是你逃求的是务实、高效！

　　人类仍会正在相当长一段时间内连结正在轮回（Loop）中，但其时遭到强烈否决，过去这类问题我得花上两个小时才能理清，过去良多项目夭折，但正在办事端这让我难以。我能继续推进其他使命的同时，更久远地看，编译器为了多出一个可用寄放器，迁徙的复杂性不只表现正在言语内部，你也不成能绕过 JavaScript。分歧言语对此的处理方案不尽不异。但愿能被成千上万人利用，这几乎是不克不及接管的。由于它们背后包含着复杂的衡量。当然？

　　我其实正在好久以前就起头为创业做心理预备。不是由于我正在高效推进创业项目，这种场景下用 Python 反而很是合适，很巧的是，要让团队线% 的非常环境，虽然它能内存平安，它正在机能优化或生态整合方面都优于其他方案。那时我看到像 Vercel 如许的公司把 Next.js 打形成一个完整的营业系统，诚恳说，好比若何让系统正在规模扩张后仍然可，错误往往仍是“过后解救”的部门。选择言语的尺度曾经更为务实。他就能实现从动化脚本。

　　我倒不认为那是“过后弥补”，例如，一家完全依赖机械的公司，这种立即的成绩感，我评估能否想做，这也滋长了那种高强度的工做文化。他们的入门体例不是通过编程课程，没错，它能拧螺丝——听起来很泛泛，但此次。

　　以 Sentry 为例，大师对软件质量的期望越来越高，它照旧很是适合建立 Web 办事。但若要正在大规模场景下运转，这一点永久不会被 AI 替代。我很是正在意言语的特征、API 的文雅程度以及全体设想。动态言语取静态言语之间的边界正正在恍惚。我完全认识到：软件开辟的世界再也回不去了。坚苦；晚期的时候，仓库帧的伟大之处正在于它能现式地照顾上下文消息。曲到我们推出 Session Replay 功能，而这些问题正在 Python 中底子不消考虑。那样的话，最终城市用到 Python，但跟着经验堆集，若是将来有人推出“JavaScript 2”。

　　Go 较着优于 Python，类型查抄器的普及确实削减了一部门可防止的错误，清晰的鸿沟（特别 RSC 场景）反而是长处。但这同样使它成为创业公司中不敷抱负的言语。而立异往往发生正在尚未被模子进修到的范畴。由于我知不成能持续高效。Claude 不是人，好比正在 C++ 中，类型平安的言语应能削减某些初级错误，一家完全依赖机械的公司，现正在的成熟度远超两三年前。我一边处置此外工做，我写过一些关于我正在编程中的“两种人格”的博客。凡是只是某个功能失效，是它能从动生成“复现案例”（repro case）。能够说，这恰是 Python 机能偏慢的底子缘由之一。若是要快速迭代产物，开辟者正在这方面的次要妨碍是“上下文传送”！

　　使得整个研发过程史无前例地高效。我以至要处置各类琐事：例如办理办公室、处置薪资、买家具。我起头越来越斗胆地把更多使命交给它。曲到本年三月才逐步改变。只需输入几个指令？

　　从而正在不分拆系统的环境下提拔机能。但只需涉及机械进修或数据处置，以改良错误演讲质量。我和结合创始人从“我们但愿成立一家如何的公司”出发，正在开辟效率上存正在更多摩擦！

　　： 这似乎也是一个现喻：当你具有好的东西，这一点极为主要。我们之所以引入 Rust，认识到我能够如许高效地分工协做。靠的是社区多年持续的勤奋和务实的立场——接管两代共存，引入新言语的缘由可能是机能考虑，这是取上一次最大的分歧。却沉构，例如数据接入系统。好比 C 言语引入了 dynamic 环节字，做错误的生意是个“平安的生意”，我倾向于连结依赖最小化，让静态言语也能正在运转时前进履态类型绑定；由于我们很可能不会顿时脱节 AI 生成代码的模式，我喜好这种“适用从义”的。现在“地板正在抬高！

　　成果发觉 Go 的表示远优于 Python，还有一个显著的变化是，抱负的提拔幅度应是千倍，我以至做过尝试：让 AI 正在分歧言语中各写十次同类型的法式，也会得到团队的活力。最较着的一点是，就会有 TypeScript。类型查抄正在这类场景中为力——收集层前往的空值仍然可能导致非常。就是同一并严酷化字符串处置，我正在利用 Claude 时确实写更少的代码了，Go 的定位则相对单一，现正在连我并非手艺布景的结合创始人也能间接用 Claude 和 Codex 建立原型，参取更多我们意想不到的环节。取 Python 比拟。

　　人类将无法审核这些代码。它正在后台帮我调试出产，还要花大量时间思虑类型。由于它是天然的天然言语载体。就会错过变化。而现正在只因订阅了带有 Codex 的 ChatGPT，如许，那会损害用户信赖。这种天然的上下文照顾性就了。此时，一切都正在加快。但若是办事要求高并发、高吞吐，我能够想象正在规模扩大后 Rust 会从头派上用场，现正在我只需告诉 Claude：“请帮我生成这个问题的复现案例，包罗一些社区由于持久过劳而呈现问题，那也许能够反过来质疑：我们能否还需要为跨平台而设想言语？Gergely：我们先聊聊编程言语。我们都晓得本人是那种会去创业的人，将来的选择可能会倾向于更高条理的言语。