我认为此屏幕截图实际上是对生产率的一种衡量，足以传达本文的含义，但是如果读者对我对这个问题的想法感兴趣，那么欢迎您。
程序员沉迷于程序执行的速度。 即使速度不是很重要，我们也会监控速度。 有时有悖常识和逻辑。 在每种情况下，甚至都无法完全理解“速度”或“性能”一词的真正含义。 我们仍然需要最快的硬件，最快的语言和最轻便的框架。
我乐意相信您（用户名）不是那样。 您自己能够编写正确的基准测试，您知道运行时的运行方式，您讨厌出于速度优化的目的而进行速度优化，并且对硬件非常了解。 但是上一段还有更多人。 已检查。
看上图的例子，我首先first咖啡...
-打字稿如何能比javascript更快地工作，并且同时消耗更少的内存？
-不行！
Typescript没有自己的运行时。 也就是说，您无法在任何地方或几乎任何地方运行打字稿。 您必须首先将其编译为javascript，然后在该javascript理解的运行时中运行。 在这种情况下，节点v11.3434充当了这样的运行时。 巧合的是，该javascript示例还在同一运行时上运行。
与其比较语言，不如通过体育比赛进行微竞赛。
→ 打字稿代码
→ JavaScript代码
事实证明，运行时，内存消耗和其他特征严重取决于谁编写此验证代码以及如何编写。 当然，在这里您可以抓住打字稿迫使您编写“正确代码”的论点。 但是没有人愿意用javascript编译打字稿，而且我也没有看到有优化的地方。
顺便说一句，您看到某人写了类似的代码多久了，并且经过了审查？ 固体，OOP和FP在这里没有气味。 该代码以过程样式明确编写。 因为他有不同的任务。 正确理解，尽管代码可以解决问题，但仍需要在生产之前进行重构。 而且，重构将如何影响性能还不得而知。 但这可能是挑剔的事情。
我们找到一个例子。 显然，这个例子是不够的。
但是，让我们看看其他编程语言如何通过相同的测试。
您如何看待，得出Swift比Go更快的结论是正确的？ 我认为那是错误的。 足以看到两个Rust实现（第2行和第6行）的时间相差2倍。
这里的问题已经看起来更加严重了。 如果将打字稿和JavaScript进行比较被视为一个笑话，那么在其他语言的情况下，问题就不会那么明显了。 如果看到这样的报告，您是否会开始理解是怎么回事？
事实证明，基准代码需要受到密切监视。
问题：您什么时候最后一次看到一个人，在看到标准的漂亮性能图后，它正在仔细检查基准代码的编写方式？
我很少遇到这些。 我认为这样的工程师很少。
另一方面，在我眼前有很多例子，这些例子基于这种测试得出了该技术的性能和轻便性的结论。 顺便说一下，正在形成舆论。
在这里，您可以比较主要javascript框架的性能。
您仍然相信结果吗？ 我不知道
仅此而已。 但是有个好消息。 程序员的技能仍然是影响程序性能的主要因素。
结论：
除非您是特定平台的性能专家，否则微基准测试不会向您显示任何内容。 更好的是，您自己在完全了解自己的要求和条件的同时编写这些基准测试，同时了解自己在做什么。
PS：
撰写该帖子是为了对仓促比较和有关未来生产力的结论做出回答。 当然，没有此示例也可以给出本文的所有结论和论点，但是带有数字和细节将使其更加有趣和清晰。