What can you "new"

[Sean Kelly]

Cristian Vlasceanu wrote:
> Hm... how should I put it nicely... wait, I guess I can't: if you guys think 
> D is a systems language, you are smelling your own farts!

Then I may as well just walk away from D now because this is the only 
reason I'm using it.

> Because 1) GC magic and deterministic system level behavior are not exactly 
> good friends

malloc is non-deterministic as well, but C/C++ have that.  And in 
instances where determinism is necessary, why not simply avoid dynamic 
allocation?  Sure, things get a bit weird when language features have to 
be avoided (string concatenation, etc), but at least these are easy to 
grep for, thanks to Walter providing distinct syntax for this stuff.

 > and 2) YOU DO NOT HAVE A SYSTEMS PROBLEM TO SOLVE. C was
> invented to write an OS in a portable fashion. Now that's a systems 
> language. Unless you are designing the next uber OS, D is a solution in 
> search of a problem, ergo not a systems language (sorry Walter).

C/C++ have historically been the only feasible languages for much of the 
work I do.  It's possible that I could write the higher layers of some 
apps in a language like Erlang (I did used to work for a Telco, after 
all), but C/C++ would still have been necessary for the underpinnings. 
The thing is, after having spent a decent amount of time with C/C++ I 
began to have problems with certain design issues in those languages. 
Sure, they /can/ do what I need, and they're certainly prevalent which 
is a huge perk, but the cost of maintenance with both languages is 
unreasonably high, certain types of bugs are difficult to avoid, etc. 
So far I've found D to answer many of my issues with C/C++ very well 
without sacrificing the features I need from these languages: direct 
system access, unsafe memory manipulation, inline assembler, etc.  I'm 
still using C/C++ at work today, but I would love for D to become 
sufficiently mature that I could argue for its use instead.

 > It is a
> great application language though, and if people really need custom 
> allocation schemes, then they can write that part in C/C++ or even assembler 
> (and I guess you can provide a custom run-time too, if you really DO HAVE a 
> systems problem to address -- like developing for an embedded platform).

There are a lot of application languages out there, most of which have 
terrific toolset support--something D lacks tremendously.  Why would I 
bother with D if I could use Java or C# for the same thing?  I think 
multiprogramming support may be an answer to this question, but that's 
not a selling point /today/.

> Here go another two pessos.

And another two as well. :-)