31–40 of 77 posts
D is a fantastic language. C++ is so difficult to unseat as a systems language now since it is back as a moving target which is both evolving and has extremely robust tools to go with it. Challenging it on the language level is not enough.
I was working on a similar article just a couple of weeks ago for the D wiki, but I wanted to focus on the really big things, and I want to include more examples: http://wiki.dlang.org/Coming_From/C_Plus_Plus_WIP_article
The one issue that sticks for me was the dual standard libraries. Just seems so messy.
Is now the time for D? I really wonder, I am not really sure. Certainly a lot of languages go thru a period of obscurity before success, but I'm still uncertain. The one issue that sticks for me was the dual standard libraries. Just seems so messy.
> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?
version (Posix) {
version(OSX) {
// Weird stuff on OSX
}
// Sane stuff for Linux or FreeBSD
}
version (Windows) {
// Weird stuff for Windows
}
> D has no need for a preprocessor How does this work, specifically conditional compilation? I have lots of code like this: #if __APPLE__ /* do things the OS X way */ #else /* do things the Linux way */ #endif Where the OS X way calls functions that do not exist on Linux, and vice-versa. How does D handle this?
Lack of a preprocessor does not imply lack of conditional compilation: http://dlang.org/version.html The constructs are simply built into the language. This has considerable benefits: you can use e.g. `static if` to enable/disable code based on conditions which refer to constants declared in the program (there is no longer a separate namespace for preprocessor defines and program constants), and with CTFE, you can us…
This comes up all the time in reference to C++. C++ doesn't need a package manager because it has excellent support from distro package managers. Most libraries are in the system package manager. And yes, sometimes you need a newer version of a package or one not quite widely-used enough to be in the system package manager, in which case you need to do compile it yourself or install it manually. But that is a problem common to all package managers and there is nothing about D which will make it any easier.
Earlier quoted context omitted.
>WalterBright uses it in his compiler. Ironically, the dmd compiler is written in C++.
D didn't exist when the dmd compiler was written. But Daniel Murphy has written a C++ to D converter, and it's looking like the next release will have dmd written in D.
I'm curious how many people out there on HN actully use D and what for? I don't typically see D based projects here on HN so it would be interesting to find out about any use cases where D was found a perfect fit.
I really enjoy a lot more writing on D, but I keep finding the issue that I need to interface with C++ libs for something (for example Qt 5 for an emulator GUI) or weird errors like these problem with std.net.curl on Ubuntu 14.04 . If not was for that, I would wrote the Trillek virtual computer on D.
Is now the time for D? I really wonder, I am not really sure. Certainly a lot of languages go thru a period of obscurity before success, but I'm still uncertain. The one issue that sticks for me was the dual standard libraries. Just seems so messy.
The dual library issue ended 7 years ago or so.
Honestly, I'm pretty excited for Rust. Having a strong proof of lifetime enforced by compiler is very compelling idea.