Hacker News new | ask | show | jobs
by gavinray 1224 days ago
I'm not sure I follow

Is this about D code that interops with C/C++?

You have "extern (C++)" and @nogc for that

1 comments

No, it's about pure D code. Some (many) people just don't want a GC in their program and that's why they use C++. If they switch to D, they'll have to put up with a GC if any of their dependencies needs one, and the probability of that being the case is... high.
@nogc eliminates that risk.

The GC also doesn't run if you don't call it so mitigating it's downsides while keeping the good aspects isn't all that hard.

You disable GC for the whole program? And what do you do when one of your dependencies relies on it? Just live with a memory leak?

Bear in mind you're simply not going to convince anti-GC folks that you can have the "good aspects" of a GC without the bad ones, and they're the folks you're trying to market to. To many C++ programmers the only good GC is one that is absent. You can tell them they're wrong all you want, but regardless of who's right, it's always been a losing battle.

It won't compile.

You can also make it so it will compile but won't collect unless you ask it to explicitly.

We don't exclusively market to C++ developers. D replaced PHP and Java for quite a few D users.

It won't compile, and... how is that a solution? You've basically told some users they can't use your language in that case. That's problem solved?

If you see PHP and Java replacement as taking off, that's awesome. I was addressing those who want to see it replace C++.

The express purpose of the @nogc attribute is to enforce that code under it's influence doesn't use the GC.

There is lots of @nogc code available to depend upon

Aye, you can turn off GC entirely, for the whole program

There's even a mode of D that operates this way by default, "-betterC" meant to be a C replacement

The GC really is an entirety opt-in component.

I'd encourage you/other folks to give D an honest try, you might be surprised

You're not understanding my point unfortunately. I never said you can't turn it off. I said if you do, and any of your dependencies expect it to be on, then you have a problem. (Yes, I have tried D. That's how I know this.)
Ohhh, fair enough, yeah I see what you're saying.

Yeah you're boned in that case I think and that's a real problem that can pop up if you want full @nogc

EDIT: Maybe not based on Max's comment

D-Plug (Audio FX plugins) is one example of having to build up a dependency stack of @nogc compatible deps, a lot of that is in-house stuff.

Not impossible but it's a commitment, at which point you may as well use something else unless you REALLY want to use D, for sure.

If you actually turn it off (as in GC.disable()) they won't know either way, it's just a memory allocator to them.