I was writing a library and a contributor popped out of nowhere. He didn't knew D. The first patch it suggested was about parsing some JSON at compile-time.
It turned out std.json the stdlib parser was able to parse at compile-time in CTFE context. So, the contributor parsed JSON at compile-time without his knowledge, without really knowing D, and the fact it worked was accidental (since the parser was n't specially designed to do that, but could).
Disclaimer: I've used D for an enormous time, and I tried Rust for about one hour for the experience.
Remarks:
- build times are worse in Rust, but not _that_ much worse
- with Rust error messages are plentiful and helpful to solve the error. It is a designed user experience, which is quite novel.
- the first Rust program I built downloaded no less than 146 packages, which seems to indicate the standard library is very barebones. This was an example program. So the granularity of package seems to be smaller there. I don't really like this.
- Rust has quite visibly a stronger open-source ecosystem, with lots of crates being built before a compiler release. Good.
- Rust documentation is more aimed at beginner programmers, and there is more of it.
- I just don't like to look at Rust code at all... the styling on the car is really bad
- it seems dub and cargo are very similar. Cargo download and installs a lot more cruft inside directories. Probably there is a way to have a shared directory for that.
- Rust libraries look a bit more systematically modular with the features tags ("configurations" in DUB parlance)
- it seems Rust has comparatively more C bindings than C-to-D translations in the ecosystem (vs D)
So... I'm not sure I would take Rust if starting a codebase today.
It just doesn't add up for me versus D.
I try to be someone practical and need actual measurable improvements in the daily practice.
For me the key take-away is the very consistent experience when interfacing with Rust tools, since this experience has been designed and fine-tuned to be easy. I think D can learn some UX tricks from it.
I remember earlier AMD processors, supporting SSE1 (with the CPUID bit on), but this was so slow to be unusable in practice, slower than general instructions.
In this case, the optimal thing to do was not to use these instructions despite the processors claiming support.
I'd argue that the optimal thing for a compiler to do is to use SSE when the processor supports it... and then the optimal thing for customers to do is not buy processors that run reasonable code slowly.
So, as a Game On 2010 contestant, my entry is now gone from their site? I prefer to participate to js1k which does not erase entries.
Also the reader should be aware that he will be in competition with games in development for years, some run by companies.
(edit: not to mention the sudden urge to send prizes now instead of in due time)
Gah. The old site and old pages will come back -- part of the shift that pmoz mentions above is that different teams ran the 2010 site and the 2012 version, and so we're learning (a bit late) how to build in permanence into the site structures).
I would advise to search energically for _root causes_ for your illness, have a lucid stare at your life and ask yourself why you feel bad now. Perhaps you have missing information. (edit: attention this may lead to extremely discomfortable transitional states)
I was writing a library and a contributor popped out of nowhere. He didn't knew D. The first patch it suggested was about parsing some JSON at compile-time.
It turned out std.json the stdlib parser was able to parse at compile-time in CTFE context. So, the contributor parsed JSON at compile-time without his knowledge, without really knowing D, and the fact it worked was accidental (since the parser was n't specially designed to do that, but could).