编程语言与软件工程2018christophermeiklejohn.com
面向容器与 AWS Lambda 的类型系统以避免故障
Towards a Type System for Containers and AWS Lambda to Avoid Failures
进阶 · 约 25 分钟读完前置知识：分布式系统基础、类型系统/IDL 概念、容器与 AWS Lambda 基础
导读
这篇论文提出为容器与 AWS Lambda 之间的跨系统交互引入类型系统（类似 IDL/契约），以期在部署前发现并避免运行时故障。文章以 ZooKeeper/Kafka 等为例讨论跨服务类型不一致导致的问题，但评论者认为其仍停留在「应该用更好的类型」的倡议层面，缺少具体方案描述。
HN 关注点：「跨系统类型/契约」这一想法是否有实际价值：有人质疑论文概念含糊、举例不当，也有人分享用 FaaSlang、protobuf 实现类似目标的一线经验。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
质疑质疑论文概念空泛、容器与 ZooKeeper 例子都不恰当，且统一 IDL 不现实
我不太确定这篇论文的重点是什么。它大谈容器，但本质上是跨系统的契约问题，跟是否跑在容器里无关，所以「容器」这个词没必要。它说「迈向类型系统」，然后只是泛泛谈 IDL/REST/Thrift，说「我们需要跨系统的东西……所以应该用更好的类型」，但究竟长什么样？只有「我们做过这个」的模糊断言，看不到具体描述。ZooKeeper/Kafka 的例子虽然贴切，但我怀疑「跨系统类型系统」是否说对了：ZooKeeper 有意且合理地不关心客户端在它文件系统里编码了什么，所以复制数据是 F 还是 F+1 对它毫无意义；解决方案不是让 ZooKeeper 感知 Kafka 的不变量，而是 Kafka 自己正确解释这些数据——如果这意味着在 Kafka 的 ClusterInfoApi 抽象里返回 Either[ValidCluster, InvalidCluster]，那没问题，但 ZooKeeper 的 API/IDL 不会也不该关心。另外你永远不可能让所有网络服务就唯一正确的网络格式/类型系统/IDL 达成一致，那为什么还要把它当作可行方向来讨论？（声明：我不常读学术论文。）
stephen查看英文原文
I'm not sure what the point of this paper is? * It talks a lot about containers, but this is really just contracts across systems, whether they run in containers or not. So not sure why the word "container" is necessary. * It says "towards a type system", but then just muses about IDL/REST/Thrift, says "we need cross-system stuff ... so we should use better types", ...but...what does that look like? There are vague assertions that "we've done this", but I don't see any description of what that actually looks like. * The Zookeeper/Kafka example, while apt, I'm not sure if "having a cross-system type system" is exactly right, as Zookeeper is purposefully/validly ambivalent about what its clients encode within it's file system, so whether the replication data is F/F+1/whatever is meaningless to Zookeeper. So to me the solution is not "cross-system type system" where Zookeeper becomes aware of Kafka's invariants, it's just Kafka itself correctly/internally interpreting the Zookeeper data. If that means it's an Either[ValidCluster,InvalidCluster] within the Kafka "ClusterInfoApi" abstraction, that's fine, but that's not something the Zookeeper API/IDL is going to care/know about. * You're never going to get all networked services to agree on the One True networking format/One True type system/IDL, so why even muse about this as a possible approach? Disclaimer I don't read academic papers on a regular basis.
补充介绍 FaaSlang：用注释静态推断类型，在网关层做类型转换与校验
我们在 StdLib 做的就是这个，叫 FaaSlang。它用静态分析加上 ESDoc 注释的超集，为无服务器函数的 API 接口推断类型，从而在函数执行前于网关层自动完成查询参数类型转换、自动错误检查等。零配置，按平常习惯写注释即可。它差不多是 TypeScript 和 JavaScript 之间的一个健康中点，运行在运行时之上，理论上适用于函数容器里跑的任何语言。
keithwhor查看英文原文
This is what we’ve done at StdLib [1] with FaaSlang [2]. FaaSlang uses static analysis and a superset of ESDoc comments to infer types for the API interface to serverless functions on our system. This allows for automatic type coercion from query parameters, automatic error checking, and more - all caked in at the gateway layer before a function is executed. Zero configuration; just write comments the way you normally would. It’s almost a healthy midpoint between TypeScript and JavaScript, operating above the runtime, but theoretically applicable to any language run within a function container. [1] https://stdlib.com [2] https://github.com/faaslang/faaslang/
亲历亲历：用共享 protobuf 定义 + 两端类型检查来给 Lambda 加契约
我在开发这类系统上的经验远没那么多，所以一开始在没有类型的情况下上手有点发怵。我的做法是把 Lambda 函数包在 protobuf 里，并用一个共享的公共定义仓库；这样 Lambda 服务既支持 proto 的 JSON 表示，也支持完整的二进制 proto，两端都做类型检查。想听听大家觉得这个方案怎么样。
arcticbull查看英文原文
I've not nearly as much experience developing these systems, so getting started without types was a bit daunting. I wrapped my Lambda functions in protobufs and used a shared common definition repository. Then the lambda services support either the JSON rep of the protos or full-on binary protos, and the type checking happens on both ends. Curious what y'all think of this as a solution.
支持乐见此类研究，呼吁从 CORBA/SOAP 等历史尝试中吸取经验而非一味排斥
很高兴看到这个领域有更多工作！也很欣慰论文提及了过去的各种尝试——重要的是从它们的失败中学习，也要从成功中学习。人很容易陷入「呃，CORBA」「不要啊，SOAP」的思维定式，而看不到其中的机会。让我们坚持下去，把这件事搞明白！
bjz_查看英文原文
I'm really happy more work is being done in this space! Also nice to see nods to various attempts from the past - it's important we learn from their failings, but also their successes. It's too easy to get stuck in the mindset of "Ugh CORBA" and "noes, SOAP", without being able to see an opportunity there. Let's be persistent and figure this stuff out!
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖180 分 · 63 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选