是不是如果一种编程语言能直接操纵内存，它就能用于写出高性能需求的软件，否则，就只能写性能要求不是特别高得应用层软件？

语言越底层越相当于直接与硬件打交道，逻辑处理就越复杂，人脑也就越难胜任这个工作，除了性能，效率、安全、测试、工程化等同样重要，而这些要求大多与直接操作内存的方式相悖，现代高级语言基本都朝这些方向发展。所以未必不让直接操作内存的语言就写不出高性能的软件，而可能是把内存操作的细节给封装起来了，现代编译器大多优化得足够好，编译出来的底层代码未必比普通人写的性能差。所以，能不能直接操作内存不是考核能否写出高性能软件的前提条件，不然现代语言就停留在汇编、C 就好了，而真正能不能用好语言、选择合适的语言干合适的事情才是最重要的，毕竟代码都是人来写的~

不是，决定性能的永远是算法和思维，计算机任何问题都可以通过增加一个中间层来解决，你完全可以写一门语言来编译成另外一门语言

大致上是的，但是与硬件成本有一定的关系，现在硬件资源成本低，连 Electron 写出来的软件用户也有不少接受了，你看跨平台软件这里很多动不动就推广 Electron 开发，对于中高配的电脑这不是什么太大的问题，不就吃点内存和浪费点硬盘空间，开发速度快，你用底层语言框架还没撘记起来，人家开发完了，当然这是无视中低端设备用户的情况下。
语言也就没有那么重要了，手机上以前塞班时代编码用 c++，申请内存的字节数都是精准控制，到安卓时代的 Java ，到处随便分配内存，开发者大多数都对内存管理没有良好习惯，Activity 都销毁了，还一堆资源没有释放，各种内存泄漏太严重了，包括各个大厂的应用，经常 gc 到生活不能自理，但是你回过头看同样 Java 的 J2ME 软件，内存控制也一点不差。

理论上任何语言都能做编译好的库函数的 binding ，然后写出高性能需求的软件[滑稽]

认真点讲，你说对了一半，因为光能操作内存还不足以高性能，还需要语言根据平台指定 SIMD 指令等特殊硬件优化，并且语言还要尽量防止发生 mem alloc ，差不多就实现一般意义的高性能了。

这两件事情之间没什么特别大的关系。

除开汇编，任何语言的执行要么通过编译器编译到机器指令，要么通过解释器解释执行，包括楼上所说的各种硬件特性，也是编译器能够生成这种形式的机器码，跟语言本身没啥关系。

换句话说，编译器优化的极限决定了语言性能的上限，你拿一个玩具编译器去编译 C 代码，也跑不过 cpython 解释执行的 python 代码。

而一个基本的结论是，动态特性的使用跟优化效果成反比，跟执行时的负载成正比。

举个例子，如果 C 语言现在改成函数调用必须使用函数指针实现，不允许直接调用函数名，并且这个指针变量必须得是全局的。那么意味着所有 interproduce optimization 、inline 、link time optimization 都不起作用了，其他 DCE 、GVN 之类的优化也将受到巨大限制，性能下降百倍起步。

反过来，如果对 python 做出各种限制，比如不允许使用继承、一个变量只允许一次赋值等等，然后为这个受限制的 python 再实现一个编译器，那么完全可以获得跟 C 语言在大部分场景下相似的性能，即便它不能手动 mallco/free 。

rust