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. :-)

Reply via email to