D is a fun language, and some friends and I (mostly my friends) have been/were writing an exokernel in it[1], but between the weird licensing, D1 -> D2 transition, dual standard libraries, and a few other things, it's been really rocky.
I hear it's a bit better these days, but my "better C++" interests lie in Rust nowadays. That said, this link is one of the ways D is strictly better: since it's been around a while, there's more educational information out there.
I'm curious what the "few other things" are because the things you mention specifically are a few years out of date at this point. I'm not sure what licensing issues you've had but phobos is Boost licensed which is extremely liberal (basically "use for whatever you want just don't remove this license text when copying this source code").
Pretty much everyone uses D2 these days unless they are maintaining a legacy system written in D1 and transitioning to D2 isn't worth the effort in their case.
Phobos versus Tango hasn't been an issue for years. In fact, in D2 you can use Phobos and Tango side by side[1].
Rust is very interesting and I'm excited to see where it is headed but it's still rather immature compared to something like D.
> the things you mention specifically are a few years out of date at this point.
Right, hence the 'I hear it's a bit better these days.' Maybe I should have been more clear.
> I'm not sure what licensing issues you've had
The whole time I was using the language, there was the dual licensed aspect of the compiler, where the front end (I think?) was not open, but the back end was? Or maybe the other way around? I think I heard that Walter ended up OSSing the entire thing. As a strong BSD proponent I find complex licensing requirements tiring.
> but it's still rather immature compared to something like D.
Yeah, Walter did end up opening up the backend to DMD but the backend is still not Free Software only because Walter is licensing it from Symantec. He accepts patches to fix problems in it but it is less than ideal. The frontend is GPL and has had the copyright assigned to the FSF.
The good news is that GDC (gcc backend) and LDC (LLVM backend) both produce faster binaries than DMD and are completely open source. The only downside is they tend to be a version or two behind DMD (which at DMD's release rate is around 3-6 months or so I'd say). Also, LDC isn't available for Windows primarily because LLVM doesn't yet support SEH exceptions.
In any case, the compiler's licensing doesn't affect software you write in D.
I find D to be much less complex than Rust. Rust, even now, is woefully incomplete. Take the 'rust' tool for instance, see how many bugs you can find just in the flags that you can pass to it!
(it's a substantial amount... or it just decides to break conventions, which dmd did also with it's '-offilename' type flags.)
Rust is also harder to learn, and it seems (to me) to also be more difficult to use C libraries from Rust than D. I cut my teeth on D by creating a few bindings, and I really struggle to do the same in Rust.
Just my experiences...
PS - Rereading this it occurs to me that D is probably just as complex as Rust, but it 'feels' less complex due to syntax familiarity.
Thank you. I'm actually watching Ali's Session of DCONF 2013 and was wondering where this book was. I totally recommend watching the sessions: http://www.youtube.com/watch?v=mPr2UspS0fE
I wonder if they are being deliberately slow at releasing these videos so that each one gets discussion and views. The conference has been over for some time now.
I'm interested in D but lack of tutorials/documentation have always kept me away from it. It'd be cool if it had something similar to Python's tutorial.
Sweet! What a blast to browse this in a native app! :) Page flipping, keyword searching ... everything happens immediately. Byebye Web browsing. Just do it:
D is great but lack of tool support (proper intellisense) means we're all stabbing in the dark trying to figure out what function to use, where it comes from and what its parameters are supposed to take. Also, really needs declarative parallelization mechanisms a la OpenMP. Plus, unsure if compiler supports vectorization, SIMD support would be nice to get.
On the other hand, amazingly fast compiler, very concise language, and metaprogramming! Want a decent IDE!
"D is great but lack of tool support (proper intellisense) means we're all stabbing in the dark trying to figure out what function to use, where it comes from and what its parameters are supposed to take."
Some people like to read the documentation and not let their editor figure out how to program for them.
Wasting time just to enhance your own ego is not a virtue. If you really find that pseudo-religious penance is beneficial to your smug sense of superiority then wear a hairshirt while you program.
Bah - the point is not that it is better to look things up than to have an IDE know things for you, the point is that if your IDE doesn't know those things, you should be able to find them yourself. It is bad to be beholden to intellisense to the point where you actually can't use a language that it doesn't work well for.
Are you seriously arguing that a programmer, who surely has more than a passing familiarity with how to search for things on the internet, would forget how to look up documentation after using an IDE for some time period? The art of programming is not masted by mindless repetition of laborious documentation lookups. Searching documentation isn't an advanced skill that requires constant practice to remain capable. Generally there are still plenty of things to look up (has somebody solved this before, is there a library to do this, has somebody already figured out a workaround for this bug in library/framework X that I'm using etc etc).
I find languages with poor tooling irritating to use, in the same way that I find other language deficiencies irritating. I usually wish I was back using something more powerful. For example, it's the feeling I get when working with strings in C, or using a language without lambdas. I am irritated at my time being wasted when using languages where the compiler doesn't warn me about simple mistakes, or when I have to manually filter out false positives when renaming something with a tool that doesn't understand the code beyond doing find/replace/regex on a stream of unicode characters. None of this means that I can't get work done with 'blub' language and tooling, but the fact that something better exists is always in the back of my mind, and knowing I have mastered a worse tool doesn't give me much satisfaction.
The idea that more modern and better tools are a crutch is hardly unique to software development. In just about any field you can find people advocating for the 'character developing' tedium of the old ways. The irony of course is that the same arguments nearly always apply to the older methods being advocated: they once were new, and the hard won knowledge of the even older method became redundant. See: punchcards, assemblers, compilers, build automation tools, version control software, syntax highlighting, documentation being a big physical book with an index, compiler errors and warnings, images, refactoring tools, automated testing. Just about all of those have been described as a crutch that prevents people achieving real deep understanding of the computer or their code. Does it make you feel inadequate as a programmer to know that you couldn't do your job using punchcards, or as you put it, to be 'beholden to a text editor to the point where you can't program without one'.
That's good to know. I was not intending to disparage D, which I have not used so I don't know how good the tooling is one way or the other. I was merely responding to comments implying that better tooling is a crutch for people who can't really code.
Language-aware completion is called "omni completion" and triggered with <C-x><C-o>. <C-n> does keyword completion which is much dumber than its sibling but works.
On the contrary, I would consider it a waste of time to dive into a language, library or framework without sitting down and reading through enough documentation to figure out what I want to do. The time you spend planning these things is well repaid in terms of avoiding simple mistakes.
Coming from someone working in graph theory code I can tell you that the debugger is invaluable.
So many pointer links :)
Last time I tried VisualD it was pretty good.
I use Go actively, and I come back every few months to D. In short, use Go if you want a simple, structure development environment, but use D if you want a better C++. I like Go because it's well designed, but I like D because everytime I review the docs, I learn something new. Here's some very basic analysis:
Go is fantastinc for writing servers. The concurrency model is awesome and the standard library is surprisingly extensive given its age. It does work for non-server things, but it was developed for making concurrency as used in servers easier. There is no manual memory management, unless you use a C extension.
Pain points:
* no inheritence: it's fine for 90% of problems, but really annoying for the last 10%
* super-strict type system: byte isn't implicitly convertable to int, for example
* opinionated: code style, build system, etc.; everything can be worked around, but it's a recurring theme
* no manual memory management: the GC is getting better, but it'll never be good enough for writing intense games
D is awesome for writing more general software. The general feel is what C++ would have been if it was designed better. It has a stronger connection to C, so manual memory management is an option with free/malloc. However, most of the time you'd rely on the GC, but it's nice when you absolutely have to control things, e.g. for a game.
Pain points:
* not enough documentation: the website is awesome, but when you try to do something complicated (like write a game), it's uncharted territory
* Annoying bugs, especially in CTFE: most normal operations work fine, so this isn't really an issue
* no package manager: well, there is DSSS and Orbit, but I haven't found one that I like
* no standard http lib: terrible if you want to do web-stuff
I actually recommend them both. They're very different languages built for very different things, but you can't go wrong with either. Go 1.1 is about to be released (the "final" release candidate was released last week), and it has some cool new features (I like method values a lot). Then again, D has awesome metaprogramming support (templates are magic =D).
I hear it's a bit better these days, but my "better C++" interests lie in Rust nowadays. That said, this link is one of the ways D is strictly better: since it's been around a while, there's more educational information out there.
1: https://github.com/xomboverlord/xomb