Hacker News new | past | comments | ask | show | jobs | submit login

This to me is one of the best arguments for a new language that takes over the traditional role of C++ - writting programs in it is just too slow.

I can't even imagine what it would be like on a 100hz computer.




D and Go are the two languages poised to take over the roles of C and C++. They both have very fast compilers and numerous other advantages compared with C and/or C++. I've looked at both of them quite carefully, and decided that D works better for me (an important factor for me though was that D2 recently stabilized with the publication a couple months ago of Andrei Alexandrescu's excellent new book "The D programming language"). There's an interesting recent thread debating the merits of the two languages at the golang-nuts mailing list.


> languages poised to take over the roles of C and C++

D has been around for ages, during which time C++ usage has grown quite a lot, essentially at the expense of C and assembly.

First of all, I don't get the sense people are actually casting about for a C++ replacement. Secondly, garbage collection makes D a non-starter in probably over half the areas C++ is used.


Given that Andrei Alexandrescu, who is one of the best-known C++ programmers in the world, co-designed (with Walter Bright) the new version of D, I would say that there are at least some C++ programmers looking for a better language. I think there's also a lot of C programmers looking for a better language but unwilling to deal with C++ (I'm in that category myself). Garbage collection in D is optional.


I'm not poo-pooing D at all, it just it seems to compete more with Java/C# than C++.

C++ is now really for closer to the metal, where garbage collection is truly a non-starter and nobody cares that std::string is awkward because they don't use it.


Can you explain why, if garbage collection is a non-starter, _optional_ garbage collection should have any negative impact?


I would say it depends on what the libraries do expect, especially the D standard libraries. If those work with and without garbage collection it probably doesn't matter so much. If those expect garbage collection then I suppose D2.0 will have a hard(er) time luring that many c++ guys over.

Does anyone already know how the new standard libraries which they wrote do work?


Andrei Alexandrescu addresses the issue of programming in D without garbage collection in this interview from yesterday: http://www.informit.com/articles/article.aspx?p=1622265

Notice in particular that he says "Furthermore, you can use malloc() and free(), along with the rest of C's standard library, ..., without any overhead. Then, a D primitive called emplace allows you to construct objects at specified memory locations (a la C++'s placement new operator)".

The emplace function is in the std.conv library and is the basis for constructing objects outside of the control of the garbage collector.

My understanding is that most library functions do not care about whether you are using garbage collection or not. Library functions are usually written in a parameterized way such that you can use any appropriate object; so long as it has the right methods.

Take a look for example at the std.algorithm library: http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html I don't think anything there cares whether you use garbage collection for your types or not.


Speak for yourself. I use std::string frequently and there isn't anything awkward about it.


Manual memory management is always possible in D, and if you really need to, the GC can be ripped out.


I got into D at least 5 years ago because I was a C/C++ user looking for something that has comparable power and, well, wasn't so horrible.


IIRC, D has optional manual memory management.


And Walter, of course, has his answer to this. dmd is very fast (IIRC according to Walter it's faster than Google Go compiler) thanks to parallel compilation, asynchronous I/O, etc. enabled by design of D.


To be fair, I can't think of much that wouldn't be painfully slow on a 100Hz CPU.


Just as an example, the original Playstation ran on 33.8688 MHz.

(100 MHz is actually quite fast.)


100Hz != 100MHz


Oh, I mentally inserted an M.


That, and the fact that concurrency without garbage collection has been shown to cause brain cancer.


If it gets some momentum behind it then I feel GO could be that language.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: