On 11/26/17 16:14, IM wrote:
Hi, I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now.First of all, I must start by saying that I like D, and wish to use it everyday. I'm even considering to donate to the D foundation. However, some of D features and design decisions frustrates me a lot, and sometimes urges me to look for an alternative. I'm here not to criticize, but to channel my frustrations to whom it may concern. I want D to become better and more widely used. I'm sure many others might share with me some of the following points: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way.
Well. D has it's own idioms and patterns. So we fully expect some of the idioms that are easy in C++ to be not easy in D, and indeed that's kind of the point. If you look at the those idioms that are hard in D, it's probably because said idiom allows you to do some fantastically unsafe (and insecure) thing in C++. Yes, I am sure that it gives some performance boost, but D is not trying to be the pinnacle of language performance. D is trying to be a memory-safe language, quite intentionally at the expense of speed (see this DConf 2017 talk: https://www.youtube.com/watch?v=iDFhvCkCLb4&index=1&list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance.
We are not trying to be C++ and we are not trying to replace C++. It sounds like C++ works better for you. We are OK with that. We always recommend using what works best for you. That is after all why WE are here. :)
-- Adam Wilson IRC: LightBender import quiet.dlang.dev;
