Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 79

Thread: D Language Still Showing Promise, Advancements

  1. #11
    Join Date
    Nov 2010
    Location
    Sweden
    Posts
    27

    Default

    The D devs are very aware of the common points of criticism (in short: dynamic/shared libs, stop-the-world GC), and limiting the amount of allocations in phobos is AFAIU on the todo list.

    There was a concurrent gc library for D1 (CDGC) but it hasn't been ported to D2. It looks like it will be, though.

    Anyway, the CDGC author's dconf talk: Concurrent Garbage Collection for D by Leandro Lucarella

  2. #12
    Join Date
    Sep 2010
    Posts
    457

    Default

    Quote Originally Posted by Ericg View Post
    You mean the ARC that got added in C++11 in the form of Smart Pointers, Shared Pointers and Widgets? :P
    Yeah, something like this kinda. ARC is neat because it pushes things to compile time.
    Read up on the C++11 new pointers and have found some problems with it: http://www.codeproject.com/Articles/...Smart-Pointers
    Seems like we need some better semantics than C++ can provide, and the earlier attempts is now starting to create legacy stuff.
    The behaviour is still not really consistent and you need to take special precautions to not fail.
    It's coming closer but it's still not as reliable and error-resilient as I would like it to be.

  3. #13
    Join Date
    Mar 2013
    Posts
    144

    Default

    First off, D isn't a C substitute. It's a C++ substitute. If you're in the market for a C substitute, try golang.

    Now, while I detest big OO languages like C++ and Java, D at least does it right. In fact, If you entertain the basic premise that large OO language are some times necessary - say, for closed source game engines where there must be some very good abstractions around some very tough math, D is C++ done right.
    D takes every feature C++ has to offer, and redoes it in retrospect properly. The syntax is coherent and consistent. The standard library isn't the random grab bag that C++ is but has some very specific goals and functions. And most importantly D was designed from the grounds up with a vision in mind unlike the randomness C++ has become.

    So, if you're a C++ programmer that is working on a pet project, you might as well go with D. You won't regret it. If you're part of some closed source library project that has the leeway to experiment a little, D just might be right for you.
    Even if you're a hobbyist that dislikes C++, you can do well to learn some D (like myself) so you can fine tune your hate of the concept rather than the implementation Then you can go ahead and fall in love with golang :P

  4. #14
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,537

    Default

    Quote Originally Posted by c117152 View Post
    Even if you're a hobbyist that dislikes C++, you can do well to learn some D (like myself)
    Indeed. Though I like both the concept and implementation. Writing in D is just a lot faster and easier than writing in C (and to a slightly lesser extent than C++), and just like C++ and unlike Java it doesn't force you to use OOP. So in a way it's a good C replacement as well, although C isn't as direct a competitor as C++ is. Also, like Walter Bright said in the keynote, its nice and coherent syntax makes you feel good about writing code in D, because the resulting code is just aesthetic-looking and is very readable, if you use the proper language features (templates, array slicing, contracts, Ddoc, unit tests etc.).

  5. #15
    Join Date
    Feb 2008
    Posts
    208

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: D Language Still Showing Promise, Advancements

    provably correct, and of industrial quality. By provably correct they mean it provides provable memory safety, provable purity and immutability,
    http://www.phoronix.com/vr.php?view=MTM5MTg
    At first I toght about being "probably", not "provably". Then I found this word exists and as wiktionary puts, it comes from provable -> -> proven -> prove -> proof

    I'm not a native speaker, so this amuses me and I always find words I don't know to learn more about the English language

  6. #16
    Join Date
    Oct 2012
    Posts
    274

    Default

    Quote Originally Posted by c117152 View Post
    So, if you're a C++ programmer that is working on a pet project, you might as well go with D. You won't regret it. If you're part of some closed source library project that has the leeway to experiment a little, D just might be right for you.
    Even if you're a hobbyist that dislikes C++, you can do well to learn some D (like myself) so you can fine tune your hate of the concept rather than the implementation Then you can go ahead and fall in love with golang :P
    The GC is in every case you mention for me (us) the main point why D is no go. we have a quite constraint memory demand which makes any currently known attempt of GC a deal breaker.

    i can't go into details, but in contrary to what somebody else posted here, GC is worse than manual memory management. of course you do not compare a bad implementation of memory management with a good GC. you compare a good memory management with a good GC. the lack of control yields a damn lot of situations where a memory limit will cause big issues with any kind of GC.

    GC are in general only for usecase where you actually have either a lot of memory or time enough.... or your customers/clients can live with the drawbacks.

  7. #17
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,873

    Default

    Quote Originally Posted by a user View Post
    The GC is in every case you mention for me (us) the main point why D is no go. we have a quite constraint memory demand which makes any currently known attempt of GC a deal breaker.

    i can't go into details, but in contrary to what somebody else posted here, GC is worse than manual memory management. of course you do not compare a bad implementation of memory management with a good GC. you compare a good memory management with a good GC. the lack of control yields a damn lot of situations where a memory limit will cause big issues with any kind of GC.

    GC are in general only for usecase where you actually have either a lot of memory or time enough.... or your customers/clients can live with the drawbacks.
    Automated Reference Counting is a nice middle ground. As long as the object has 1 reference to it, it wont be freed which prevents 'accidental frees' that can happen from human-error in manual memory management, but when it hits 0 references it gets automatically freed.

  8. #18
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by GreatEmerald View Post
    Just as a heads-up, all the conference videos can also be found on YouTube here:
    http://www.youtube.com/channel/UCzYz...oQaQYXw/videos



    Nope. GC can actually be more efficient than manual memory management. And those who absolutely must go around it, it's easy to either turn it off or simply avoid using functions that invoke it. See this presentation for more information on the subject:
    http://www.youtube.com/watch?v=1MF5bcmvJ0o
    Is there any written version? I don't really like long videos, I prefer reading. I'm curious about how could it be more efficient than good manual management.

  9. #19
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,537

    Default

    Quote Originally Posted by mrugiero View Post
    Is there any written version? I don't really like long videos, I prefer reading. I'm curious about how could it be more efficient than good manual management.
    There are slides, but they don't show the point the presenters want to make that well, so you should just watch the video. It's all about the GC in any case.

  10. #20
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by Ericg View Post
    Automated Reference Counting is a nice middle ground. As long as the object has 1 reference to it, it wont be freed which prevents 'accidental frees' that can happen from human-error in manual memory management, but when it hits 0 references it gets automatically freed.
    Yes and no: ARC increases the size of the object by adding the reference data into it. I'm (almost) sure that ARC may work great for this guy, as I suppose that the bias against the GC is founded on rumor and "I think", and "these big pauses". D has not a generational GC (because in generationa GCs the freeing of most short lived objects automatically).

    Also, ARC is expensive in CPU power, if you have a loop, and in this loop you have a reference increasing and decreasing by one, the same loop can work slower with reference counting than with a proper GC.

    At last, but not at least, ARC gives more predictability about freeing of objects (given you don't make reference cycles, meaning leaks), so many pauses are by design very small. This I think is the main advantage of ARC, and to not use a GC. If the user's application creates many long lived objects, the GC pauses can be really big.

    But memory constraints? Not sure.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •