18 ms·

I've preferred C to C++ and D to C++ for a long time. To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all

I've preferred C to C++ and D to C++ for a long time. To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around. For things that don't need classes (and there is a lot of code) I stick to C. But if I need the OOP benifits then I go with D. As a bonus, the C programmers and JavaScript programmers that I work with can read the D code and get most of it on the first try. If you haven't used D, spend 30 mins and write a four function calculator. Then take the remaining time adding some kind of internal function line sin, cos, etc. You'll be suprised at how fast you can pick it up. Granted, the above is a toy exercise, it's not writing an enterprise solution. But it's a little more than the standard "Hello Sailor, new in town" program that people start off with.

petre 7y ago
> For things that don't need classes (and there is a lot of code) I stick to C. I'd use D anyway just for the GC or whatever, less compiler fighting, betterC etc. Procedural, OOP, functional, yay.
- rowanG077 7y ago
  Really? For me the presence of a GC disqualifies D as the main replacement for C and C++.
  - mhh__ 7y ago
    How much software genuinely requires not having a GC? If you don't want it, don't use it, but using it can make your software completely safe and fast (Garbage Collection is often faster than RC as long as pause times are acceptable, and added memory use). A lot of the standard library ranges are inherently lazy and therefore require no interaction with the GC. Exceptions are also nogc now.
    - quicknir 7y ago
      If you can tolerate GC then like 20 languages (as or less obscure than D) enter the conversation. If you can tolerate GC and the performance implications that go with it, then using C or C++ is rarely a good choice to begin with (well, other than legacy, which is a valid and common reason).
      - mhh__ 7y ago
        D isn't defined by performance or memory management, however. There are many D features which are just blisteringly professional in how they approach software development: Using D is conducive to writing good software. Metaprogramming, for example, in D is obvious and almost fun. The compile times are ridiculous compared to C++, i.e. I can build the main D compiler in three different configurations in about 5sec on my machine.
        quicknir 7y ago
        I'm not saying that D is defined by that. I'm simply saying that if you're comparing to C or C++, you are talking about use cases that are defined by performance and/or memory management (or else, they are being used for legacy reasons). If you have a green field project that doesn't have massive performance concerns, and doesn't have to be specifically in C or C++ for other reasons (toolchain availability, available developer resources, etc), you probably aren't using C or C++. Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.
        WalterBright 7y ago
        There are people who specifically use D for writing high performance applications. They find it faster than C++ for a rather subtle reason - D code is more plastic, meaning it is easier to refactor D code trying out different algorithms looking for a faster one.
    - umanwizard 7y ago
      I’ve seen large, poorly written Java programs[0] where an entire core at 100% is dedicated to the GC. I have never seen that behavior for things like ~shared_ptr in C++ or similar languages. Then again, OOMing due to leaks is something you’re more likely to see in poorly-written systems in non-GC languages (Objective-C, C, C++, etc), so there are certainly trade offs. [0]: Maybe “poorly written” is unfair. Perhaps “written by people who are unaware of how to write code that performs well in a GC system”.
    - krzat 7y ago
      Probably the most important usage of C are shared libraries. How well it will work if I have D library with it's own GC, another Go library with second GC and app written in C# with yet another GC?
    - jcelerier 7y ago
      > Garbage Collection is often faster than RC as long as pause times are acceptable I have never in my life worked in any kind of software where this was remotely acceptable
    - rowanG077 7y ago
      You are right most software it doesn't matter if you have a GC. However then D is not competing against C and C++ it's competing against almost every other language.
  - newacct77 7y ago
    D's garbage collector can be disabled, so would you mind elaborating?
    - CameronNemo 7y ago
      How well is that supported by the ecosystem?
      - dymk 7y ago
        Very poorly
      - p0nce 7y ago
        Not using the GC is rather easy, there are plenty of mitigation methods. Not using the D runtime is much more involved. Not linking with the D runtime is a more hardcore endeavour.
    - rowanG077 7y ago
      Yes and then you can't use most of the nice features of D. Forget about libraries.
  - nicwilson 7y ago
    Mere presence shouldn't. If you never allocate from it (which is able to be verified very easily with the @nogc attribute), it will never trigger. You can disable it and trigger when you feel it is needed. You can choose to just leak. The default GC is OK, but not great. However it recently was made multithreaded in the mark phase so it is much faster than it used to be. There is a fork based (on linux only IIRC) GC, used by several companies for hard realtime systems, that marks and sweeps in a separate process with CoW pages.
  - WalterBright 7y ago
    The -betterC switch to the compiler compiles a D subset that doesn't have a GC.
- edwintorok 7y ago
  What makes you choose it over Rust or Go?
  - 6thaccount2 7y ago
    Not OP, but I can guess. D has a built-in GC by default and doesn't force you to manage memory like Rust. Also, the author mentioned that D is pretty straightforward to anyone with some basic programming knowledge (think C, C++, Java, and C# which fits the majority of coders). Rust is very different from those languages. My main goto language is Python and I can understand D a lot more than Rust which confuses me to no end (disclaimer: I'm a total noob). Go is probably as easy to read as D if not more and is also GC and fast. It is also very spartan. I bet D has a lot of additional features.
  - petre 7y ago
    With Rust I always find myself fighting the compiler just like with C, it's very strict about everything, no GC, steep learning curve. Go is okay but you can't get clever with it. You're productive from the start butit becomes routine quite fast and at a certain point there isn't anything new to learn. Error checking is also quite annoying. D has the best of both worlds and it also plays nicely with C/C++, something that the author of Zig also understood is a must have in any language that aims to be a better C/C++. In D one is productive from the start and there's always something new to learn. And one learns it as they code, without having to first read Programming in D by Ali Çehreli to make any sense of the language. I also tried Crystal and liked it but one is more productive in D and Go without any prior knowledge of those languages. I was kind of annoyed by the fact that Crystal removed the for loop, which works perfectly fine in Ruby.
    - edwintorok 7y ago
      You can opt-in to a Gc with Rust via Rc<> and Arc<>: https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis https://words.steveklabnik.com/borrow-checking-escape-analys... Don't get me wrong, I like a language with a Gc by default, my favourite language is OCaml, but I can't claim it to be a drop-in replacement for C projects. Go, Rust (or D) stand a better chance at that.
nextos 7y ago
I also prefer C and D to C++. But used wisely, C++ can be a really nice language after all changes that started with C++11. The key is to realize C++ is not a language, but a federation of languages. You need to cherry pick a subset you what you want to use and stay disciplined. Otherwise, it is a mess.
- msla 7y ago
  > The key is to realize C++ is not a language, but a federation of languages. You need to cherry pick a subset you what you want to use and stay disciplined. Otherwise, it is a mess. I've noticed two strains in language design, which I internally call Scheme-style and Common Lisp-style: Scheme-style languages are the trimmed-down languages, often built around a big idea which animates the rest of the design but not always; the defining concept of Scheme-style languages is always how much they can remove to get a pure design, a design which supports writing code in one style. Python, Smalltalk, C, and Scheme are all languages in this mold. Java is kind of a compromised Scheme-style language, or two of them (C and Smalltalk) rammed into each other at high speed, which also goes for Objective-C. Common Lisp-style languages have mini-languages inside of them, or at least support multi-paradigm programming as a core design goal; you can trim a Common Lisp-style language into a Scheme-style subset, but you can't extend a Scheme-style language into something more Common Lisp-like unless you really are dealing with Scheme and have (hygienic) macros to use to add more syntax. C++, Perl, and Common Lisp are all Common Lisp-style; Unix shell is Common Lisp-style in practice because it encourages programmers to write in a bunch of relatively Scheme-style languages at once, all in the same program. Note that both Scheme and Common Lisp have a conceptual core in the Lambda Calculus and axiom-like special forms. C++ lacks this and Perl doesn't really have it either, but most people don't write huge codebases in Perl.
  - kazinator 7y ago
    Scheme is only about removing features from a language document, not from actual systems.
    - gmfawcett 7y ago
strictfp 7y ago
>> I've preferred C to C++ and D to C++ for a long time. To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around. I'm sorry, but even though I think D is a great language, there are plenty of usecases where D isn't a viable alternative to neither C or C++. If D had all those missing features, or if you compared D to some other mainly-GC:ed, statically typed and compiled language, I think the syntax comparison would have been more fair.
- mhh__ 7y ago
  Which missing features?
  - dymk 7y ago
    Say, the whole C++ ecosystem
    - 256 7y ago
      I don't think that's fair. D interfaces with C++ better than any other language I can think of. See https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
      - pjmlp 7y ago
        Delphi and .NET also come to mind, due to C++ Builder and C++/CLI respectively. :) Or via COM, which D also supports.
    - nicwilson 7y ago
      Its getting there https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
mhh__ 7y ago
Even when I only really need C, the contract programming that D provides is really helpful as it provides a macro free way of doing rigorous assertions etc. in a way that I can turn off without infecting the actual logic code. If a struct's payload cannot be null, for example, getting the compiler to insert checks into all uses in debug builds can be done easily That and metaprogramming in D is all compile time so you get RSI-free hands, for free.
- pjmlp 7y ago
  C++20 is also getting contracts, just as info. The more languages that support DbC the better.
  - vram22 7y ago
    Eiffel may have been one of the first languages to support DbC (Design by Contract). https://en.wikipedia.org/wiki/Design_by_contract#History https://en.wikipedia.org/wiki/Design_by_contract#History
umvi 7y ago
I stopped using `<<` for the most part after I discovered the excellent fmt library[1]. [1] https://github.com/fmtlib/fmt https://github.com/fmtlib/fmt
Ace17 7y ago
> To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around. Visual appearance is a rather weak reason for preferring one language over another (especially if it's for explicitly personal reasons).
- Crinus 7y ago
  Weak or not, it still is a reason as visual appearances affects readability.
- sametmax 7y ago
  Visual appearance and cognitive load are very much linked IMO.
  - rramadass 7y ago
    Very true. This is one of the things i dislike most about templates in C++. Even today reading template code with its nested syntax takes me time to unpack and understand. Symbols do affect comprehension and i would be quite interested in knowing whether somebody has done a study w.r.t. the various programming languages.

petre 7y ago

> For things that don't need classes (and there is a lot of code) I stick to C. I'd use D anyway just for the GC or whatever, less compiler fighting, betterC etc. Procedural, OOP, functional, yay.

rowanG077 7y ago
Really? For me the presence of a GC disqualifies D as the main replacement for C and C++.
- mhh__ 7y ago
  How much software genuinely requires not having a GC? If you don't want it, don't use it, but using it can make your software completely safe and fast (Garbage Collection is often faster than RC as long as pause times are acceptable, and added memory use). A lot of the standard library ranges are inherently lazy and therefore require no interaction with the GC. Exceptions are also nogc now.
  - quicknir 7y ago
    If you can tolerate GC then like 20 languages (as or less obscure than D) enter the conversation. If you can tolerate GC and the performance implications that go with it, then using C or C++ is rarely a good choice to begin with (well, other than legacy, which is a valid and common reason).
    - mhh__ 7y ago
      D isn't defined by performance or memory management, however. There are many D features which are just blisteringly professional in how they approach software development: Using D is conducive to writing good software. Metaprogramming, for example, in D is obvious and almost fun. The compile times are ridiculous compared to C++, i.e. I can build the main D compiler in three different configurations in about 5sec on my machine.
      - quicknir 7y ago
        I'm not saying that D is defined by that. I'm simply saying that if you're comparing to C or C++, you are talking about use cases that are defined by performance and/or memory management (or else, they are being used for legacy reasons). If you have a green field project that doesn't have massive performance concerns, and doesn't have to be specifically in C or C++ for other reasons (toolchain availability, available developer resources, etc), you probably aren't using C or C++. Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.
        WalterBright 7y ago
        There are people who specifically use D for writing high performance applications. They find it faster than C++ for a rather subtle reason - D code is more plastic, meaning it is easier to refactor D code trying out different algorithms looking for a faster one.
  - umanwizard 7y ago
    I’ve seen large, poorly written Java programs[0] where an entire core at 100% is dedicated to the GC. I have never seen that behavior for things like ~shared_ptr in C++ or similar languages. Then again, OOMing due to leaks is something you’re more likely to see in poorly-written systems in non-GC languages (Objective-C, C, C++, etc), so there are certainly trade offs. [0]: Maybe “poorly written” is unfair. Perhaps “written by people who are unaware of how to write code that performs well in a GC system”.
  - krzat 7y ago
    Probably the most important usage of C are shared libraries. How well it will work if I have D library with it's own GC, another Go library with second GC and app written in C# with yet another GC?
  - jcelerier 7y ago
    > Garbage Collection is often faster than RC as long as pause times are acceptable I have never in my life worked in any kind of software where this was remotely acceptable
  - rowanG077 7y ago
    You are right most software it doesn't matter if you have a GC. However then D is not competing against C and C++ it's competing against almost every other language.
- newacct77 7y ago
  D's garbage collector can be disabled, so would you mind elaborating?
  - CameronNemo 7y ago
    How well is that supported by the ecosystem?
    - dymk 7y ago
      Very poorly
    - p0nce 7y ago
      Not using the GC is rather easy, there are plenty of mitigation methods. Not using the D runtime is much more involved. Not linking with the D runtime is a more hardcore endeavour.
  - rowanG077 7y ago
    Yes and then you can't use most of the nice features of D. Forget about libraries.
- nicwilson 7y ago
  Mere presence shouldn't. If you never allocate from it (which is able to be verified very easily with the @nogc attribute), it will never trigger. You can disable it and trigger when you feel it is needed. You can choose to just leak. The default GC is OK, but not great. However it recently was made multithreaded in the mark phase so it is much faster than it used to be. There is a fork based (on linux only IIRC) GC, used by several companies for hard realtime systems, that marks and sweeps in a separate process with CoW pages.
- WalterBright 7y ago
  The -betterC switch to the compiler compiles a D subset that doesn't have a GC.
edwintorok 7y ago
What makes you choose it over Rust or Go?
- 6thaccount2 7y ago
  Not OP, but I can guess. D has a built-in GC by default and doesn't force you to manage memory like Rust. Also, the author mentioned that D is pretty straightforward to anyone with some basic programming knowledge (think C, C++, Java, and C# which fits the majority of coders). Rust is very different from those languages. My main goto language is Python and I can understand D a lot more than Rust which confuses me to no end (disclaimer: I'm a total noob). Go is probably as easy to read as D if not more and is also GC and fast. It is also very spartan. I bet D has a lot of additional features.
- petre 7y ago
  With Rust I always find myself fighting the compiler just like with C, it's very strict about everything, no GC, steep learning curve. Go is okay but you can't get clever with it. You're productive from the start butit becomes routine quite fast and at a certain point there isn't anything new to learn. Error checking is also quite annoying. D has the best of both worlds and it also plays nicely with C/C++, something that the author of Zig also understood is a must have in any language that aims to be a better C/C++. In D one is productive from the start and there's always something new to learn. And one learns it as they code, without having to first read Programming in D by Ali Çehreli to make any sense of the language. I also tried Crystal and liked it but one is more productive in D and Go without any prior knowledge of those languages. I was kind of annoyed by the fact that Crystal removed the for loop, which works perfectly fine in Ruby.
  - edwintorok 7y ago
    You can opt-in to a Gc with Rust via Rc<> and Arc<>: https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis https://words.steveklabnik.com/borrow-checking-escape-analys... Don't get me wrong, I like a language with a Gc by default, my favourite language is OCaml, but I can't claim it to be a drop-in replacement for C projects. Go, Rust (or D) stand a better chance at that.

nextos 7y ago

I also prefer C and D to C++. But used wisely, C++ can be a really nice language after all changes that started with C++11. The key is to realize C++ is not a language, but a federation of languages. You need to cherry pick a subset you what you want to use and stay disciplined. Otherwise, it is a mess.

msla 7y ago
> The key is to realize C++ is not a language, but a federation of languages. You need to cherry pick a subset you what you want to use and stay disciplined. Otherwise, it is a mess. I've noticed two strains in language design, which I internally call Scheme-style and Common Lisp-style: Scheme-style languages are the trimmed-down languages, often built around a big idea which animates the rest of the design but not always; the defining concept of Scheme-style languages is always how much they can remove to get a pure design, a design which supports writing code in one style. Python, Smalltalk, C, and Scheme are all languages in this mold. Java is kind of a compromised Scheme-style language, or two of them (C and Smalltalk) rammed into each other at high speed, which also goes for Objective-C. Common Lisp-style languages have mini-languages inside of them, or at least support multi-paradigm programming as a core design goal; you can trim a Common Lisp-style language into a Scheme-style subset, but you can't extend a Scheme-style language into something more Common Lisp-like unless you really are dealing with Scheme and have (hygienic) macros to use to add more syntax. C++, Perl, and Common Lisp are all Common Lisp-style; Unix shell is Common Lisp-style in practice because it encourages programmers to write in a bunch of relatively Scheme-style languages at once, all in the same program. Note that both Scheme and Common Lisp have a conceptual core in the Lambda Calculus and axiom-like special forms. C++ lacks this and Perl doesn't really have it either, but most people don't write huge codebases in Perl.
- kazinator 7y ago
  Scheme is only about removing features from a language document, not from actual systems.
  - gmfawcett 7y ago

strictfp 7y ago

>> I've preferred C to C++ and D to C++ for a long time. To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around. I'm sorry, but even though I think D is a great language, there are plenty of usecases where D isn't a viable alternative to neither C or C++. If D had all those missing features, or if you compared D to some other mainly-GC:ed, statically typed and compiled language, I think the syntax comparison would have been more fair.

mhh__ 7y ago
Which missing features?
- dymk 7y ago
  Say, the whole C++ ecosystem
  - 256 7y ago
    I don't think that's fair. D interfaces with C++ better than any other language I can think of. See https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
    - pjmlp 7y ago
      Delphi and .NET also come to mind, due to C++ Builder and C++/CLI respectively. :) Or via COM, which D also supports.
  - nicwilson 7y ago
    Its getting there https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp

mhh__ 7y ago

Even when I only really need C, the contract programming that D provides is really helpful as it provides a macro free way of doing rigorous assertions etc. in a way that I can turn off without infecting the actual logic code. If a struct's payload cannot be null, for example, getting the compiler to insert checks into all uses in debug builds can be done easily That and metaprogramming in D is all compile time so you get RSI-free hands, for free.

pjmlp 7y ago
C++20 is also getting contracts, just as info. The more languages that support DbC the better.
- vram22 7y ago
  Eiffel may have been one of the first languages to support DbC (Design by Contract). https://en.wikipedia.org/wiki/Design_by_contract#History https://en.wikipedia.org/wiki/Design_by_contract#History

umvi 7y ago

I stopped using `<<` for the most part after I discovered the excellent fmt library[1]. [1] https://github.com/fmtlib/fmt https://github.com/fmtlib/fmt

Ace17 7y ago

> To me when I read C++ code it's like the modem disconnected in the middle of the editing session with all the : and << flying around. Visual appearance is a rather weak reason for preferring one language over another (especially if it's for explicitly personal reasons).

Crinus 7y ago
Weak or not, it still is a reason as visual appearances affects readability.
sametmax 7y ago
Visual appearance and cognitive load are very much linked IMO.
- rramadass 7y ago
  Very true. This is one of the things i dislike most about templates in C++. Even today reading template code with its nested syntax takes me time to unpack and understand. Symbols do affect comprehension and i would be quite interested in knowing whether somebody has done a study w.r.t. the various programming languages.