《代码英雄》第三季（5）： 基础设施的影响
代码英雄 COBOL

> 
> 代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。
> 
> 
> 



> 
> **什么是《代码英雄》**
> 
> 
> <ruby> 代码英雄 <rt>  Command Line Heroes </rt></ruby>是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。
> 
> 
> 


![](/data/attachment/album/202012/11/094106a0cbrz2b1cz0c7c0.png)


本文是《[代码英雄](https://www.redhat.com/en/command-line-heroes)》系列播客[《代码英雄》第三季（5）：基础设施的影响](https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect)的[音频](https://cdn.simplecast.com/audio/a88fbe/a88fbe81-5614-4834-8a78-24c287debbe6/0ea5a208-a01f-46f8-902c-27cf4ffd0e6a/CLH_S3_EP5_The_Infrastructure_Effect_vFINAL_tc.mp3)脚本。




> 
> 导语：用在 IT 基础设施中的语言是没有有效期的。COBOL 已经存在了 60 年 —— 而且不会很快消失。我们为大型机维护了数十亿行经典代码。但我们也在用 Go 等语言为云构建新的基础设施。
> 
> 
> COBOL 是计算机的一次巨大飞跃，让各行各业变得更加高效。Chris Short 介绍了学习 COBOL 是如何被视为安全的长期投注的。60 年后的今天，还有数十亿行并不容易被替换掉的 COBOL 代码 —— 懂这门语言的专家也很少。Ritika Trikha 解释说，有些事情必须改变。要么更多的人必须学习 COBOL，要么依赖 COBOL 的行业必须更新他们的代码库。这两个选择都很困难。但未来并不是用 COBOL 编写的。今天的 IT 基础架构是在云端构建的，其中很多是用 Go 编写的。Carmen Hernández Andoh 分享了 Go 的设计者是如何想要设计一种更适合云计算的语言。Kelsey Hightower 指出，语言通常都是超专注于一种任务。但它们正变得越来越开放和灵活。
> 
> 
> 


**00:00:00 - Saron Yitbarek**：


1904 年，纽约市地铁首次开始运营时，它被惊叹为现代的一个奇迹。但是……当今天的通勤者仍依赖一个多世纪前设计的基础设施时，会发生什么？列车挤满了人，而且常常晚点。纽约每年有 20 亿人次地铁出行，再也没有人为此感到惊叹了。我们还在依赖昨日的过时基础设施，我们必须找到新的好办法，让它发挥作用。


**00:00:44**：


过去，基础设施项目通常是些可见的大而具体的事物，例如地铁。而且由于这种物理可见性，它们损坏时也显而易见。高速公路开裂、电线杆倒下，我们很清楚这些东西何时需要维修。为了使我们的生活与老化的基础设施保持协调，大量的工作是必不可少的。


**00:01:12**：


但是事物并不总是那么一是一、二是二。如今，我们还拥有 IT 基础设施，在偏僻地区嗡嗡作响的服务器农场，跨越海洋的光纤电缆，还有软件基础设施。而像遗留的操作系统或没人敢替换的 shell 脚本，这些 IT 基础设施变得陈旧和破旧时，我们是无法看出的。但是，造就了今日发展的基础设施却正在老化，就像旧的地铁轨道一样。这可能会扰乱我们的现代生活。如今命令行英雄们正努力确保我们不会被过去束缚，因此出现了大量新的挑战。


**00:02:02**：


这是我们第三季进入编程语言世界探索的第 5 期。我们将研究两种编程语言，它们与最初设计的目标基础设施密切相关。COBOL 是一种大型机的原生语言，而 Go 是云计算的原生语言。它们都深受其起源的影响。理解这一点可能会让明天的开发者不至于像纽约人一样被塞进宾夕法尼亚州的车站。


**00:02:33**：


我是 Saron Yitbarek，这里是红帽的原创播客，《命令行英雄》的第三季。



> 
> **00:02:43 - <ruby> 格蕾丝·赫柏 <rt>  Grace Hopper </rt></ruby>**：
> 
> 
> 我们面前有很多事情需要去做，但是我们首先需要大量相关的且易于访问的信息。我们才刚刚开始。
> 
> 
> 


**00:02:53 - Saron Yitbarek**：


海军上将<ruby> 格蕾丝·赫柏 <rt>  Grace Hopper </rt> 在 20 世纪 40、50 年代率先开发了高级编程语言。而她之所以能够实现这种巨大的飞跃，是因为当时的基础设施，大型计算机。</ruby>


**00:03:08 - Chris Short**：


嗨，我叫 Chris Short。


**00:03:10 - Saron Yitbarek**：


Chris 是红帽的首席产品营销经理，而且他也是一位历史爱好者。


**00:03:17 - Chris Short**：


上世纪 40 年代的赫柏上将创造了 FLOW-MATIC，这在当时是革命性的，她被广泛认为是 COBOL 的祖母。因此，她能够坐在那里说：“嘿，只需将其放在大型机上”，或“嘿，只需将其存储在大型机上”即可。


**00:03:31 - Saron Yitbarek**：


这是一个重大的游戏规则改变。突然，你有了这种机器无关的语言，即 COBOL，它是大型机环境特有的。可能性开始逐步打开。


**00:03:42 - Chris Short**：


大型机和 COBOL 真正使得每个组织能够说，它们不再需要充满了带着铅笔、纸、计算器和滑尺的人的办公室，他们可能只需要半个办公室来安装大型机。然后，他们可以雇人用 COBOL 来编写一些应用程序来完成整个财务团队做的所有的数学、逻辑运算以及账目。因此，你需要的财务团队人数少了，仅仅是因为更多的输入可以被数字化，而不是全手动操作。


**00:04:17 - Saron Yitbarek**：


如果你是那些新来的 COBOL 程序员之一，你会觉得你有了一份终身的工作。因为你的工作所基于的基础设施 —— 所有那些大型机 —— 始终会在那里。


**00:04:30 - Chris Short**：


那时侯摩尔定律还未出现，所以你可以整整十年都在同一个大型机上工作，对吧？就像你不用去考虑下一个操作系统，或者下一个类型的容器编排器，又或者下一个出现 AI 之类的东西一样。你可能会整个职业生涯都在从事 COBOL。而且你知道自己的生活将会非常稳定。


**00:04:55 - Saron Yitbarek**：


但是，摩尔定律最终还是来了。新的基础设施也出现了。现如今，程序员不太可能去学习一种半个世纪前的旧语言。但实际上，那些老旧的大型机其实并没有消失。这意味着我们对 COBOL 开发人员的需求也没有消失。


**00:05:17 - Chris Short**：


寻找 COBOL 开发者变得越来越困难。最终会发生的事情是这些大型机可能已经存在了 50 年。这些仍然可以编写出色 COBOL 程序的开发人员将获得巨额收入，以帮助项目运行并完成大型机中的数据重组。而且，该技能肯定会绝迹，并且正在成为一个利润丰厚的职业领域，如果你……现在写 COBOL 绝对可以赚很多钱。


**00:05:49 - Saron Yitbarek**：


尤其是在制造业和金融业。你无法超越几十年前建立的所有基础设施。遗留代码遍及全球。忽略这些老旧的基础设施及其相关的语言，将是一个巨大的错误。


**00:06:08 - Chris Short**：


有两千亿行代码摆在那里，要重构这些代码真的很难。不，我不认为在有生之年我们会看到它消失，真的。


**00:06:21 - Saron Yitbarek**：


Chris Short 是红帽的首席产品营销经理。


**00:06:28**：


我想花一秒钟解释一下 Chris 的观点。你想想看，95% 的 ATM 交易中都有 COBOL 代码，那就是我们与这种语言的联系。但是，COBOL 程序员的平均年龄并不比该语言年轻多少。他们 45 岁，或许 55岁。新人们并不感兴趣这门语言。这就是为什么我想向你介绍一个人。


**00:06:56 - Ritika Trikha**：


嘿，我是 Ritika Trikha。


**00:06:59 - Saron Yitbarek**：


Ritika 是一名技术编辑，曾在 HackerRank 工作。她对 COBOL 的这个问题着迷：人们认为 COBOL 是后大型机时代无意义的残留品。


**00:07:12 - Ritika Trikha**：


如今的开发人员根本不会考虑 COBOL 了，见也没见过，想也没想过。


**00:07:17 - Saron Yitbarek**：


但这可能是灾难的根源。


**00:07:21 - Ritika Trikha**：


如今，仍然有大量的 COBOL 代码在驱动企业的业务。每年至少新增 15 亿行 COBOL 新代码。我认为当你看特定行业时，真的很有意思。就像美国国税局有 5000 万行代码。社会保障局有 6000 万行代码。 因此，这些单位和实体正在处理一些如今最敏感、重要的信息，如果我们不继续为这些大型机提供支持和维护，就会造成很大的破坏。


**00:08:04 - Saron Yitbarek**：


因此，如果我们无法摆脱旧的基础设施，又无法挥舞魔杖来重建整个大型机业务，我们该怎么办？编码人员有时候仅考虑未来，该如何接受过去？我们首先需要直面该问题。


**00:08:25 - Ritika Trikha**：


你知道，年轻一代将不得不重拾这些技能。或者，必须对这些大型机进行某种现代化改造。无论是哪种方式，这个问题都不会消失。这就是为什么 COBOL 还活着的原因。


**00:08:35 - Saron Yitbarek**：


这并不容易。 Ritika 认为我们已经忽略这个问题太长时间了。


**00:08:42 - Ritika Trikha**：


这非常昂贵、艰巨，并且替换数十亿行 COBOL 代码的风险也非常高。它是用于关键任务的代码，比如社会保障和金融信息。COBOL 是专门为此类大量交易而设计的。因此，它由格蕾丝·赫柏在 60 年代为商业交易而设计。自上世纪 60 年代以来，一直存在“如果没坏，为什么要修复它”的说法，现在我们处于这样一个关头，即延续了数十年的大量的高价值数据运行在 COBOL 上。


**00:09:22 - Saron Yitbarek**：


从某种意义上说， Ritika 在呼吁一种文化的转变。改变对 "进 "与 "退 "的态度。由于发展的世界慢慢有了越来越久的历史，我们会更加地接触到自己的历史。你无法摆脱老化的基础设施。这意味着你也不能忽略编程语言的历史。


**00:09:47 - Ritika Trikha**：


有些事情必须得做。当我在 HackerRank 时，我亲眼看到了多少银行和金融机构对 COBOL 开发人员的伤害，几乎是绝望的。这不是一个会被解决的问题，我认为要么必须有某种现代化的系统，要么我们继续培训人员并激励他们。我个人认为将会有 COBOL 再次出现的一天。真的，当所有拥有 COBOL 知识的开发人员退休，并且没有新一代的开发人员学 COBOL 时，将会发生什么？总得做点什么，对吧？所以，当从 COBOL 转向新的基于云的基础设施时，需要有更多的系统化和制度化的改变。


**00:10:37 - Saron Yitbarek**：


Ritika Trikha 是一名旧金山的技术作家。


**00:10:49 - Saron Yitbarek**：


那么 Ritika 提到的那些基于云的基础设施呢？我们今天建立的基础设施是否会将后代绑定到特定的语言，像我们仍绑定找 COBOL 上一样？<ruby> 亚马逊 Web 服务 <rt>  Amazon Web Services </rt></ruby>（AWS）可能是最大的单一云基础设施，于 2006 年推出。<ruby> Google 云平台 <rt>  Google Cloud Platform </rt></ruby>（GCP）于 2008 年问世，微软 Azure 于 2010 年问世。 Go 语言以并发为重点，定位于在新的云基础设施上蓬勃发展。这是这个时代的语言。


**00:11:26 - Carmen Andoh**：


嗨，我叫 Carmen Andoh， 我是谷歌 Go 团队的项目经理。


**00:11:34 - Saron Yitbarek**：


Carmen 对 Go 语言与今天的基础设施有怎样的联系有深入的理解。这要从 Go 的创作者和编程语言历史的紧密联系说起。


**00:11:47 - Carmen Andoh**：


Robert Pike、Robert Griesemer 和 Ken Thompson。这些名字算是从上世纪 60 年代就开始出现了。Ken Thompson 发明了 B 语言，然后他在夏天的假期继续发明 UNIX 操作系统。Rob Pike 发明了字符串编码 UTF-8，他还发明了 ASCII。他帮助 Ken Thompson 共同编写了 UNIX 编程环境。所以，这两个人是很多、很多年前的同事，他们一直在研究和发明用以前的编程语言编写的操作系统，这些语言包括 Ken Thompson 最终帮助 Dennis Ritchie 一起编写的 C 语言。


**00:12:28 - Saron Yitbarek**：


Pike、Griesemer 和 Thompson 在 Google 工作之后，他们发现了一个严重的问题。并没有出现大规模的并发。人们等待了几个小时编译出来。他们使用的是 C++，并且必须得编写所有这些回调和事件调度器。那是在 2009 年，我们的基础设施再次发生了变化。诸如 C++ 之类的语言越来越不适应这种新的现实。


**00:12:59 - Carmen Andoh**：


多核处理器、网络系统、大规模计算集群和 Web 编程模型等正在引入这些问题。而且，还有这个行业的增长，程序员数量在 2010 年就会达到成千上万。因此，直到那时，所有的编程语言都是在规避问题而不是在正面解决问题。


**00:13:24 - Saron Yitbarek**：


最终，将达到一个临界点，必须开始改变。


**00:13:30 - Carmen Andoh**：


嘿，我们讨厌 C++ ，我说：“好吧，让我们看看我们是否能发明些新的东西。”


**00:13:37 - Saron Yitbarek**：


这种新语言需要完美地适应我们最新的基础设施。


**00:13:43 - Carmen Andoh**：


2005 年云技术到来以后，你不再需要自己的计算机，在某种程度上在其他地方租用它，你就可以得到一个分布式系统。但是在分布式系统中，以及在云计算中，存在并发消息传递问题。你需要确保采用异步对你来说没有问题。Go 缺省就是异步的编程语言。基本上，这意味着你执行的每个操作（例如将所有这些不同的消息发送给系统中的另一个计算机）都无需等待另一个机器对你的响应即可完成。因此，它可以在任何给定时间处理多个消息。


**00:14:28 - Carmen Andoh**：


就是说，云计算是分布式的。因此 Go 的开发就是来满足这一确切需求。Go 早就成为进行这种分布式计算的标准方法之一。这就是为什么我认为它立即引起了开发人员的广泛关注。Go 绝对是云基础设施的语言，无论是其设计，还是所有云基础设施工具，以及在过去十年中如雨后春笋般出现的模块的生态。


**00:15:06 - Saron Yitbarek**：


很快，诸如 Kubernetes 之类的关键应用都用 Go 编写了。谷歌还创建了 Go Cloud，这是一个开源库和一系列工具，使得 Go 更具吸引力。很显然，它是新生态系统的语言。它是云的语言。而且，它的创造者们因开发生命力持久的语言而享有声誉，这绝对没有坏处。


**00:15:33 - Carmen Andoh**：


我认为业界的其他人会说：“嘿，我认为这不会很快消失。”这种语言的发明者恰巧也发明了语言有 50 、60 年了。


**00:15:47 - Saron Yitbarek**：


Carmen Andoh 是谷歌 Go 团队的项目经理。


**00:15:54**：


因此，我们有了一种新的语言 Go ，旨在提供云基础设施必需的并发性。听起来不错。Go 的设计师倾向于创造可以持续半个世纪的语言。这也很棒。但是我的问题是，从现在起，50 年后，当 Go 更像是 COBOL 时，这到底意味着什么？当世界上充满了只有老开发人员才能理解的旧版 Go 代码时，这又意味着什么？在当今的云基础设施老化的时候，我们是否会做好准备？我们是否从 COBOL 和大型机领域吸取了教训，可以帮助我们为 Go 和云设计更美好的未来？


**00:16:40**：


幸运的是，我找到了问所有这些问题的合适人选。这就是下面这位。


**00:16:51**：


我们如何使我们的语言能面向未来？我们知道他们与当今的基础设施息息相关。我们也知道，随着数十年的发展，新的基础设施必将取代旧的基础设施。那么，我们今天做些什么以确保将来能平滑演进？


**00:17:10 - Kelsey Hightower**：


我是 Kelsey Hightower ，我在谷歌，是一名开发人员推广大使，我致力于引入开放性技术并将它们应用于谷歌云上的产品。


**00:17:19 - Saron Yitbarek**：


Kelsey 花了大量时间思考编程的未来。我很好奇，是否有一天我们将陷于握有 Go 语言技能的是另一批老龄化的程序员的问题，就像我们现在缺少 COBOL 的引导一样。我们是否在为这个长远的未来做计划？因此，我和 Kelsey 坐下来进行讨论。


**00:17:42 - Kelsey Hightower**：


...等等。但是，如果你考虑到今天面临的一些新的挑战，如应对互联网，这种网络，你将面临许多用户，成千上万的并发用户，以及不同的机器和架构类型的组合。考虑到这些新的场景，因此你通常希望有一种新的语言来解决。例如， JavaScript 是用于 Web 的，你不会想改造 COBOL 以便可以用它来进行 Web 编程。最终，我们今天已经有了数百种相当完善的语言，而且它们都非常专注于他们的优势。


**00:18:15 - Saron Yitbarek**：


那么，在那种情况下，我们是否需要积极推动人们走向 COBOL ？如果我们正在为这些新问题开发新语言，并且它们是高度定制化的，而 COBOL 仍在坚持不谢幕，我们是否需要鼓励人们选择它，以便我们可以维护我们的旧代码？


**00:18:32 - Kelsey Hightower**：


好吧，我认为这将对企业是个挑战吧？所以，你已经在 COBOL 上投入了 10 到 20 年，没有人会主动想学习一些新的 COBOL。或者你不会像刚从大学毕业那么“我要加倍努力……”。


**00:18:45 - Saron Yitbarek**：


没错。


**00:18:46 - Kelsey Hightower**：


“...这种语言比我父母的年龄都大。” 因此，在那个领域，你必须问自己，继续使用 COBOL 的风险是什么？未来是否仍然有意义？我认为它仍然有益于某些类型的工作任务，但是我们必须问自己一个问题，是时候推进了吗？是时候进化一点了吗？因此，如果你仍然有数十亿行的 COBOL 代码，那么你将必须寻找所有剩余的 COBOL 人才，并将其招进来，但也许我们该开始考虑其他语言能从 COBOL 学习些什么，并将某些功能和库加入到其他语言中。


**00:19:26 - Saron Yitbarek**：


COBOL 终止以后的日子，将会是一个巨大的基础设施项目。用我对纽约地铁的比喻，就像是要替换每条地下隧道。因此，展望未来，我想知道我们是否可以预见到这些问题，甚至将来对自己也能有所帮助。


**00:19:48**：


如果我们将今天的云计算与大型机进行比较，我们是否会在最终到达同一条船上，有着这些旧代码库，使用着旧的但非常稳定的语言，而且我们也到了必须做出选择的时候，我们应该继续前进还是保持不变？


**00:20:05 - Kelsey Hightower**：


云有点不同的是它不是来自一个制造商，对吗？许多云提供商通常提供了一系列技术集合，你就可以选择编程语言、编程范式，无论你是要事件驱动还是基于 HTTP 的全 Web 服务。这意味着你可以选择编程的方式，然后只需专注于要解决的问题。因此，数据进进出出，但是你来选择处理数据的方式。


**00:20:36**：


大型机通常只有一个主界面，对吗？就像你编写一份任务一样，这就是你提交任务的方式，这就是你监控任务的方式，这就是结果。这本身就是一个限制。如果你考虑一些较新的大型机，它们也会支持些较新的技术，因此即使在大型机领域，你也会开始看到可用于运行任务的编程语言扩展。


**00:20:58**：


那么我们开始问自己，好吧，既然我有了新的选项，该什么时候离开这种特定的编程范式继续前进呢？我认为我们不会陷入困境。


**00:21:08 - Saron Yitbarek**：


正确。


**00:21:08 - Kelsey Hightower**：


我认为新的分布式机器很不错，可能起步成本更低，你不必购买整个大型机即可开工。但是我们仍然希望易用性和之前一样：给你我的工作，你为我运行它，完成后告诉我。


**00:21:24 - Saron Yitbarek**：


绝对是这样，你觉得发生的事情，或者说 COBOL 所发生的事情，会发生在今天的任何一种语言上吗？ 以 Go 语言做例子，你看到我们在努力地改进 Go 从而吸引人们在 30 年后还想用 Go ？


**00:21:38 - Kelsey Hightower**：


我认为所有语言都会遭受这种命运吧？如果你仔细想一下，其实 Python 已经存在很长时间了。我想差不多 20 年了，甚至更久。因此，我认为会 …… Python 重新流行起来了，它现在是机器学习的基础语言。


**00:21:53 - Saron Yitbarek**：


是的。


**00:21:54 - Kelsey Hightower**：


对于 Tensorflow 之类的库，如果我们仅用时间来衡量，我认为这可能不是看待它的正确方式。还应该有社区是否活跃？语言的适配意愿是否活跃？我认为 Python 做得确实非常出色……社区看到了使其他语言更易于使用的能力。例如，Tensorflow 底层有很多 C++ ，使用这种语言编程可能没有 Python 这样的用户友好性。你可以用 Python，并用它来生成人们正在使用的一些东西，例如 Tensorflow 。现在机器学习非常热门，人们将 Python 引入了这个新领域，那么你猜怎么着？ Python 仍然是活跃的，并且在未来的一段时间内都是活跃的。对于 Go 来说，这同样适用。如果 Go 能够继续保持活跃度，那么，它就像许多基础设施工具和许多云库的基层一样，它也将保持活跃。因此，我认为都是这些社区确保了它们将来占有一席之地，并且当未来出现时，确保那里仍有它们的位置。


**00:22:58 - Saron Yitbarek**：


是的。那么，我们如何让我们的语言面向未来呢？就是说，我们如何有意地设计一种语言，使其能持续存在，并在 20、30 年内都保持活跃呢？


**00:23:10 - Kelsey Hightower**：


使用语言的人，我认为这在开源世界中确实是独一无二的。现在，我们已经不再使用商业语言了，对吧，过去曾经来自微软的语言或太阳微系统的如 Java™ ，那时侯，每个人都依赖于供应商来尽心尽力来对语言能干什么以及对运行时环境进行新的改进。现在，我们看到的诸如 Go、Node.js、Ruby 之类的东西，所有这些都是社区支持的，并且社区专注于运行时环境和语言。这样任何人都可以添加新库，对吧？有一个新的 HTTP 规范，对，HTTP/2 几年前问世了，每个社区都有贡献者添加了那些特定的库，猜猜现在怎么样？所有现在这些语言，都兼容于大部分的未来网站。


**00:24:01**：


我认为现在是个人真正地拥有了更多的控制权，如果他们想让语言适用于新的用例，只需要自己贡献即可。因此，我们不再受限于一两家公司。如果公司倒闭，那么运行时环境可能会因此而消亡。我们不再有这个问题了。


**00:24:23 - Saron Yitbarek**：


我们之前在这个播客上已经说过了。未来是开放的。但是，令人着迷的是考虑怎样能做到再过几十年，过去也将是开放的。它们将继承能够变形和演进的基础设施和语言。


**00:24:39 - Kelsey Hightower**：


太棒了，感谢你的加入，我期待人们的工作，而且大型机仍然有意义。它们是经典技术，因此我们不称其为遗产。


**00:24:47 - Saron Yitbarek**：


哦，我喜欢，经典，非常好。


**00:24:51**：


Kelsey Hightower 是 Google 的开发者推广大使。


**00:24:57**：


我正在想象一个充满经典编程语言以及尚未诞生的新语言的未来。那是我为之兴奋的未来。


**00:25:07 - 演讲者**：


请离关着的门远一点。


**00:25:12 - Saron Yitbarek**：


要知道，2017 年 Andrew Cuomo 州长宣布纽约市地铁进入紧急状态。他的政府拨出 90 亿美元投资于老化的基础设施。这应该提醒我们，迟早我们得注意遗留的系统。你不仅需要继续前进，面向未来。你还背着历史包袱。


**00:25:37**：


在开发的世界中，我们倾向于偏向未来。我们认为我们的语言仅在它们流行时才有用。但是，随着信息基础架构的不断老化，开发的历史变得越来越真实。事实证明，过去根本没有过去。记住这一点是我们的工作。


**00:26:05**：


你可以前往 [redhat.com/commandlineheroes](http://redhat.com/commandlineheroes) ，以了解有关 COBOL 或 Go 或本季我们要介绍的其他语言的更多信息。那里有很多很棒的材料在等你。


**00:26:19 - Saron Yitbarek**：


下一集是关于 Bash 的。我们将探索 shell 脚本的起源以及自动化的关键。


**00:26:30 - Saron Yitbarek**：


《命令行英雄》是红帽的原创播客。我是 Saron Yitbarek 。下期之前，编码不止。



> 
> **什么是 LCTT SIG 和 LCTT LCRH SIG**
> 
> 
> LCTT SIG 是 LCTT <ruby> 特别兴趣小组 <rt>  Special Interest Group </rt></ruby>，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。
> 
> 
> 欢迎[加入 LCRH SIG](/article-12436-1.html) 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。
> 
> 
> 




---


via: <https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect>


作者：[Red Hat](https://www.redhat.com/en/command-line-heroes) 选题：[bestony](https://github.com/bestony) 译者：[messon007](https://github.com/messon007) 校对：[wxy](https://github.com/wxy)


本文由 [LCRH](https://github.com/LCTT/LCRH) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
![](/rhdc/managed-files/img-clh-s3e5-hero.gif)

Languages used for IT infrastructure don’t have expiration dates. COBOL’s been around for 60 years—and isn’t going anywhere anytime soon. We maintain billions of lines of classic code for mainframes. But we’re also building new infrastructures for the cloud in languages like Go.

COBOL was a giant leap for computers to make industries more efficient. Chris Short describes how learning COBOL was seen as a safe long-term bet. Sixty years later, there are billions of lines of COBOL code that can’t easily be replaced—and few specialists who know the language. Ritika Trikha explains that something must change: Either more people must learn COBOL, or the industries that rely on it have to update their codebase. Both choices are difficult. But the future isn’t being written in COBOL. Today’s IT infrastructure is built in the cloud—and a lot of it is written in Go. Carmen Hernández Andoh shares how Go’s designers wanted a language more suited for the cloud. And Kelsey Hightower points out that languages are typically hyper-focused for one task. But they’re increasingly open and flexible.

**00:00** - *Saron Yitbarek*

When the New York City subway first started running in 1904, it was a marvel of the modern age. But ... what happens when today's commuter depends on infrastructure that was designed more than a century ago? Trains are packed and often late. Two billion subway rides take place each year in New York, and nobody's marveling anymore. We are tied to yesterday's crumbling infrastructure, and we have to find smart, new ways to make it work.

**00:44** - *Saron Yitbarek*

It used to be that infrastructure projects were these big, concrete things we could see—that subway, for example. And because of that physical presence, it was also pretty obvious when they broke down. Highways crack, telephone poles fall over. We know when those things need fixing. Big efforts are necessary to get our lives in sync with aging infrastructure.

**01:12** - *Saron Yitbarek*

But things aren't always so obvious. Today we also have IT infrastructure, server farms humming in isolated fields, fiber optic cables spanning oceans, and software infrastructure, too. Like legacy operation system, or shell scripts that nobody dares to replace. When all that IT infrastructure gets old and creaky, we can't see it for ourselves. And yet, the infrastructure that makes today's development work possible is aging, just like an old subway track. And that can mess with our modern lives. Massive new challenges emerge as today's command line heroes work to make sure we're not being boxed in by the past.

**02:02** - *Saron Yitbarek*

This is episode 5 of our season-long journey into the world of programming languages. We're looking at 2 languages that have intimate ties to the infrastructure they were first designed for. COBOL is a language native to mainframe computing, and Go is native to the cloud. They're both deeply influenced by their origins. Understanding that might save tomorrow's developers from ending up like a New Yorker crammed into Penn Station.

**02:33** - *Saron Yitbarek*

I'm Saron Yitbarek, and this is season 3 of Command Line Heroes, an original podcast from Red Hat.

**02:43** - *Grace Hopper*

So many things ahead that we have to do, but we need tremendous amounts of information, correlated, easy to access. We're only at the beginning.

**02:53** - *Saron Yitbarek*

Admiral Grace Hopper pioneered high-level programming languages in the 1940s and 50s. And she was able to make that great leap forward because of the infrastructure of her time, mainframe computers.

**03:08** - *Chris Short*

Hi, my name's Chris Short.

**03:10** - *Saron Yitbarek*

Chris is a principal product marketing manager at Red Hat, and he's a bit of a history buff, too.

**03:17** - *Chris Short*

Admiral Hopper in the 40s made FLOW-MATIC, and she's widely considered the grandmother of COBOL, which was revolutionary at the time. So being able to sit there and say, "Hey, just put it on the mainframe," or, "Hey, just store it on the mainframe."

**03:31** - *Saron Yitbarek*

It was a major game changer. Suddenly, you've got this machine-independent language, COBOL, that's native to the mainframe environment. Possibilities started opening up.

**03:42** - *Chris Short*

COBOL with mainframes really gave every organization the capability to say instead of having a room full of people with pencils, and paper, and calculators, and slide rules, they could just have half a room with a mainframe in it. And then they could have a few people write some applications in COBOL to do all of the math, and logic, and ledgering that their entire finance team could do. So the team of people that you needed to do your finances became a lot less, just because a lot more of the input could be digital as opposed to all hand jam in manually.

**04:17** - *Saron Yitbarek*

If you were one of those new COBOL programmers, it would've felt like you have a job for life. Because the infrastructure that your work was based on, all those mainframes, they weren't going anywhere.

**04:30** - *Chris Short*

Moore's Law wasn't around back then, so you could go an entire decade working on the same mainframe, potentially, right? Like you didn't have to worry about the next operating system, or the next type of container orchestrator, or the next thing that comes along and AI, or whatever. You could probably spend your whole career working on COBOL. And you knew you were going to be pretty safe.

**04:55** - *Saron Yitbarek*

But, Moore's Law did arrive eventually. New infrastructures showed up, too. And these days, programmers are less likely to learn a half-century old language. But here's the thing, those old mainframes aren't actually gone. And that means our need for COBOL developers hasn't vanished either.

**05:17** - *Chris Short*

It's getting a lot harder to find COBOL developers. What ends up happening is these mainframes have been here for 50 years, potentially. And these COBOL developers that still can write good COBOL will get paid exorbitant amount of monies to help with projects, and reorganization of data within mainframes. And that skillset is definitely dying off and becoming a highly lucrative career field if you ... you can definitely make a lot of money writing COBOL nowadays.

**05:49** - *Saron Yitbarek*

Especially in the manufacturing and finance industries. You can't outrun all that infrastructure that was laid down decades ago. Legacy code permeates work all around the world. It'd be a huge mistake to ignore that old infrastructure and the languages tied to it.

**06:08** - *Chris Short*

With 200 billion lines of code laying around, it's going to be really hard to refactor all that. No, I don't think we'll ever see it disappear in our lifetimes, for sure.

**06:21** - *Saron Yitbarek*

Chris Short is a principal product marketing manager at Red Hat.

**06:28** - *Saron Yitbarek*

I want to drive Chris's point home for a sec. Consider this. COBOL is baked into 95% of all ATM transactions. That's how tied we are to this language. And yet, the average COBOL programmer isn't much younger than the language itself. They are 45, maybe 55 years old. The newbies aren't interested. Which is why I want to introduce you to someone.

**06:56** - *Ritika Trikha*

Hi, my name is Ritika Trikha.

**06:59** - *Saron Yitbarek*

Ritika's a technology writer, formerly with HackerRank. And she's fascinated by this question of COBOL, and the assumption people make that it's a kind of pointless leftover from the mainframe days.

**07:12** - *Ritika Trikha*

Developers today are really not thinking about COBOL, it's out of sight, out of mind.

**07:17** - *Saron Yitbarek*

But that could be a recipe for disaster.

**07:21** - *Ritika Trikha*

There's a huge volume of COBOL lines of code that are still powering businesses today. At least 1.5 billion new lines of code in COBOL every single year. And I think when you look at the specific industries, it's really interesting. Like there's 50 million lines of code at the IRS. There's 60 million lines of code at the Social Security Administration. And so these businesses and entities are handling some of the most sensitive, important information today, and if we don't continue to power and maintain these mainframes, it could be really destructive.

**08:04** - *Saron Yitbarek*

So if we can't escape our old infrastructure, and we can't wave a magic wand to rebuild the whole mainframe universe, what do we do? How do coders, who sometimes only think about the future, start coming to terms with the past? We need to start by facing the problem head on.

**08:25** - *Ritika Trikha*

You know, younger generations are going to have to pick up these skills. Or, there has to be some sort of modernization of these mainframes. Either way, this problem isn't going to go away. That's why COBOL is relevant.

**08:35** - *Saron Yitbarek*

It's not going to be easy. Ritika figures we've ignored the problem for too long already.

**08:42** - *Ritika Trikha*

It's incredibly expensive, hard, and the risk is incredibly high to replace billions of lines of COBOL. It's mission-critical code like Social Security and financial information. And COBOL was specifically designed for these types of large volumes of transactions. So it was designed for business transactions by Grace Hopper in the 60s. And “if it's not broken, why try to fix it” has been the mentality since the 60s, and now we're at a point where we just have decades of very valuable, high volumes of data running on COBOL.

**09:22** - *Saron Yitbarek*

In a way, Ritika's calling for a cultural shift. A change in attitude about what's in and what's out. As the world of development starts to actually gain a deeper and deeper past, we have to become more in touch with our own history. You can't escape the aging infrastructure. And that means you can't ignore the history of languages either.

**09:47** - *Ritika Trikha*

Something has to be done. When I was at HackerRank, I saw firsthand how many banks and financial institutions are hurting, and desperate almost, for COBOL developers. It's not a problem that's going to go away, and I think either there has to be some sort of modernization of the systems, or we need to keep training folks and incentivizing it. I personally think there's going to be a day where COBOL is actually in again. Really, what's going to happen when all of the developers with COBOL knowledge retire, and no new younger generations of developers are learning COBOL? Something has to give, right? So there needs to be more of a systematic and institutionalized change when it comes to shifting away from COBOL and into the new cloud-based infrastructures.

**10:37** - *Saron Yitbarek*

Ritika Trikha is a technology writer based in San Francisco.

**10:49** - *Saron Yitbarek*

So what about those cloud-based infrastructures Ritika mentioned? Are the infrastructures we're building today going to chain future generations to particular languages, the way we're still tied to COBOL? Amazon Web Services (AWS) may be the biggest single piece of cloud infrastructure, launched in 2006. Google Cloud Platform arrived in 2008, and Microsoft Azure started in 2010. The Go language, with its focus on concurrency, was made to thrive inside all that new cloud infrastructure. It's a language of its time.

**11:26** - *Carmen Andoh*

Hi, my name is Carmen Andoh, and I am a program manager for the Go team at Google.

**11:34** - *Saron Yitbarek*

Carmen has an insider's understanding of how Go is tied to today's infrastructure. It starts with the creators of Go having some strong ties to the history of languages.

**11:47** - *Carmen Andoh*

Robert Pike, Robert Griesemer, and Ken Thompson. Those names have kind of come through ever since the 1960s. So Ken Thompson invented the programming language B, and then he would go on to invent the UNIX operating system on a summer off. And Rob Pike invented UTF-8, which is a string in coding. He also invented ASCII. He helped co-author the UNIX programming environment. So these two had been coworkers for a very, very long time, and they had been looking at and inventing operating systems in previous programming languages, including C, which Ken Thompson would eventually help write with Dennis Ritchie.

**12:28** - *Saron Yitbarek*

Once Pike, Griesemer, and Thompson were all working at Google, they discovered a serious problem. Getting concurrency at scale just wasn't happening. People were waiting hours for a bill to compile. They were working in C++, and had to write all these callbacks and event dispatchers. It was 2009, and our infrastructure was changing again. Languages like C++ were becoming less and less in tune with that new reality.

**12:59** - *Carmen Andoh*

The problems were being introduced by things like multicore processors, and network systems, and massive computation clusters, and the web programming model. And then, also, just the growth of the industry and the number of programmers which were going into the thousands and the tens-of-thousands by 2010. And so all of the programming languages up until that point were being worked around, rather than addressing things head on.

**13:24** - *Saron Yitbarek*

Eventually, you reach a breaking point and something's got to give.

**13:30** - *Carmen Andoh*

Hey, we hated C++ and I said, "Well, let's see if we could invent something new."

**13:37** - *Saron Yitbarek*

That new language would need to be exquisitely adapted to our latest infrastructure.

**13:43** - *Carmen Andoh*

What happened with the cloud, which was starting to come of age in 2005, was that you now no longer had to handle your own computes, you sort of were renting it elsewhere, and you get a distributed system. But what happens in a distributed system, and in a cloud, is that you have problems of concurrent messaging between distributed systems. You need to make sure that you have no problems with asynchronicity. Go is a programming language that is asynchronous by default. Basically this means that every operation you perform, like sending all these different messages to another in the system, it's done without waiting for the other system to respond back to you. So it can handle multiple messages at any given time.

**14:28** - *Carmen Andoh*

And that said, cloud computing is distributed. And so Go was developed to address this exact need. Go became, early on, one of the standard ways of doing this kind of distributed computing. And that's why I think that it picked up a lot of the developer mindshare immediately. Go absolutely is the language of cloud infrastructure, both in its design, but also in the ecosystem of all the cloud infrastructure tooling, and building blocks that have sprung up in the last decade.

**15:06** - *Saron Yitbarek*

Soon, major applications like Kubernetes were being written in Go. Google also created Go Cloud, an open source library and set of tools that made Go even more attractive. It became clear, this was the language of a brand new ecosystem. It was the language of the cloud. And it definitely didn't hurt that the creators had reputations for developing languages that lasted.

**15:33** - *Carmen Andoh*

I think that the rest of the industry said, "Hey, I don't think that this is going to be going away anytime soon," and the inventors of the language also happen to invent languages that are now in their 50th year, or 60th year.

**15:47** - *Saron Yitbarek*

Carmen Andoh is a program manager for the Go team at Google.

**15:54** - *Saron Yitbarek*

So we have a new language, Go, designed to deliver the concurrency that cloud infrastructure makes necessary. Sounds great. And Go’s designers tend to create languages that last for a good half century. Also great. But my question is, what will that really mean 50 years from now when Go is more like COBOL? What will it mean when the world is teeming with legacy Go code that only older developers understand? Are we going to be prepared for a time when today's cloud infrastructure is aging? Are we learning lessons from COBOL and the world of mainframe that could help us design a better future for Go and the cloud?

**16:40** - *Saron Yitbarek*

Luckily, I found exactly the right person to ask all these questions. And that's next.

**16:51** - *Saron Yitbarek*

How do we future-proof our languages? We know they're tied to the infrastructure of their day. And we know that new infrastructures are bound to replace the old ones as decades roll by. So what are we doing today to keep things running smoothly tomorrow?

**17:10** - *Kelsey Hightower*

I'm Kelsey Hightower, I'm at Google, I'm a developer advocate and I work bringing open technologies and turning them to products on Google Cloud.

**17:19** - *Saron Yitbarek*

Kelsey spends a lot of time thinking about the future of programming. I was curious whether one day we're going to end up with another aging group of programmers with these wizard-like skills around Go, the same way we have a shortage of COBOL wizards today. Are we even planning for that long range future? So Kelsey and I sat down to hash it out.

**17:42** - *Kelsey Hightower*

... and so forth. But if you think about some of the new challenges today, things like dealing with the internet, the network, you've got multiple users, hundreds of thousands of concurrent users, different collections of machines and architecture types. So given those new use cases, typically you want to have a new language. For example, JavaScript is for the web, you don't want to retrofit COBOL so that we can start doing web programming with it. So we have hundreds of languages that are out and pretty well established today, and they're all kind of hyper-focused on their sweet spots.

**18:15** - *Saron Yitbarek*

So in that case then, do we need to actively push people towards COBOL? If we're developing these new languages for these new problems and they're highly specialized, and COBOL's still sticking around, do we need to encourage folks to pick it up so we can maintain our legacy code?

**18:32** - *Kelsey Hightower*

Well, I think that's going to be a challenge for the enterprise, right? So you've invested 10, 20 years in COBOL, and there is no one actively thinking about learning some new COBOL. Or you don't come out of college just like, "I'm going to double-down..."

**18:45** - *Saron Yitbarek*

Right.

**18:46** - *Kelsey Hightower*

"...on this language that's older than my parents." So in that world, you have to ask yourself, what is the risk of continuing on with COBOL? Is it still relevant going forward? I think it is still relevant for certain types of workloads, but we have to ask ourselves a question, is it time to progress? Is it time to evolve a little bit? So if you still have billions of lines of COBOL, you're in the situation where you're going to have to try to find all the COBOL talent that's remaining and bring them in house, but maybe we start to think about what can other languages learn from COBOL, and incorporate some of that functionality and libraries into other languages.

**19:26** - *Saron Yitbarek*

Life after COBOL, that would be an enormous infrastructure project all on its own. To use my New York subway analogy, it'd be like replacing every underground tunnel. So, going forward, I wanted to know whether we could anticipate those issues, and even do our future selves some favors.

**19:48** - *Saron Yitbarek*

If we compare the cloud today to mainframes, are we going to end up in the same boat where we have these legacy code bases that are using kind of old but very stable languages, and we have to kind of reach this new point of figuring out if we should move on or stay the same?

**20:05** - *Kelsey Hightower*

So the thing that makes the cloud a bit different, it's not from one manufacturer, right? A lot of cloud providers typically bundle up collections of technology so you have your choice of programming language, you have your choice of programming paradigm, whether you want to event-driven, or it's all web services based on [HTTP]. So what that means is you get to choose what you want to program in, and just kind of focus on what gets solved. So data will come in, data will come out, but you choose how you want to process that data.

**20:36** - *Kelsey Hightower*

The mainframe typically just kind of had one main interface, right? Like you write this job, and this is how you submit the job, here's how you monitor the job, and here's where it comes out. So that's very limiting of itself. So if you think about some of the newer mainframes, they also support some of the newer technology, so even in the world of mainframe, you start to see the expansion of programming languages you can use to run your jobs.

**20:58** - *Kelsey Hightower*

So then we start to ask ourselves, okay, given that I have my new choice, when is it time to move on from this particular programming paradigm? So I think we don't get stuck.

**21:08** - *Saron Yitbarek*

Right.

**21:08** - *Kelsey Hightower*

But I think it is going to be nice that there's going to be a new machine that's going to be distributed, maybe there's a lower cost of entry, you don't have to buy the whole mainframe to get started. But we still want that ease of use of here's my job, you run it for me, tell me when it's done.

**21:24** - *Saron Yitbarek*

Absolutely. Do you see what's happening, or what's happened to COBOL, happening to any of today's languages? Like for example, Go, do you see us struggling to maintain Go and getting folks who want to write Go in 30 years?

**21:38** - *Kelsey Hightower*

I think all languages can suffer that fate, right? So if you think about it, Python's been around for a very long time. I think it's, what, close to 20 years if not more. So I think what happens ... and Python's had a resurgence in its usage, right, it's kind of the foundation of language for machine learning.

**21:53** - *Saron Yitbarek*

Yep.

**21:54** - *Kelsey Hightower*

For libraries like Tensorflow. So if we use just time alone, I think that's probably not the right way to look at it. It's like how relevant is that community? How relevant is that language willing to adapt? And I think what Python did really, really well, it ... that community saw the ability to make other languages easier to use. For example, Tensorflow's a lot of C++ underneath it, so programming in such a language is probably not as user friendly as something like Python. And you could take Python and use it to generate some of the stuff that people are using for, example, Tensorflow. So now that machine learning is hot, people have brung Python into that new space, so guess what? Python continues to be relevant, and will be relevant for some time to come. And the same thing's going to be true for Go. If Go can continue to be relevant, right, it's like at the foundation of many of our infrastructure tools, many of the cloud libraries, it too will remain relevant. So I think it's all about those communities ensuring that they have a place in the future, and when the future shows up, making sure that they have a story there.

**22:58** - *Saron Yitbarek*

Yeah. So how do we future-proof our languages? Meaning, how do we intentionally design a language to make it last, and make it relevant 20, 30 years from now?

**23:10** - *Kelsey Hightower*

The people that use the language, so this is something that's really unique I think, in the open source space. Now that we've moved away from commercial languages, right, languages used to come from Microsoft, or Sun Microsystems in the case of Java™, and at that point everyone relied on the vendor to do all the heavy lifting about what the language would be able to do, any new improvements in the run time. Now what we see with things like Go, Node.js, Ruby, all of these are community backed and focused runtimes and languages. So anyone can add new libraries, right? There was a new [HTTP] spec, right, [HTTP/2] came out a few years ago and each of the respective communities just had contributors add those particular libraries, and now guess what? All of those languages are now compatible with the future of the ... kind of the web for the most part.

**24:01** - *Kelsey Hightower*

So I think it's really now that individuals have more control if they want their language to be relevant for new use cases by just contributing that functionality themselves. So we're not restricted to one or two companies. If the company goes out of business, then maybe the runtime dies with it. We don't have that problem as much anymore.

**24:23** - *Saron Yitbarek*

We've said it on this podcast before. The future is open. But it's fascinating to consider how in another couple decades, the past will be open too. They'll be inheriting infrastructure and languages that are able to morph and evolve.

**24:39** - *Kelsey Hightower*

Awesome, thanks for having me, and I look forward to what people do and mainframe is still relevant. So we don't call it legacy, these are classic technologies.

**24:47** - *Saron Yitbarek*

Ooh, I like that, classic, very nice.

**24:51** - *Saron Yitbarek*

Kelsey Hightower is developer advocate at Google.

**24:57** - *Saron Yitbarek*

I'm imagining a future that's rich with classic programming languages, along with new languages that haven't even been born yet. That's a future I'm excited for.

**25:07** - *Speaker*

Stand clear of the closing doors, please.

**25:12** - *Saron Yitbarek*

You know, in 2017 Governor Andrew Cuomo declared a state of emergency about the New York City subway. His government set aside 9 billion dollars to invest in the aging infrastructure. And that should remind us, sooner or later, we have to take care of the systems we inherit. You don't just race onward to whatever comes next. You bring the past with you.

**25:37** - *Saron Yitbarek*

n the world of development, we tend to have a bias towards the future. We think our languages are only useful in the moment, when they're the hot new thing. But, as informational infrastructure continues to age, the history of development becomes more and more real. The past, it turns out, isn't past at all. And it's our job to remember that.

**26:05** - *Saron Yitbarek*

You can learn more about COBOL, or Go, or any of the languages we're covering this season, by heading over to [redhat.com/commandlineheroes](//www.redhat.com/en/command-line-heroes). There's a bunch of great bonus material waiting for you.

**26:19** - *Saron Yitbarek*

Next episode is all about Bash. We're exploring the origins of shell scripts, and the key to automation.

**26:30** - *Saron Yitbarek*

Command Line Heroes is an original podcast from Red Hat. I'm Saron Yitbarek. Until next time, keep on coding.

### Keep going

### The Infrastructure is Code: A story of COBOL and Go

COBOL was, and still is, the dominant language of mainframes. What can Go learn from its history in order to dominate the cloud?

### Go on Red Hat Enterprise Linux

Get started with Golang on Red Hat Enterprise Linux. Check out this article for instructions and links to more resources to learn more about Go.

### Enjoy this episode's artwork on your device

Download the Command Line Heroes artwork and set it as your background.