On Wednesday, 27 March 2013 at 15:34:20 UTC, Vidar Wahlberg wrote:
I know I'm probably going to upset some people with this,
bashing their favourite child and all, but I wanted to let you
know the experience I've had with D so far, as a novice D coder
with a heavy Java & light C++ background.
I think D has quite a strong set of critic users, namely because
the benefits are just too great.
Not to suggest less importance to these issues, but these are
known issues. It is good to have them brought up from the new
user perspective.
Woes:
-----
- I find myself in a world of pain when I want to share data
I don't use this, but my understanding is that 'shared' is a low
level feature. In general one doing threading should never touch
it and instead a library is built from it.
The problem is we don't have a good threading library, we have
parallelism and concurrency which may use threads but not always
what one would expect when looking for threading.
I could be completely wrong here!
- While the "auto"-keyword often is great, it can lead to
difficulties, especially when used as the return type of a
function, such as "auto foo() { return bar; }". Sometimes you
may wish to store the result of a function/method call as a
global variable/class member, but when the function/method
returns "auto" it's not apparent what the data type may be.
My observation is that many times in D the type is something you
probably don't want to write out even if you know it. Using
typeof() tends to be a better choice even if it isn't straight
forward.
Gotchas:
--------
- The lack of "rectangular" arrays created at runtime in D
("int i = 5; int[i][i] foo;") can be quite confusing for
programmers with Java or C++ background.
Well in this case you are trying to create a static 2D array with
a runtime value.
I haven't had issues with 2D arrays, but I'm not familiar with
"rectangular" arrays.
- Static array versus dynamic array was one of the first traps
I stepped on
Static arrays are very hidden. Much like arrays are hidden in C.
- When casting a value to an enum, there's no checking that the
value actually is a valid enum value. Don't think I ever found
a solution on how to check whether the value after casting is a
valid enum value, it hasn't been a pressing issue.
This would be nice, but enum's are also nice for binary flags.
auto option = My.A | My.B | My.C;
option would be a valid My for how it is used, but it is not
defined as valid. There has been discussions on alternatives to
using an enum (but enum is convenient).
- Compiling where DMD can't find all modules cause a rather
cryptic error message. A solution is to make sure you specify
all source files when compiling.
The compile => link process is pretty well hidden in most
languages these days (many don't have it).
Wishlist:
---------
- "void[T]" associative array (i.e. a "set") would be nice, can
be achieved with "byte[0][T]".
I think a proper library container would be fine.
- "Foo foo = new Foo();" for global variables/class members.
Now you must "Foo foo; static this() { foo = new Foo(); }".
This won't happen. It is kind of a feature. Otherwise you'd be
confused with the static this dependency error because "I'm not
using static this."