- 主题:【转】微软正从 C/C++ 改用 Rust 来构建其基础设施软件
好些人就当真的。。很尬
【 在 z16166 (Netguy) 的大作中提到: 】
: 是宇宙第一IDE，也是调侃的
: 记得vs2015从sp2似做了大的改动，特别是模板编译。所以用vs 2019的编译器是最好了，守着2015不划算
--
FROM 112.47.122.*
java 和 python 程序员体会不到啊。至少得加个 C++ IDE 的定语吧。
而且 C++ 的 Eclipse/Clion/QtCreator 也不错，各有所长。我记得 vs 以前不能在编辑器提示警告，也不能按一下回车自动修改错误。现在不知道可以了没有。
【 在 Knightmare (梦醒时分) 的大作中提到: 】
: ide方面也就idea能竞争一下吧？
: 第一ide也不是很夸张
--
FROM 110.81.12.*
支持 python 了？能自动完成和重构吗？
唉，巨硬早干嘛去了。
【 在 Knightmare (梦醒时分) 的大作中提到: 】
: 现在vs2019支持python，而且支持的很好，我感觉是所有ide里最好的。
: 智能更正也有的，vs现在做的确实挺好了，就是忒大了
--
FROM 110.81.12.*
rust 主要是内存管理的创新。。就这样子足以带来安全编程的革命？不太相信啊。rust 能够防止内存被多次释放以致崩溃，但是能够防止长时间运行的内存泄漏吗？
【 在 liaotianxia (liaotianxia) 的大作中提到: 】
: Levick表示，安全编程的这种能力不应该被轻视。实际上，它可以带来逾10倍的提升，因此值得投入心血。这主要是由于几乎所有的C/C++代码都需要接受安全审计、查找有无不安全行为，而用Rust编写的需要接受检查的不安全代码只是大多数代码库的一小部分。
: 虽然微软看好Rust，但Levick 承认微软核心开发人员短时间内不会停止使用C/C++。
: 他说：“我们微软有很多的C++代码，这些代码不会被抛弃。实际上，微软在继续用C++编写代码，会继续用它编写一段时间的代码。”
: ...................
--
FROM 110.81.12.*
gc 也没什么卵用。我以前犯过一个错误，java 的数据库连接忘了释放，报销了公司十几万营收。
【 在 superisaac (宅男总动员) 的大作中提到: 】
: 那带个GC不更香吗？
--
FROM 110.81.12.*
因为缺少一个适合业务编程描述能力强的静态语言啊。
swift 原本是一个选择，但它爹苹果不被社区认同。julia 和 crystal 或许能有机会。
【 在 ilovecpp (cpp) 的大作中提到: 】
: 正常。
: Rust作为更加强化类型系统的C++，即使在C++程序员中间也应该只合一小部分人口味。现在已经是过热了。
: 用类型系统来搞内存管理也是非常规的做法，不容易做得简单和容易理解。
: ...................
--
FROM 59.60.54.*
unsafe 的情况比较少，只是底层库需要。。
我的想法是新语言，都在编译器直接支持 c 语言的语法就行了。所有 unsafe 的东东，都在 c 语言里面实现，不是更简单么。完全可以在 c 里面实现链表，然后 rust 里面:
use c.unsafe_func;
use c.linked_list;
很简单的嘛。
【 在 Jacqueline (花仙子◆唯有低贱，或能长存-M.J.<二月兰>) 的大作中提到: 】
: 这些个现代语言遇到需要效率的场合全都得unsafe或者搞各种脏技巧，
: 写着写着就发现，我干嘛不用C++！
--
FROM 59.60.54.*
首先呢，，新语言的编译器不再是简单链接 c 语言了，而是真的就是 c 语言编译器。能够分析 c 语言的执行流。我们只是借用 c 语言的语法来做 unsafe 编程。
其次，标注语法可以在 c 语言里面加。把这个 c 语言定位为依附主语言的 unsafe 专用语言。避免主语言的语法被污染。
总之，丑的都归了 c 语言。于是乎，我们全力做美的语言就行了。
【 在 ilovecpp (cpp) 的大作中提到: 】
: 调用C函数在各语言里都不难。不过也不可能像你写的那样，因为C函数签名缺少lifetime标注，也不区分owner/borrow，必须在Rust代码里加上。
: 数据结构是不可能的。C++都不可能去用C写的链表，更别说其它语言了。跨语言链接，没有编译器优化，效率不可接受。只有.net有多语言公用数据结构。
--
FROM 59.60.54.*
我想可以这样做：
1. 新的 c 语言可能是特别的 c 语言，比如它可以理解宿主语言(rust)的类型:
rust_int32 sum(rust_int32 *array, int32 n);
rust_str concat(rust_str s1, rust_str s2);
void set_property(rust_str moved_s1);
但这样子破坏了兼容性。这样子写出来的 .rustc 文件不能被普通的 c 编译器编译了。
2. 是否要支持编译现有的 c 语言库 libcurl 什么的？还是只编译这些特别语法？我觉得仍然可以支持现有的 c 库，只要我们仍然支持 int/char 这些原始的类型就行了。
3. 是否提供和系统 c 库一致的环境，比如这个 c 语言的 sizeof(int *) 是否要等于系统的 sizeof(int *) 也是可以讨论的。有两种选择，规定 sizeof(int *) 永远是 64bit，这样子指针操作可能不原子。也可以规定和系统一致，有效率，但编译器实现可能会很复杂。
4. 本质上，这个 c 语言已经是原版 c 语言的超集了。但只是简单增添数据类型和标注，比 c++ 那种超集简单一万倍。比 opencl c 还简单。
5. 最大的问题是一个编译器两种语法，很多人难以接受。如果实在要一个语言两种语法，也只有 c 语法可以接受，其它语法我都接受不了。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 首先呢，，新语言的编译器不再是简单链接 c 语言了，而是真的就是 c 语言编译器。能够分析 c 语言的执行流。我们只是借用 c 语言的语法来做 unsafe 编程。
: 其次，标注语法可以在 c 语言里面加。把这个 c 语言定位为依附主语言的 unsafe 专用语言。避免主语言的语法被污染。
: 总之，丑的都归了 c 语言。于是乎，我们全力做美的语言就行了。
: ...................
--
FROM 59.60.54.*