bearophile wrote:
Just a note:
What are the application areas that D targets? WB: In short, any application that
would otherwise use C or C++ would be suitable for D.<
That may become true in future, but it can't be true now. If I buy an Arduino,
or a little 16 bit CPU that has to go inside a cheap microwave oven, I usually
have to program it in C, Forth (or worse). I can't use D for that. Currently D
is not fit for the world of small real-time CPUs. And embedded CPUs are very
common, for every desktop (and handheld) CPU produced, 10 or 100 small CPUs for
embedded purposes are produced.
But there are possible ways to make D fitter for those purposes. For example it may be designed a "lightD", a subset of D (that has no built-in AAs, that uses no GC, etc), and adds several tricks/constructs useful when your available RAM is 1200 bytes long and your available ROM (well, flash, or a different slower kind of RAM) is 30000 bytes. In such situations a compiler is even asked to produce not just the faster or shorter binary, but sometimes even the less energy consuming one! (think about a -Oe compilation flag, beside the -O and the -Os). Or maybe D will never fit for such purposes.
I wouldn't want the language to be too different though. Maybe a subset
runtime (with gc off by default) + std lib though (subset of existing
and not really a third choice of library). Call just about anything in
tango and you get an allocation, no explicit delete and an assumption
that the GC will take care of it eventually.
Aswell as the embedded, regular operating systems are a big area of
C/C++. This should be an easier fit for D but all D kernel/os projects
have probably been abandoned.
