Jör*_*tag 15
有很多语言是明确设计的,以适应所有这些利基:
有趣的是,还有一些语言没有专门设计来填补这个利基,但是已经非常成功地用于这个领域:
还有很多语言还没有在那个利基中使用,但肯定可以.(主要是因为那些语言社区本身已被"你只能在C语言中编写操作系统"所欺骗,他们实际上认为他们自己的语言无法使用.)
[请注意,对于我列出的三个类别中的每一个,实际上有数千种语言适合那里.]
事实上,人们有时会觉得那些不是专门为操作系统编程而设计的语言实际上更适合这种事情.例如,比较创新水平,稳定性,安全漏洞数量,性能,如20世纪70年代的Smalltalk OS和2010年的Windows或OSX.
就个人而言,我认为这是基于系统编程社区中的一些根深蒂固的神话.他们认为用一种语言进行系统编程,比如强类型,类型安全,内存安全,指针安全,自动存储管理是不可能的,获得性能或实时保证的唯一方法是放弃强大的抽象设施.然而,事实证明,当你尝试为人而不是机器设计编程语言时,人类实际上可以理解他们编写的程序,找到安全漏洞,修复错误,并在1行monad理解中更好地定位和修复性能瓶颈而不是100行的循环.
例如,SqueakNOS是Squeak Smalltalk系统的一种变体,它在没有操作系统的情况下运行(换句话说:它是操作系统)具有您期望从现代操作系统(图形用户界面,...)中获得的所有功能. .)加上一些你没有的东西(嵌入式脚本语言可以在运行时修改操作系统的每一部分),重量仅为300k SLOC,并在不到5秒的时间内启动,而Windows重量为5000 万 SLOC.
是否有任何提议或实现的语言适合与 C 相同的（巨大的）利基市场，旨在成为替代方案，同时保持对操作系统、高性能、嵌入式和其他角色的所有适用性？
操作系统历史上是用汇编程序实现的。后来开发转向 C，它最初是一种宏汇编程序。
现在大多数操作系统主要用 C 编写，因为它几乎是唯一保持某种汇编程序向后兼容性的语言（例如，可以将硬件规格中找到的汇编程序一对一映射到 C）。libc 是内核和用户空间之间的主要接口 - 通常是唯一的接口。然而，该接口并不能涵盖所有内容：由于尚未提供标准接口，因此必须直接访问内核中的某些内容。例如，必须使用 C 结构体向 ioctl 传递参数/从 ioctl 检索结果。
这意味着在应用程序开发中使用 C 很大程度上是由一个简单的事实推动的：如果您使用 C，您就可以自动访问也是用 C 编写的内核 (OS) 的所有功能。
唯一能够以某种方式与 C 竞争的语言是基于 C/与 C 兼容的语言。我知道的唯一替代方案是 C++。以前也有比较流行的翻译器，比如p2c（Pascal to C）：用一种语言开发程序，但源代码会自动翻译成C进行编译。但翻译器有很多错误，如果不了解 C 语言，程序通常无法调试。因此，如果您无论如何都必须了解一些 C，为什么还要费心翻译呢？
我个人（我确信还有许多其他开发人员）使用各种语言经常偶然发现操作系统具有功能的问题，但所使用的语言不提供任何访问它的设施。我认为这是其他语言发展的主要阻碍因素。即使你对一种新语言有一个聪明的想法（这可能与 C 不兼容，否则这个想法就不会那么聪明），你最终还是要承担重新实现几乎整个操作系统的接口的负担（以及各种必须的）有应用程序库）。
只要 (1) C 仍然是系统编程的唯一语言，并且 (2) 操作系统接口仍在不断发展，那么应用程序开发另一边的所有非 C 兼容语言都将处于更大的劣势。
PS 实际上，这是我希望LLVM / clang能够打破的模式之一。clang 被实现为一个可重用的库，理论上允许混合语言。例如，主源文件可以是一种语言（并由一个前端解析），但#includes 可以是 C 语言（并由 clang 解析）。