d用户反驳移植到jai的经验

原文
我从一开始就在窗口上开发引擎,我甚至为它开发Xbox,所以,我的D经验应该可证明是有用的.
:90%时间,缺失this指针或错误
我唯一一次发现缺少this,我只是在issues.dlang上发送了一个bug:当在函数内部使用匿名类时,这似乎是DMD的一个bug.
:函数栈上变量经常部分或全部丢失或错误
从来没有.
:在没有其他可见问题时,变量值有时报告错误
没有.
:静每一未扩展好,会使调试器混乱
我还没有调试过这种代码
:mixins(D的宏等效项)生成调试信息会使调试器找不到正确文件(因此必须单步反汇编)
或,你可用-mixin=targetFileToMixin.d,可以更容易理解原因.D中的所有元编程工具在(如code-d或VisualD)工具中都不能正常工作.
:在VS中移回指令指针到上一行,一般会在下一条指令时崩溃程序
我不会玩指令指针,这会在任何语言都不安全.
:奇怪的交互,不同的编译阶段,导致元编程中的意外,生成误导性错误.
是的,我遇见了一个,当处理库的静如版本时,类似问题.
:ldc2的编译速度非常慢,但有时是唯一的选择,因为dmd有bug.
目前对我来说,情况正好相反,我不能用LDC正确地构建DLL,当用LDC构建时,writeln/printf非常有缺陷.
:D提供了禁止垃集的更好的C模式.然而,使用该模式时,不能编译标准库,元编程受到很大阻碍.
更好C的问题
:缺少文档
哪个文档?大多数时候是因为我未正确阅读文档,再者,别人可给我指出来.
:用插件时,全局域中,有时会破坏有依赖顺序的声明.
我记录了一个与此相关的错误.
:除非使用特殊类型的串字面,否则不解析mixin中的名字空间名.
没有
:在静每一中,在if后,不能插入多个else if.
同意,如果可在静每一中放case,就应该可放else if.

总结:

可见那个家伙搞了58KLoc的纯模板,元编程和CTFE滥用.60秒的构建时间是不可接受的.我相信,这样的项目是D发展自己的一个很好的研究案例.

可惜,看到D在其独特功能上那种状态是令人难过的,比如正在推广用CTFE,但因为它会使构建速度减慢很多,而不能实际使用CTFE.在某处有CTFE缓存PR,说可加速构建速度,可惜,不知道为什么未继续下去.
虽然我不会把D换成另一种语言,但我部分同意博客里说的话:在D中添加新的特性不应是第一优先,因为有很多其他东西会破坏开发者体验.
使用version/static if/mixin template/mixin有一个清晰和更好的编译流程,在元编程端生成更好的调试信息(这也帮助code-d和visualD等工具),然后,使CTFE更快(或缓存),可使D在D所提供方面更好.
如果你像C或Java那样编写D代码,你不会有太多的痛苦,但是如果开始用插件模板/别名和其他类似特性,就会开始咬人.