Hacker News Reader

Comment by Decabytes | Hacker News Reader

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?

View on HN

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

Including use after free experience.

> 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.

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.

> 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?

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

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.

Why not add a separate, optional compilation mode that uses barriers?

To make it effective, you'd only want it to apply to GC pointers. But the type system does not distinguish between GC pointers and other pointers, making such a mode a rather complex implementation problem.

In java-like situations where something like that would see use, I think it would be fair to treat all pointers as gc pointers.

In Java, all pointers are GC pointers. But in D, not very many are. For example, objects on the stack aren't GC pointers.

Objects on the stack aren't pointers at all...

If you have a struct on the stack, and call member functions, you've got pointers. For an array on the stack, taking a slice of it or looping through it with pointers, you've got pointers. For a variable on the stack, passing it by ref to another function, there are pointers.

The problem of D GC is it doesn't scale at all

The more pointers you need to scan, the slower it becomes, and it'll stop all threads

It's fine for a compiler or a cli tool, but it's very bad for anything that runs forever and needs to scale (server and games, specially networked games where the world and number of entities is not fixed) you then need to think about managing your memory and working around the GC a lot; then you think about yourself, why use GC at all..

D needs invest more into non GC stuff and making the GC trully optional, make it possible to link the GC away if you don't need it, make the runtime less dependent on GC (ability to statically make GC usages assert such as 'new', rework associative array, and cleanup the runtime from requiring GC, thread, socket etc etc etc)

I use D everyday, i know how to deal with that kind of issue, but new people don't, and they might be turned off the day they need to workaround GC issues

Dare to elaborate how you manage these GC issues (example code, howtos, etc.)? Thx

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 :))

Most of my programs tend to be a mix of GC allocations and malloc allocations. They work together rather smoothly.

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?

You call a function to register and deregister a region of memory as potentially holding pointers to Gc-allocated memory.

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?

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.

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.

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.

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.

> 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.

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.

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://wiki.dlang.org/Voldemort_types

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.

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

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.

Nice! Which country?

UK - Beyond that I won't comment!

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.

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.

I find coding fun, and I have been coding since I was 10. I did not go to university because I had family problems, and financial problems, along with mental health problems (depression, anxiety, panic attacks and the like). They usually do not care about this though.

I wish they would at least check out my projects, and let me talk about them or something. I would probably work harder and better than some of their employees. I am currently working on a game and I do not sleep for 2-3 days. I am pretty dedicated when I am interested.

Symmetry Investments hires D programmers every year and is continuously adding new developers.

vs say AWS is very heavily invested in Rust

Rust remains one of the most loved and least used languages in the SO surveys IIRC - ignoring the meme-aspect of that trend - the job market is still swamped by C++ shops.

Realistically programming languages take time to adopt culturally but they aren't that difficult

There are more Rust developers are Amazon that there are D developers in total.

Rust is not one of the least-used languages in SO surveys.

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.

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.)

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.

> 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.

> (C and Java aren't really statically typed; they rely on run-time typing for polymorphism.)

Um, what? Having type information available at runtime is orthogonal to whether or not a language is statically typed.

"Aren't really" means "cannot commit to 100 percent static typing all the way".

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.

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.

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.

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/

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

Pick up some Java

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.

Reply on news.ycombinator.com