ola等对d的观点

布满荆棘的人生 2023-01-22 09:51 10阅读 0赞

## `dmd`应该有个`选项`,否则无法吸引`关注性能`的人.   标准库,与`生成代码/操作系统`有关,我不评价.有点像`编译器`的`后端/运行时`.有特色很正常.   `long[string]`应该是`std.xyz.Map!(long,string)`的缩写.`语言设计者`应尽量`使用`语言特征集,否则,无法正确作出决策.   `哈希`策略,需要`上下文`.`d`需要更好的`元编程`.`哈希字面`应绑定至`可哈希`.应由`库`来构造.   `黄金准则`:`语言`中不应该`添加库可实现`的东西.尽量要`小而精`.`特例`对`元编程`不友好.   `关联数组`应,用`库`来实现,`关联数组字面`用`自定义AA`来工作.   `缓存`可修复`编译时间`.多利用`领域特定语言`.`go`比`rust`更流行.`rust`是由`系统`编程来吸引人的.   `最佳方案`是`降低特性集`并改进`元编程`,增加`特性`有实验性质.没必要样样学`其他语言`,他们有他们的`理念`.   先`修复类型统一`,但要处理`终止(类型)`.`基于任务的`垃集可在`完成时`调用`析构器`.`火卫一单独不大,但第三方`可能有问题.   `垃集运行时接口`不好,在`暂停点`基于任务的应是`无栈`的.但在`挂起-释放`时用了`系统栈`.因而有`大量挂起任务`,还需要`合并垃集堆`.这样,你可以`聚集因并行而分开的任务`.   你可像`c++`用`灵针`,但不像`c++`处理`arc`在`llvm ir`前注入`新ir`,而对`arc`的灵针用`编译器内部函数`.   `共享`语义是错的,因为不安全.未给定`完整`方案就给出`语义`,因而不能`发展`并行`设计`.`字节`依赖`转换`.   要`通用`的话,要减少`使用`后端特征.   `栈元信息,挂起点等`依赖`编译器`.`共享`应该是`任务`间,而不是`线程`间.   `没有工作组`.`d`的`特性集`是`实验`出来的.所以`最好多用`,经常用,就会`暴露`错误.   需要用`rc`来写库,可`自由`转换为`gc`.写`析构器`,清理`基本`.测试`混合`.还要有`精确垃集`.还可用`绑定任务的垃集`.`dmd`应用`推荐的系统编程管理准则`.   我在想,`目标类型`可`传递和消费`的`编译时类型字面量`.也可`编译时前向区间,生产<键值>对`.   `后台`不应`浪费内核和硬件资源`.`应用程序`不能乱搞.   `获取超过需要的资源`的应用都是在`乱搞`.   如果,没有同`内存管理`打交道,则不可能有`改进`.   如果,你有`系统编程`的合适方案,则`管理内存`不难.如果`d`管理不好`dmd`,则`d`管理不好系统级编程.   `垃集`不适用`所有情况`.   `用户`会看`编译器如何使用这些特征`.   不难`管理内存`.你要经常使用自己的工具.然后别人就会跟着你用.`全局泵`分配器是`另一个泄露之源`.`dmd`自身没有`垃集`,就说明了问题.   `减少功能/改进元编程`,缺少的在`库`中实现.可合并`部分特征`,如`枚 常量/别名`.   `跟踪栈`,用`类型系统`避免`错误`.   用`指针`指向`不变`不稳定,最好用`标签联`.   我在想优化`工具函数`. ##

另一个:`russhy`:  
在`垃集`上下功夫的,因为`d的垃集`不能`规模化`.  
在`微服务/可伸缩网络应用`时代,`托管语言`不能`规模化`,`d`最好与`c/c++`搭配.  
所有好生态,都`围绕`着`系统库`.  
`一切都强制围着垃圾的垃集转`.  
用`虚幻`,你不必用`垃集`.  
`D+core.stdc`是`D`最好版本.加上`特征/签名`系统,和`ARC/RC`,就很实际了.不值得为`垃集`浪费时间.  
`苹果在swift上用RC`,`d`内存所有权和`引用计数`.