7 ms·

In theory that's D. D was designed to be easier to parse than C++, for example, it uses Foo!Bar and Foo!(Bar, 4) template syntax rather than Foo<Bar> and Foo<Ba

In theory that's D. D was designed to be easier to parse than C++, for example, it uses Foo!Bar and Foo!(Bar, 4) template syntax rather than Foo<Bar> and Foo<Bar, 4>. On the other hand, it still uses templates and supports mixins (basically #define on steroids), so while it's easy to parse, large chunks of code don't exist until compile time so can't be indexed by IDEs perfectly.

pjmlp 7y ago
And as much as I like their community, I feel it already lost its spotlight opportunity, due to their lack of manpower vs other languages offerings and continuous improvements. Even if C++ is a little baroque, C++17 and now C++20 provide many of the D's benefits, while keeping all the libraries, and finally we are getting Java like C++'s tooling to just throw it away.
- otabdeveloper4 7y ago
  > due to their lack of manpower vs other languages offerings and continuous improvements No. D failed due to a mandatory GC and the 'two standard libraries' idiocy.
  - pjmlp 7y ago
    Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C++, those devs will have a very tiny niche to contend with. I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development.
    - jstimpfle 7y ago
      > I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing, and you can't have nice names for things. Assembly->Compiler is a huge step compared to MM->GC, and GC can cause a lot of headaches as well. (disclaimer, I've done almost no assembly at all).
      - pjmlp 7y ago
        On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.
        gpderetta 7y ago
        Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
        bitwize 7y ago
        Try Rust. Proven memory safety, no GC.
        gpderetta 7y ago
        no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!
        pjmlp 7y ago
        Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.
    - jacobush 7y ago
      Plenty did but none took a chunk out the C++ world that thrives on manual memory mgmt.
      - pjmlp 7y ago
        The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.
        gmueckl 7y ago
        I don't think that your statement about C with C++ compilers holds true anymore. I have seen quite a few codebases that are definitely C++, but use bespoke memory management strategies where required. Pool allocators and allocation-only heaps are high on the list of things that are useful in this area, for various reasons.
        bluGill 7y ago
        I'd call most of that C with classes.
        gmueckl 7y ago
        As ooposed to what? This is the core of C++, even though feature creep has opened up the language to other coding styles and patterns.
        jacobush 7y ago
        I should have said "not garbage collection" instead of manual memory management.
        pjmlp 7y ago
        Reference counting, regardless how it is implemented (language primitives or library), is a garbage collection algorithm.
    - bitwize 7y ago
      Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a systems programming language.
      - pjmlp 7y ago
        Interestingly I never saw that phenomen on ETHZ graphical Workstations powered by AOS. And apparently no one noticed that a part of Bing used Midori for a while. That is alrigth, according to Midori team, Windows team also did not accept what Midori was capable of, even when proven wrong. Having a GC is non different than malloc spending all its time doing context switches to reclaim more OS memory, using the actual OS memory management APIs. It is up to the developers to decided to use a GC based allocation, stack, global memory segment or plain untraced heap allocations. The tools are there, naturally there is a learning process that many seem unwilling to do. And by the way, Swift's reference counting implementation gets wiped out by tracing GCs on the ixy paper.
      - ChrisLomont 7y ago
        >Building a GC into your system means building nondeterministic amounts of latency into it That's not true. You can pool, you can call GC when needed, you can build incremental GC with bounded times, and so on. Check stackoverflow - there's plenty of links to papers and real-world examples of fixed-time garbage collectors. Or check google scholar and read papers. Go has demonstrated a very efficient garbage collector. Here [1] is one from Oracle for Java. >If your language requires a GC, it is a complete failure as a systems programming language. Plenty of OSes are in development and/or researched using managed languages and GC. Singularity [2] is but one example. I suspect in the future that doing memory management by hand will be as obsolete as writing an OS in assembly. The benefits for security, robustness, and productivity will outweigh the costs, just like the benefits for using higher languages to develop in, while slower than hand-tuned assembly, far outweigh the costs. [1] https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-1517310.pdf https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-... [2] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
    - biggestdecision 7y ago
      Swift's GC is really a lot closer to modern C++ style memory management than the other languages you mentioned. If you use RAII & shared_ptr in C++ you are using the exact same techniques that Swift's "GC" uses.
      - pjmlp 7y ago
        And as proven by the ixy paper, quite slow versus tracing GCs.
        biggestdecision 7y ago
        I assume this is what you are talking about? https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/the-case-for-writing-network-drivers-in-high-level-languages.pdf https://www.net.in.tum.de/fileadmin/bibtex/publications/pape... >A total of 76% of the CPU time is spent incrementing and decrementing reference counters. ouch
        pjmlp 7y ago
        Yep, that one.
      - im3w1l 7y ago
        Maybe. But shared_ptr should only be used very sparingly. Almost all objects should be stack or unique_ptr.
    - otabdeveloper4 7y ago
      > I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. Yeah, I've heard that 25 years ago. It was, in fact, the big marketing bullet point on Java's first release. Meanwhile here in 2019, with the death of Moore's Law, careful memory (and cache!) management is more important than before.
  - gmueckl 7y ago
    The GC is realistically only an issue in rare fringe cases. Early on, the competing standard libraries were a massive problem, though. This was overcome with D2, which is already more than a decade old. When this standard library competition existed, the library ecosystem had this very weird split where half of the libraries you would have liked to use in your project used the other library you couldn't link to at the same time. This prevented me from picking up and trying D for a long time because I didn't want to deal with that. Now that this is over with and a ton of useful libraries exist, I'm glad that I started to use D because this is now a language in which I'm very productive.
    - otabdeveloper4 7y ago
      > The GC is realistically only an issue in rare fringe cases. Yes, and one of those fringe cases is when you're building a competitor for C++. Knowing your target audience helps if you're trying to take over the world.
- atilaneves 7y ago
  I went back to C++14 a few years ago after writing D and it was painful. The only addition to C++17 that made my life easier was `void_t`, but even then it's not even close. Having to deal with headers again and C++'s templates was torture. Did C++ close the gap? Yes. However, I can still write D 2-3x faster than I can write C++. It's similar to how I'm 2-3x more productive in C++ than in C.
  - pjmlp 7y ago
    I only use C++ alongside Java and .NET, when they need an extra help. The problem with D in its current state is that its tooling isn't match for OS SDKs + IDE + libraries, beyond the typical POSIX daemon scenarios, unless one is willing to put some effort into it. So it is hard to catch up to C++, specially after all major compilers reach C++20 compliance.
rienbdj 7y ago
Not quite, because D brings many other things. I mean something that is equivalent to C++, with all of the same semantics, but a less ambiguous grammar.

pjmlp 7y ago

And as much as I like their community, I feel it already lost its spotlight opportunity, due to their lack of manpower vs other languages offerings and continuous improvements. Even if C++ is a little baroque, C++17 and now C++20 provide many of the D's benefits, while keeping all the libraries, and finally we are getting Java like C++'s tooling to just throw it away.

otabdeveloper4 7y ago
> due to their lack of manpower vs other languages offerings and continuous improvements No. D failed due to a mandatory GC and the 'two standard libraries' idiocy.
- pjmlp 7y ago
  Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C++, those devs will have a very tiny niche to contend with. I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development.
  - jstimpfle 7y ago
    > I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing, and you can't have nice names for things. Assembly->Compiler is a huge step compared to MM->GC, and GC can cause a lot of headaches as well. (disclaimer, I've done almost no assembly at all).
    - pjmlp 7y ago
      On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.
      - gpderetta 7y ago
        Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++. For me the big attraction of GC is memory safety not convenience.
        bitwize 7y ago
        Try Rust. Proven memory safety, no GC.
        gpderetta 7y ago
        no opportunity at $CURRENT_JOB, but in the future, sure, it is definitely on my radar!
        pjmlp 7y ago
        Until one tries to do GUI programming, then it is Rc<RefCell<>> everywhere, or arrays with vector clocks for managing old entries.
  - jacobush 7y ago
    Plenty did but none took a chunk out the C++ world that thrives on manual memory mgmt.
    - pjmlp 7y ago
      The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.
      - gmueckl 7y ago
        I don't think that your statement about C with C++ compilers holds true anymore. I have seen quite a few codebases that are definitely C++, but use bespoke memory management strategies where required. Pool allocators and allocation-only heaps are high on the list of things that are useful in this area, for various reasons.
        bluGill 7y ago
        I'd call most of that C with classes.
        gmueckl 7y ago
        As ooposed to what? This is the core of C++, even though feature creep has opened up the language to other coding styles and patterns.
      - jacobush 7y ago
        I should have said "not garbage collection" instead of manual memory management.
        pjmlp 7y ago
        Reference counting, regardless how it is implemented (language primitives or library), is a garbage collection algorithm.
  - bitwize 7y ago
    Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a systems programming language.
    - pjmlp 7y ago
      Interestingly I never saw that phenomen on ETHZ graphical Workstations powered by AOS. And apparently no one noticed that a part of Bing used Midori for a while. That is alrigth, according to Midori team, Windows team also did not accept what Midori was capable of, even when proven wrong. Having a GC is non different than malloc spending all its time doing context switches to reclaim more OS memory, using the actual OS memory management APIs. It is up to the developers to decided to use a GC based allocation, stack, global memory segment or plain untraced heap allocations. The tools are there, naturally there is a learning process that many seem unwilling to do. And by the way, Swift's reference counting implementation gets wiped out by tracing GCs on the ixy paper.
    - ChrisLomont 7y ago
      >Building a GC into your system means building nondeterministic amounts of latency into it That's not true. You can pool, you can call GC when needed, you can build incremental GC with bounded times, and so on. Check stackoverflow - there's plenty of links to papers and real-world examples of fixed-time garbage collectors. Or check google scholar and read papers. Go has demonstrated a very efficient garbage collector. Here [1] is one from Oracle for Java. >If your language requires a GC, it is a complete failure as a systems programming language. Plenty of OSes are in development and/or researched using managed languages and GC. Singularity [2] is but one example. I suspect in the future that doing memory management by hand will be as obsolete as writing an OS in assembly. The benefits for security, robustness, and productivity will outweigh the costs, just like the benefits for using higher languages to develop in, while slower than hand-tuned assembly, far outweigh the costs. [1] https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-1517310.pdf https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-... [2] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
  - biggestdecision 7y ago
    Swift's GC is really a lot closer to modern C++ style memory management than the other languages you mentioned. If you use RAII & shared_ptr in C++ you are using the exact same techniques that Swift's "GC" uses.
    - pjmlp 7y ago
      And as proven by the ixy paper, quite slow versus tracing GCs.
      - biggestdecision 7y ago
        I assume this is what you are talking about? https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/the-case-for-writing-network-drivers-in-high-level-languages.pdf https://www.net.in.tum.de/fileadmin/bibtex/publications/pape... >A total of 76% of the CPU time is spent incrementing and decrementing reference counters. ouch
        pjmlp 7y ago
        Yep, that one.
    - im3w1l 7y ago
      Maybe. But shared_ptr should only be used very sparingly. Almost all objects should be stack or unique_ptr.
  - otabdeveloper4 7y ago
    > I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. Yeah, I've heard that 25 years ago. It was, in fact, the big marketing bullet point on Java's first release. Meanwhile here in 2019, with the death of Moore's Law, careful memory (and cache!) management is more important than before.
- gmueckl 7y ago
  The GC is realistically only an issue in rare fringe cases. Early on, the competing standard libraries were a massive problem, though. This was overcome with D2, which is already more than a decade old. When this standard library competition existed, the library ecosystem had this very weird split where half of the libraries you would have liked to use in your project used the other library you couldn't link to at the same time. This prevented me from picking up and trying D for a long time because I didn't want to deal with that. Now that this is over with and a ton of useful libraries exist, I'm glad that I started to use D because this is now a language in which I'm very productive.
  - otabdeveloper4 7y ago
    > The GC is realistically only an issue in rare fringe cases. Yes, and one of those fringe cases is when you're building a competitor for C++. Knowing your target audience helps if you're trying to take over the world.
atilaneves 7y ago
I went back to C++14 a few years ago after writing D and it was painful. The only addition to C++17 that made my life easier was `void_t`, but even then it's not even close. Having to deal with headers again and C++'s templates was torture. Did C++ close the gap? Yes. However, I can still write D 2-3x faster than I can write C++. It's similar to how I'm 2-3x more productive in C++ than in C.
- pjmlp 7y ago
  I only use C++ alongside Java and .NET, when they need an extra help. The problem with D in its current state is that its tooling isn't match for OS SDKs + IDE + libraries, beyond the typical POSIX daemon scenarios, unless one is willing to put some effort into it. So it is hard to catch up to C++, specially after all major compilers reach C++20 compliance.

rienbdj 7y ago

Not quite, because D brings many other things. I mean something that is equivalent to C++, with all of the same semantics, but a less ambiguous grammar.