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内存所有权和引用计数.
