云，为什么这么难？🤷‍♀️

面向云的编程宣言。

别误会，我爱云！它让我能够创造出令人惊叹的东西，并彻底改变了我使用软件进行创新和解决问题的方式。

它是“新型计算机”，终极计算机，无计算机的计算机。它可以弹性扩展，始终在线，无处不在，无所不能。它无所不能，而且一定会持续存在。

但是，我的天哪，我们未来十年构建云应用程序的方式绝对不可能是这样的。随着云从“我不想在办公桌下放服务器”发展到“我的应用程序需要30个不同的托管服务来执行其任务”，我们几乎忘记了优秀的开发者体验是什么样的。

构建云应用程序有时感觉就像把孩子们没用过的乐高积木包洒在客厅地板上，然后自己试着搭一座城堡。在经历了撕碎的卡片、吓人的芭比娃娃头和漏液的电池之后，你把说明书读了无数遍，却发现最终搭出来的基本上和上次搭的一样。

整理乐高积木真有趣！它能和孩子们一起消磨时间。它甚至还能满足我的强迫症……但是，这可不是我想要开发专业软件的方式！

让我尝试描述一下我和我的开发人员朋友们正在努力解决的问题。

我想专注于为用户创造价值

当我构建专业软件时，我希望大部分时间都花在应用程序的功能领域内，而不是我使用的平台的非功能机制上。

每次我想在 AWS Lambda 函数中执行代码时，我都必须了解它需要与 tree-shaken 依赖项捆绑在一起，以 zip 文件的形式上传到 S3，并通过 Terraform 进行部署，这毫无道理。或者，为了能够向 SNS 发布消息，我的 IAM 策略必须包含允许sns:Publish对主题的 ARN 执行操作的语句。难道每个开发人员都需要了解 ARN 是什么吗？

这些东西跟我试图为用户创造的价值毫无关系。它们只是纯粹的机制。我们能去掉它们吗？

我想独立

对于我来说，作为一名开发人员，最令人沮丧和最令人沮丧的情况之一就是我不得不停下来等待某人或某事才能继续。

就像在空中快乐地滑翔，欣赏着美景，背景中播放着美妙的音乐，突然，砰！一堵混凝土墙。

在构建云应用程序时，这堵“混凝土墙”的形状和大小各不相同。它可能是 DevOps 人员，负责处理无休止的工单；它可能是需要更新的 IAM 策略；它可能是只有外部兼职顾问才知道如何调试的部署失败；它可能是内部平台中积压的无数缺失的旋钮和 API，而我们原本希望这些旋钮和 API 能够改变这一切。

这些障碍令人沮丧，因为它们迫使我切换环境，应用“临时”安全策略，甚至发明一些我不愿提及的丑陋黑客手段。这是一个支离破碎的世界。

我想要独立。我想要能够完成任务，保持节奏。我想要一个个提交，改善世界，完成后再继续下一个。我想要完成任务时那种多巴胺的快感，而不是又一个未完成的线程带来的羞愧感。

我想要即时反馈

我说过我想要独立，但不要误以为我写的代码是完美的。这就是为什么我想用铅笔而不是钢笔写代码。

一些开发人员可以花一整天的时间编写代码，甚至无需调用编译器，而在一天结束时，他们编译并部署，程序就可以正常工作。

我钦佩他们，但我不是那种开发者。先生，不是。对我来说，关键在于迭代、迭代、再迭代。我从小处着手，用一支细铅笔勾勒轮廓，看一眼，擦掉一些，再画一条粗线，退一步，眯起眼睛，继续画，擦掉更多，再看一眼，如此反复。

这就是为什么对我来说，迭代速度至关重要。我越早运行并测试我的应用程序，就能越快地回溯和迭代。这就是我的工作流程。

我刚开始编程的时候用的是 Borland C++。在 IBM PC AT 机器上（TURBO ON）编译运行一个程序大概需要 100 毫秒。云端的平均迭代周期只需要几分钟。几分钟！有时甚至几十分钟！

现在云端的迭代流程是这样的：我修改了代码；然后需要编译；部署到我的测试账户；找到管理控制台来触发迭代；等待迭代运行，然后去
其他服务上搜索日志。然后我意识到出现了一个错误响应，它告诉我我太蠢了，我怎么会不知道必须传入 Accept-Content: application/json 呢？否则我会得到一个叫做“XML”的奇怪结果，我完全不知道该怎么处理（开个玩笑，XML 很棒，不是吗？）。现在一切又要重新开始了……

所以你以居高临下的姿态说“写单元测试”，试图为当前的现实辩解。“优秀的开发人员会写单元测试”。好！现在我需要拿出我的代码，它调用了大约20个外部API，然后通过从过时的文档中复制粘贴来模拟API响应，结果却发现我的请求被拒绝了，因为我的IAM安全声明中缺少一些隐式操作。我们都经历过这种情况。

说实话，给我 90 年代的开发体验吧。我想做一个修改，并且希望能够在几毫秒内以交互方式或通过单元测试来测试这个修改，而且我希望坐在没有 WiFi 的飞机上也能做到这一点，好吗？（90 年代我们可没有 WiFi）。

所以这只是一场咆哮？

绝对不行！我是个程序员。我有时候感觉自己从出生起就在写软件了。我写软件的时候，社会环境很不稳定，当个电脑极客可不是什么酷事。

作为一名开发者，我一直热爱的一点是，如果我对我的工具不满意，我可以自己制作。毕竟，制造工具是我们的基因——人类制造工具的历史已经超过一百万年了。

我对我的工具不满意。

2022 年 4 月，我与好友兼前微软同事Shai Ber携手创立了 [Wing]，致力于为开发者解锁云技术。我们组建了一支由优秀极客组成的优秀团队，他们与我们一样对开发者体验和开源充满热情，并开启了赋能开发者（也就是我们自己）解决这些根本性问题的旅程。

编译器来拯救

那么，我们该如何一次性解决所有这些问题呢？
我们正在构建一种云计算编程语言。

“编程语言！？ ”你问道，“难道世界上的编程语言还不够多吗？ ”“编写编译器真的很难吗？ ”“开发人员想要学习一门全新语言的可能性有多大？ ”“为什么你不能侵入现有的语言工具链，眯起眼睛仔细看看，然后就完事了？ ”

我不是那种一时兴起就构建编程语言的人。事实上，过去五年我一直在构建AWS CDK，这是一个多语言库，它允许开发人员使用自己喜欢的编程语言定义云基础设施，从而解决了我所说的一些挑战。

“在开发人员所在的地方与他们会面”是 AWS 和 CDK 的一个美好宗旨，并激励我们创造出JSII和构造等出色的技术。

但有时，“他们在哪里”并不足以成为创造所需体验的良好模型。

用代码定义基础设施确实使我们能够创建更高级别的抽象，但只要我的应用程序代码需要与该基础设施交互，抽象就会变得漏洞百出。我被迫不得不理解超出我需要的东西，我必须成为 IAM、VPC、ALB、EBS 以及基本上比我愿意记住的更多 TLA 方面的专家。

我们今天使用的语言都是围绕着计算机是一台单一机器这一理念设计的。它们已经达到了能够为我们提供这些机器之上的坚实抽象的程度。它们抽象出了 CPU、内存、文件系统、进程管理和网络。作为一名开发者，我不需要关心文件在磁盘上的布局，甚至不需要关心我的哈希映射需要多少内存。我只需要编写readFile()代码，new Dictionary()然后继续我的日常工作。是的，了解一下底层发生的事情对我来说并非坏事，但我并非被迫这样做。

大多数这类语言也提供了类型安全。当我调用一个带有错误参数数量的函数时，编译器会发出警告。我不用等到应用程序运行起来才发现我忘记了参数，或者传递了错误的类型。

在云端，我只能靠自己。每当我的代码需要与云资源或服务交互时——随着行业的发展，这种情况越来越频繁——我都必须离开编程语言的舒适和安全。我必须跳出机器的界限，进入互联网的狂野西部，而我的编译器对此一无所知。

突然之间，所有痛苦的根源几乎显而易见。如今的云应用程序只是一堆互不相干的碎片拼凑而成。我的基础设施需要一个编译器，我的函数需要一个编译器，我的容器需要一个编译器，我的CI/CD 流水线也需要一个编译器。每个编译器都非常认真地工作，确保我在每台机器上都能安全愉快地运行。但我的应用程序不再运行在一台机器上，而是运行在云端。

云就是计算机。

Wing，一种面向云的编程语言

当新的编程范式出现时，编程语言需要时间来跟上。我曾经喜欢用 C 语言编写面向对象代码，但那是一种漏洞百出的抽象。我必须了解对象在内存中的布局方式、虚表的工作原理，并记住将对象作为每个函数的第一个参数传递。当编程语言开始将面向对象的概念作为“一等公民”来支持时，这种范式就普及了，而如今大多数开发人员甚至不知道虚表是什么，世界仍在继续运转。

Wing，或者如果你想给它起个可爱的名字叫winglang，它拥有你对现代、面向对象、强类型和通用语言所期​​望的所有优点，但它还包括一些额外的原语，旨在支持云作为一等公民的分布式和基于服务的性质。

一探究竟

我们开发 Wing 已经快一年了，我很高兴邀请您试用并分享您的使用感受。虽然 Wing 仍处于 Alpha 测试阶段，尚未准备好投入生产使用，但已经可以用它来构建一些实际的应用了。

请为 Winlang 点赞⭐