8 ms·

Once I've gotten a better grasp on C, I plan on moving up to a language with a few more conveniences for day to day programming. It's between D, Rust, and C++.

Once I've gotten a better grasp on C, I plan on moving up to a language with a few more conveniences for day to day programming. It's between D, Rust, and C++. I feel like the safe bet is C++, but since I don't plan on getting hired to do it, Rust and D are also in contention. I like the idea of using D with a garbage collector and having something like GO, and then turning it off when I want to do something more performance oriented. How is the performance of D compared to other garbage collected languages when the garbage collector is turned on?

bsaul 6y ago
The idea of having a language that can work with or without a garbage collector in different part of a code seems completely impossible to manage to me. How can this even work in practice ? Do you have twice the stdlib ? Twice the libraries ? I'm pretty sure the D guys figured it out, but i'm really curious to see what's the end result in the real world, once it reaches the dirty hands of end-product developers :))
- WalterBright 6y ago
  Most of my programs tend to be a mix of GC allocations and malloc allocations. They work together rather smoothly.
  - Thiez 6y ago
    How does that work? As I understand it the D GC scans the stack and the GC heap memory for pointers (or values looking like pointers) to determine which objects are reachable. But can the GC scan memory allocated by malloc? How does it know whether a value allocated with malloc has since been freed?
    - david2ndaccount 6y ago
      You call a function to register and deregister a region of memory as potentially holding pointers to Gc-allocated memory.
      - Thiez 6y ago
        Right, but if you do that, is there any advantage over just allocating that memory directly from the GC instead of calling malloc and then registering the memory?
    - mhh__ 6y ago
      The GC is precise where it matters but has no interest in memory you allocate yourself (exceptions to this rule exist but they're fairly obvious). You don't need to worry about it nearly always.
      - Thiez 6y ago
        So you don't want to store pointers to GC objects in memory allocated yourself, or it may get freed if there are no other pointers? Seems like quite the footgun.
        mhh__ 6y ago
        Basically in this situation you have to inform the GC but realistically this extremely rare in practice. Of the issues the GC has, this isn't one of 'em.
        destructionator 6y ago
        You do have to be legitimately careful with that. I've tripped myself before while sending objects through a self-pipe. The D GC only runs upon a function call, so with a bit of care you can defer runs, but here I allocated a new object while another one was still in the kernel's pipe buffer... and the GC assumed it was dead since it can't see that buffer and reused its memory for the new object. Took me a while to realize what was going on. But on the other hand, I write a lot of D code and often go back to that same story because it isn't terribly common anyway and easy to manage when you know how. Just yeah if you are mixing techniques without knowing the potential issue you can have trouble.
- zozbot234 6y ago
  > The idea of having a language that can work with or without a garbage collector in different part of a code ... How can this even work in practice ? "Pluggable" GC-based arenas could make it work quite well. People routinely use ECS (entity-component systems) frameworks in GC-less languages like Rust that could mesh quite well with GC. You do need some extra glue to harmonize the GC-based and GC-less paradigms (such as adding new "GC roots" for any GC'd objects that are being kept "alive" via links from non-GC ones, and demoting them when the references are dropped) but it's quite doable. Rust will probably get facilities for this once "local allocators" are added to the language in a reasonably stable form.
- mhh__ 6y ago
  The principle is a combination of pragmatism, pain, and then realisation that all memory allocation is slow (allocate less memory). Lots of D code is fundamentally lazy.
  - WalterBright 6y ago
    The fastest memory allocator is no-allocation allocation. D has some cool methods for doing that, like the chain template and voldemort types. For example, chain can be used to "concatenate" two arrays without allocating a byte. https://dlang.org/phobos/std_range.html#chain https://dlang.org/phobos/std_range.html#chain https://wiki.dlang.org/Voldemort_types https://wiki.dlang.org/Voldemort_types
- p0nce 6y ago
  In extreme cases, this can become uneasy and then you need a mental model of what is traceable and what GC "roots" to add. If it's not GC-reachable it gets collected. But in most cases, most people will likely just need custom allocators, or just malloc. You can generate arbitrarily less garbage in D progressively. Mixed allocation strategies is still nice because whatever is in GC memory doesn't need an owner (it has a global owner). Nowadays, the D GC is really unlikely to be a problem whatever your performance requirements. It isn't a problem for corporate users, as you can see on the parent link. Besides the GC performance increased in the last few years.
moonchild 6y ago
> How is the performance of D compared to other garbage collected languages when the garbage collector is turned on? The GC itself isn't very good. The overall language performance, though, is quite good; the allocator isn't usually a bottleneck.
- WalterBright 6y ago
  The GC could be improved by generating extra code when pointer accesses are made, so the GC can keep track of writes to GC allocated memory. This makes the GC faster and more effective, at the expense of slower generated code. It is a worthwhile tradeoff for fully GC languages like Java. But it isn't worthwhile for D, which uses GC here and there and a lot of non-GC pointers and allocations. D trades things off in the other direction - faster runtime code generation, at the cost of a slower GC.
  - MaxBarraclough 6y ago
    > D, which uses GC here and there and a lot of non-GC pointers and allocations Won't this depend on the programming style used? If the programmer makes heavy use of functional programming, or for that matter Java-style programming, wouldn't that result in a lot of object churn through the GC?
    - mhh__ 6y ago
      Functional code as usually written in D doesn't have this problem because people are aware of this - most compositions are extremely lazy, allocations are trivial to group together because of allocators in the stdlib
    - WalterBright 6y ago
      Java does not have stack allocated objects like struct instances. They get allocated via the GC (sometimes the Java optimizer can optimize these to be stack allocated). Personally, I make very heavy use of stack allocated objects, even for temporary buffers. Stack allocated objects cost nothing to allocate, nothing to free, and (being on the stack) are already in the hot memory cache.
mhh__ 6y ago
The performance is going to be exactly the same for almost all code. D is spectacularly good at turning performance up to 11 - inline assembly is a first class thing in D. D also makes generating code at compile time extremely easy which is a performance win at the expense of some compile time (no free lunch) but once again you slide the scale easily as the code the generates it is the same as at runtime. There are two real backends one can use for these kinds of things, or one for Rust (LLVM) and friends.
- WalterBright 6y ago
  Actually, there are 3 D back ends. There's the original Digital Mars C++ backend for DMD, the Gnu Compiler Collection backend for GDC, and the LLVM compiler backend for LDC. Each has their strengths and weaknesses, and some users even switch back and forth depending on what they need at the moment.
  - mhh__ 6y ago
    I was keeping it simple as the DM backend cannot compile (say) Rust whereas LLVM (and sort of GCC) has frontends for both so you can make the comparison. I myself am not in the "move to ldc" camp, I like having dmd available for speed.
ljm 6y ago
Zig is worth a look for C-like stuff, considering the zig compiler is also a legit C compiler now.
- pjmlp 6y ago
  Including use after free experience.
qaq 6y ago
If you plan on getting hired to do it D would be a pretty bad bet.
- mhh__ 6y ago
  I just got hired for more than my parents earn off the back of an email to the right people and I'm 20 - D is small but we have a lot of money per capita as far as I can tell.
  - johnisgood 6y ago
    Nice! Which country?
    - mhh__ 6y ago
      UK - Beyond that I won't comment!
      - johnisgood 6y ago
        Oh that is more than enough, thank you! What I am curious about is if I could get a job there without having education. Here in Eastern Europe they still want a CS degree in many places, showing projects, that are on, say, GitHub is not enough. You simply do not even get to the interviewing part.
        mhh__ 6y ago
        Proving you are worth talking to is the hard bit, and even then the recruiters don't know waffle from insight. Its a fact of life, I think: We are the people who really care about technology, the people we work for usually don't. If you are a student we (D) regularly fund students to work on projects for us. There's more money than you'd think in small communities - don't badger people, but don't be afraid to ask.
        johnisgood 6y ago
yawaramin 6y ago
There are a few more choices in this space--someone mentioned Zig; there's also Nim, OCaml, Go, and even a super-old language that has a modern and well-maintained variant: Object Pascal. Check out https://castle-engine.io/modern_pascal_introduction.html https://castle-engine.io/modern_pascal_introduction.html
astral303 6y ago
Pick up some Java
randomNumber7 6y ago
If you can think like a C programmer, you will be able to write really fast programs in D. D, C++ (and also C# and Java) are very similar languages. If you learn any of those, learning the others will be easy. C++ is just the most complicated because of the accidental complexity of the language.
- otabdeveloper4 6y ago
  No, not at all. C++ is much closer to something like OCaml than to C or Java. The "complexity" is not accidental, and it only seems complex because people are not used to languages with static typing systems. C++ is not complex if you mastered something like the Haskell type system. (C and Java aren't really statically typed; they rely on run-time typing for polymorphism.)
  - oblio 6y ago
    C++ is not complex? The C++ complexity is not accidental? C++ is like Haskell or OCaml? Dude, C++ can still compile C code, right? And how are C++ templates anything like Haskell or OCaml? Aren't they just some fancy text-based code generator thing, at the end of the day? I'm really curious about this as everything I've seen so far contradicts your perspective. Or are you talking just about modern C++ (post C++ 11)? That doesn't work as C++ of all kinds is out there in the wild and you'll run into it, at least from external dependencies.
    - otabdeveloper4 6y ago
      > C++ is not complex? The C++ complexity is not accidental? C++ is like Haskell or OCaml? C++ doesn't compete with Java or Go, C++ competes in the "polymorphism via static typing" niche along with Haskell, Ocaml, etc. If you look at what Haskell at al. need to do to get static polymorphism right then C++ doesn't look at all that complex or strange. > Dude, C++ can still compile C code, right? No, wrong. > And how are C++ templates anything like Haskell or OCaml? C++ templates are a purely functional Lisp-like DSL. > Aren't they just some fancy text-based code generator thing, at the end of the day? So is Haskell. > I'm really curious about this as everything I've seen so far contradicts your perspective. You just don't know C++. People think they do because they learned a bit of C back in college, but they don't. > Or are you talking just about modern C++ (post C++ 11)? C++11 was a decade ago; hardly "modern". > That doesn't work as C++ of all kinds is out there in the wild and you'll run into it, at least from external dependencies. There's lots of legacy crap out there in the wild, including legacy COBOL and legacy Haskell. I fail to see your point; "modern" C++ isn't some wild departure from the original idea of C++. Ever since STL it has been in a pretty specific and well-defined trajectory.
otabdeveloper4 6y ago
C++ is the language that is changing the fastest of the three. In 5-10 years it will be the most modern choice; D is already legacy.
- deleted 6y ago
  [deleted]
miccah 6y ago
Take a look at V. It's like the love child of Rust and Go. It's extremely fast (both compiling and executing), has simple syntax with "one way to do things", has sum types and option/results with enforced error checking, and it even has a REPL. Oh not to mention it has C interoperability and a native cross-platform GUI library. https://vlang.io/ https://vlang.io/

bsaul 6y ago

The idea of having a language that can work with or without a garbage collector in different part of a code seems completely impossible to manage to me. How can this even work in practice ? Do you have twice the stdlib ? Twice the libraries ? I'm pretty sure the D guys figured it out, but i'm really curious to see what's the end result in the real world, once it reaches the dirty hands of end-product developers :))

WalterBright 6y ago
Most of my programs tend to be a mix of GC allocations and malloc allocations. They work together rather smoothly.
- Thiez 6y ago
  How does that work? As I understand it the D GC scans the stack and the GC heap memory for pointers (or values looking like pointers) to determine which objects are reachable. But can the GC scan memory allocated by malloc? How does it know whether a value allocated with malloc has since been freed?
  - david2ndaccount 6y ago
    You call a function to register and deregister a region of memory as potentially holding pointers to Gc-allocated memory.
    - Thiez 6y ago
      Right, but if you do that, is there any advantage over just allocating that memory directly from the GC instead of calling malloc and then registering the memory?
  - mhh__ 6y ago
    The GC is precise where it matters but has no interest in memory you allocate yourself (exceptions to this rule exist but they're fairly obvious). You don't need to worry about it nearly always.
    - Thiez 6y ago
      So you don't want to store pointers to GC objects in memory allocated yourself, or it may get freed if there are no other pointers? Seems like quite the footgun.
      - mhh__ 6y ago
        Basically in this situation you have to inform the GC but realistically this extremely rare in practice. Of the issues the GC has, this isn't one of 'em.
      - destructionator 6y ago
        You do have to be legitimately careful with that. I've tripped myself before while sending objects through a self-pipe. The D GC only runs upon a function call, so with a bit of care you can defer runs, but here I allocated a new object while another one was still in the kernel's pipe buffer... and the GC assumed it was dead since it can't see that buffer and reused its memory for the new object. Took me a while to realize what was going on. But on the other hand, I write a lot of D code and often go back to that same story because it isn't terribly common anyway and easy to manage when you know how. Just yeah if you are mixing techniques without knowing the potential issue you can have trouble.
zozbot234 6y ago
> The idea of having a language that can work with or without a garbage collector in different part of a code ... How can this even work in practice ? "Pluggable" GC-based arenas could make it work quite well. People routinely use ECS (entity-component systems) frameworks in GC-less languages like Rust that could mesh quite well with GC. You do need some extra glue to harmonize the GC-based and GC-less paradigms (such as adding new "GC roots" for any GC'd objects that are being kept "alive" via links from non-GC ones, and demoting them when the references are dropped) but it's quite doable. Rust will probably get facilities for this once "local allocators" are added to the language in a reasonably stable form.
mhh__ 6y ago
The principle is a combination of pragmatism, pain, and then realisation that all memory allocation is slow (allocate less memory). Lots of D code is fundamentally lazy.
- WalterBright 6y ago
  The fastest memory allocator is no-allocation allocation. D has some cool methods for doing that, like the chain template and voldemort types. For example, chain can be used to "concatenate" two arrays without allocating a byte. https://dlang.org/phobos/std_range.html#chain https://dlang.org/phobos/std_range.html#chain https://wiki.dlang.org/Voldemort_types https://wiki.dlang.org/Voldemort_types
p0nce 6y ago
In extreme cases, this can become uneasy and then you need a mental model of what is traceable and what GC "roots" to add. If it's not GC-reachable it gets collected. But in most cases, most people will likely just need custom allocators, or just malloc. You can generate arbitrarily less garbage in D progressively. Mixed allocation strategies is still nice because whatever is in GC memory doesn't need an owner (it has a global owner). Nowadays, the D GC is really unlikely to be a problem whatever your performance requirements. It isn't a problem for corporate users, as you can see on the parent link. Besides the GC performance increased in the last few years.

moonchild 6y ago

> How is the performance of D compared to other garbage collected languages when the garbage collector is turned on? The GC itself isn't very good. The overall language performance, though, is quite good; the allocator isn't usually a bottleneck.

WalterBright 6y ago
The GC could be improved by generating extra code when pointer accesses are made, so the GC can keep track of writes to GC allocated memory. This makes the GC faster and more effective, at the expense of slower generated code. It is a worthwhile tradeoff for fully GC languages like Java. But it isn't worthwhile for D, which uses GC here and there and a lot of non-GC pointers and allocations. D trades things off in the other direction - faster runtime code generation, at the cost of a slower GC.
- MaxBarraclough 6y ago
  > D, which uses GC here and there and a lot of non-GC pointers and allocations Won't this depend on the programming style used? If the programmer makes heavy use of functional programming, or for that matter Java-style programming, wouldn't that result in a lot of object churn through the GC?
  - mhh__ 6y ago
    Functional code as usually written in D doesn't have this problem because people are aware of this - most compositions are extremely lazy, allocations are trivial to group together because of allocators in the stdlib
  - WalterBright 6y ago
    Java does not have stack allocated objects like struct instances. They get allocated via the GC (sometimes the Java optimizer can optimize these to be stack allocated). Personally, I make very heavy use of stack allocated objects, even for temporary buffers. Stack allocated objects cost nothing to allocate, nothing to free, and (being on the stack) are already in the hot memory cache.

mhh__ 6y ago

The performance is going to be exactly the same for almost all code. D is spectacularly good at turning performance up to 11 - inline assembly is a first class thing in D. D also makes generating code at compile time extremely easy which is a performance win at the expense of some compile time (no free lunch) but once again you slide the scale easily as the code the generates it is the same as at runtime. There are two real backends one can use for these kinds of things, or one for Rust (LLVM) and friends.

WalterBright 6y ago
Actually, there are 3 D back ends. There's the original Digital Mars C++ backend for DMD, the Gnu Compiler Collection backend for GDC, and the LLVM compiler backend for LDC. Each has their strengths and weaknesses, and some users even switch back and forth depending on what they need at the moment.
- mhh__ 6y ago
  I was keeping it simple as the DM backend cannot compile (say) Rust whereas LLVM (and sort of GCC) has frontends for both so you can make the comparison. I myself am not in the "move to ldc" camp, I like having dmd available for speed.

ljm 6y ago

Zig is worth a look for C-like stuff, considering the zig compiler is also a legit C compiler now.

pjmlp 6y ago
Including use after free experience.

qaq 6y ago

If you plan on getting hired to do it D would be a pretty bad bet.

mhh__ 6y ago
I just got hired for more than my parents earn off the back of an email to the right people and I'm 20 - D is small but we have a lot of money per capita as far as I can tell.
- johnisgood 6y ago
  Nice! Which country?
  - mhh__ 6y ago
    UK - Beyond that I won't comment!
    - johnisgood 6y ago
      Oh that is more than enough, thank you! What I am curious about is if I could get a job there without having education. Here in Eastern Europe they still want a CS degree in many places, showing projects, that are on, say, GitHub is not enough. You simply do not even get to the interviewing part.
      - mhh__ 6y ago
        Proving you are worth talking to is the hard bit, and even then the recruiters don't know waffle from insight. Its a fact of life, I think: We are the people who really care about technology, the people we work for usually don't. If you are a student we (D) regularly fund students to work on projects for us. There's more money than you'd think in small communities - don't badger people, but don't be afraid to ask.
        johnisgood 6y ago

yawaramin 6y ago

There are a few more choices in this space--someone mentioned Zig; there's also Nim, OCaml, Go, and even a super-old language that has a modern and well-maintained variant: Object Pascal. Check out https://castle-engine.io/modern_pascal_introduction.html https://castle-engine.io/modern_pascal_introduction.html

astral303 6y ago

Pick up some Java

randomNumber7 6y ago

If you can think like a C programmer, you will be able to write really fast programs in D. D, C++ (and also C# and Java) are very similar languages. If you learn any of those, learning the others will be easy. C++ is just the most complicated because of the accidental complexity of the language.

otabdeveloper4 6y ago
No, not at all. C++ is much closer to something like OCaml than to C or Java. The "complexity" is not accidental, and it only seems complex because people are not used to languages with static typing systems. C++ is not complex if you mastered something like the Haskell type system. (C and Java aren't really statically typed; they rely on run-time typing for polymorphism.)
- oblio 6y ago
  C++ is not complex? The C++ complexity is not accidental? C++ is like Haskell or OCaml? Dude, C++ can still compile C code, right? And how are C++ templates anything like Haskell or OCaml? Aren't they just some fancy text-based code generator thing, at the end of the day? I'm really curious about this as everything I've seen so far contradicts your perspective. Or are you talking just about modern C++ (post C++ 11)? That doesn't work as C++ of all kinds is out there in the wild and you'll run into it, at least from external dependencies.
  - otabdeveloper4 6y ago
    > C++ is not complex? The C++ complexity is not accidental? C++ is like Haskell or OCaml? C++ doesn't compete with Java or Go, C++ competes in the "polymorphism via static typing" niche along with Haskell, Ocaml, etc. If you look at what Haskell at al. need to do to get static polymorphism right then C++ doesn't look at all that complex or strange. > Dude, C++ can still compile C code, right? No, wrong. > And how are C++ templates anything like Haskell or OCaml? C++ templates are a purely functional Lisp-like DSL. > Aren't they just some fancy text-based code generator thing, at the end of the day? So is Haskell. > I'm really curious about this as everything I've seen so far contradicts your perspective. You just don't know C++. People think they do because they learned a bit of C back in college, but they don't. > Or are you talking just about modern C++ (post C++ 11)? C++11 was a decade ago; hardly "modern". > That doesn't work as C++ of all kinds is out there in the wild and you'll run into it, at least from external dependencies. There's lots of legacy crap out there in the wild, including legacy COBOL and legacy Haskell. I fail to see your point; "modern" C++ isn't some wild departure from the original idea of C++. Ever since STL it has been in a pretty specific and well-defined trajectory.

otabdeveloper4 6y ago

C++ is the language that is changing the fastest of the three. In 5-10 years it will be the most modern choice; D is already legacy.

deleted 6y ago
[deleted]

miccah 6y ago

Take a look at V. It's like the love child of Rust and Go. It's extremely fast (both compiling and executing), has simple syntax with "one way to do things", has sum types and option/results with enforced error checking, and it even has a REPL. Oh not to mention it has C interoperability and a native cross-platform GUI library. https://vlang.io/ https://vlang.io/