ponce

This is really quite common thinking in D.

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.

That's what D does, it has infinite look-ahead in cases and there are still multiple parsers available as libraries.

Go doesn't allow to create reusable, zero-cost abstractions so I guess it's not more concise than C++ either.

Great news, Intel does make suprinsingly effective optimizations.

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.

May I mention Nimrod [1]? It has a lot going for it when it comes to meta-programming.

[1] http://nimrod-code.org/

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)

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)

yay, every Allman indented program will silently fail

It's damn hard to stop using. Pretty addictive.

Same here. People don't know how high one can get just with running.

I commute by bike (2x30 min/day), go running 1h30 once a week and have a rowing machine (1h/week). I don't want to live without these highs. It also helped me in productivity and mental illness.

Windows and Linux drivers are maintained by the manufacturers.

Now deprecate your own OpenGL drivers.

Did you make a "throw the geek" flash game ? It was great.

Now he can program in a proper language.

A language without purity / proper constness / powerful static checking will not be automatically parallelized.

Walter rewrited his game Empire in D.

Maybe you could have a read at Modern C++ Design by Andrei. A mind expanding book with incredible insight in meta-programming.

All this "template maelstrom" makes sense and is unavoidable to have powerful and expressive statically-typed languages.

Unsupported is a bit strong.

"For pet projects I'd be inclined to give a green light. It's always nice to play with new technologies as it opens your mind and give you new ideas."

I had no success in learning another languages now that I know D... be cautious :p

"For full fledged commercial products you expect to live several years, that's going to be a solid red light. I wouldn't take the risk of using an unsupported language."

I would have said that a year ago, but it becomes less true over time.

You are likely to encounter less bugs in D1 than one year ago. DMD is released frequently, usually fixing a lots of bugs you didn't even worried about.

All problems other than compiler bugs aren't really blocking. There is also bugs in C++ compilers.

I don't think many-cores compatibility is a little gain.

I find it a lot better.

There is an awful lot of problems with C++ though.

- The tool are certaintly not rock solid. Parsing requires arbitrary look-ahead and semantic pass, order of headers inclusion matters, #if and dirty tricks are everywhere

- compilation is slow

- non standard extensions makes painful portable C++ across compilers and platform, because you need them and they can have incompatible syntax

- C++ const is useless when it comes to optimization or concurrency.

- any real world project involving C++ is going to be challenging if you're not working with top C++ library implementers or emasculating rules (like "no exceptions" or "nothing goes in the constructor" at Google)

Anyway, even if C++1x was already here and completely supported (which C++03 is not), D would still have an edge.

Despite its current problems D greatly enhance productivity over C++. Refactoring is _way_ faster when you have import and no headers to maintain. Properties enhance expressivity a lot. You have access to the machine, value semantics, and reference returns, so there is nothing conceptually wrong with it.

Also, in D there is much less skill diffference between library writers and typical programmers as compared to C++.

Finally if you really want C++1x features, I sincerely advises to try D because there is a lot of overlapping.