5 ms·

C++ will always have a leg up over D for me due to the GC stuff. I like not having GC in C++. When I want a GC'd C-like I use Go. D has to find a space betwee

C++ will always have a leg up over D for me due to the GC stuff. I like not having GC in C++. When I want a GC'd C-like I use Go. D has to find a space between those two for me and a lot of other people. I don't dislike D. I think D has a LOT of great work done in it. I just really want all my libraries to be able to be used without GC. And I'm not sure it's really feasible to have each foot in either world and not just get split down the middle. Can someone argue against this worry? It's literally the only thing stopping me spending more time with D. Also I've been coding in Ada (lord help me) for fun. Contracts are interesting.

loeg 10y ago
I've been told (in other threads on HN) that you can disable GC in D. I don't know how that integrates with stdlib (or other library) bits that use GC (are they disallowed, or do they fail at runtime?).
- lossolo 10y ago
  You can't allocate with GC in @nogc functions, you will get compile time error. There is ongoing work in standard library (Phobos) to make it work without GC.
  - loeg 10y ago
    So if you @nogc main(), you're set? Thanks.
    - andralex 10y ago
      Affirmative.
shakna 10y ago
You don't have to have GC in D, and manual memory can work side-by-side the GC with or without disabling it. You can delete objects early, or call GC.disable
- bachmeier 10y ago
  The safer approach is to mark that code @nogc. There is no guarantee that the GC won't run when calling GC.disable. You do get a guarantee with @nogc.
  - destructionator 10y ago
    > There is no guarantee that the GC won't run when calling GC.disable. If you have called GC.disable, the collector becomes `return;`. Sure, the GC function is called, but it doesn't do anything, it just immediately returns.
    - bachmeier 10y ago
      I'm not sure tbh. The documentation says "Collections may continue to occur in instances where the implementation deems necessary for correct program behavior, such as during an out of memory condition." My understanding from the forum discussions is that a collection could happen and you would not know about it.
penpapersw 10y ago
An important factor in choosing a language is platform. I'm not going to choose Go or D to write an iOS app in, because it would be painful and buggy, if it's even possible in the first place. I'm restricted to Objective-C(++) if I want it to really be a high quality & native app.
- johncolanduoni 10y ago
  Most languages with a C FFI (and ARM/Mach-O compiler support) can do pretty well on iOS. Rust bindings to Objective-C APIs are pretty painless for example.
- klickverbot 10y ago
  D can interface with Objective-C just fine. The Apple-provided tooling will indeed be more convenient for the developer, but the result the end user sees will be a "high quality & native app" just the same.
phaylon 10y ago
I'm only lurking on the D forums, so this should probably be taken with a grain of salt. From what I understand the GC is required for various array, hash map and string operations, and things like closures and exceptions (maybe assertions?). Though there is work being done on fixes and alternatives (scope limitations, ref counted things). This does seem to come up sometimes. I'm wondering if it makes sense to add a "end-vision for GC-less D" section to the D GC documentation, now that there are various undertakings to make it easier. Might also help with finding volunteers that care about @nogc to help out with various bits.
- WalterBright 10y ago
  There is a pull request in now to make throwing exceptions GC-free. It hasn't been merged yet, but should be soon.
atilaneves 10y ago
There's been a lot of work recently to enable GC-free D code. Yes, that means some of the standard library is off bounds, as are some of the built-in operators (new, array concatenation). However, you can have _static_ guarantees that there will be no GC allocations whatsoever. Writing an executable? `void main() @nogc { /* ... */ }` Done. I've written a log of `@nogc` code lately.
- gpderetta 10y ago
  Then what? How much of the standard library and the library ecosystem compiles with nogc? Subsetting languages (and comunities) usually doesn't end well...
  - atilaneves 10y ago
    Depends on the kind of code you write. std.algorithm? No problem
buzzybee 10y ago
Remedy Entertainment has a talk - actually two talks, one from 2013 and one from 2016 [0], about how they added D to their game engine, replacing a major subsystem, and then shipped a AAA title(Quantum Break) with it. The GC did not present a major issue although the talk notes that their solution was "unfinished" and got the result they wanted by wasting memory instead of what they initially aimed for(ARC, this is work-in-progress for D [1][2]). Most of the nuts-and-bolts work came from achieving smooth integration with the C++ codebase, and building for the release devices. [0] http://dconf.org/2016/talks/watson.html http://dconf.org/2016/talks/watson.html [1] https://wiki.dlang.org/Language_design_discussions#Automatic_Reference_Counting_.28ARC.29_as_an_alternative_to_D.27s_Garbage_Collector https://wiki.dlang.org/Language_design_discussions#Automatic... [2] http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D_296740.html http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D...
- pixel_fcker 10y ago
  The slides say the GC never collects, which is the same as having no GC.
p0nce 10y ago
After a while decreasing GC usage in D, I ended up removing it completely. I got reduced memory usage but no speed gain. What I've found is that before you remove the GC, you can turn the overhead from excessive to very affordable with optimizations. Especially today with std.experimental.allocator and -profile=gc

loeg 10y ago

I've been told (in other threads on HN) that you can disable GC in D. I don't know how that integrates with stdlib (or other library) bits that use GC (are they disallowed, or do they fail at runtime?).

lossolo 10y ago
You can't allocate with GC in @nogc functions, you will get compile time error. There is ongoing work in standard library (Phobos) to make it work without GC.
- loeg 10y ago
  So if you @nogc main(), you're set? Thanks.
  - andralex 10y ago
    Affirmative.

shakna 10y ago

You don't have to have GC in D, and manual memory can work side-by-side the GC with or without disabling it. You can delete objects early, or call GC.disable

bachmeier 10y ago
The safer approach is to mark that code @nogc. There is no guarantee that the GC won't run when calling GC.disable. You do get a guarantee with @nogc.
- destructionator 10y ago
  > There is no guarantee that the GC won't run when calling GC.disable. If you have called GC.disable, the collector becomes `return;`. Sure, the GC function is called, but it doesn't do anything, it just immediately returns.
  - bachmeier 10y ago
    I'm not sure tbh. The documentation says "Collections may continue to occur in instances where the implementation deems necessary for correct program behavior, such as during an out of memory condition." My understanding from the forum discussions is that a collection could happen and you would not know about it.

penpapersw 10y ago

An important factor in choosing a language is platform. I'm not going to choose Go or D to write an iOS app in, because it would be painful and buggy, if it's even possible in the first place. I'm restricted to Objective-C(++) if I want it to really be a high quality & native app.

johncolanduoni 10y ago
Most languages with a C FFI (and ARM/Mach-O compiler support) can do pretty well on iOS. Rust bindings to Objective-C APIs are pretty painless for example.
klickverbot 10y ago
D can interface with Objective-C just fine. The Apple-provided tooling will indeed be more convenient for the developer, but the result the end user sees will be a "high quality & native app" just the same.

phaylon 10y ago

I'm only lurking on the D forums, so this should probably be taken with a grain of salt. From what I understand the GC is required for various array, hash map and string operations, and things like closures and exceptions (maybe assertions?). Though there is work being done on fixes and alternatives (scope limitations, ref counted things). This does seem to come up sometimes. I'm wondering if it makes sense to add a "end-vision for GC-less D" section to the D GC documentation, now that there are various undertakings to make it easier. Might also help with finding volunteers that care about @nogc to help out with various bits.

WalterBright 10y ago
There is a pull request in now to make throwing exceptions GC-free. It hasn't been merged yet, but should be soon.

atilaneves 10y ago

There's been a lot of work recently to enable GC-free D code. Yes, that means some of the standard library is off bounds, as are some of the built-in operators (new, array concatenation). However, you can have _static_ guarantees that there will be no GC allocations whatsoever. Writing an executable? `void main() @nogc { /* ... */ }` Done. I've written a log of `@nogc` code lately.

gpderetta 10y ago
Then what? How much of the standard library and the library ecosystem compiles with nogc? Subsetting languages (and comunities) usually doesn't end well...
- atilaneves 10y ago
  Depends on the kind of code you write. std.algorithm? No problem

buzzybee 10y ago

Remedy Entertainment has a talk - actually two talks, one from 2013 and one from 2016 [0], about how they added D to their game engine, replacing a major subsystem, and then shipped a AAA title(Quantum Break) with it. The GC did not present a major issue although the talk notes that their solution was "unfinished" and got the result they wanted by wasting memory instead of what they initially aimed for(ARC, this is work-in-progress for D [1][2]). Most of the nuts-and-bolts work came from achieving smooth integration with the C++ codebase, and building for the release devices. [0] http://dconf.org/2016/talks/watson.html http://dconf.org/2016/talks/watson.html [1] https://wiki.dlang.org/Language_design_discussions#Automatic_Reference_Counting_.28ARC.29_as_an_alternative_to_D.27s_Garbage_Collector https://wiki.dlang.org/Language_design_discussions#Automatic... [2] http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D_296740.html http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D...

pixel_fcker 10y ago
The slides say the GC never collects, which is the same as having no GC.

p0nce 10y ago

After a while decreasing GC usage in D, I ended up removing it completely. I got reduced memory usage but no speed gain. What I've found is that before you remove the GC, you can turn the overhead from excessive to very affordable with optimizations. Especially today with std.experimental.allocator and -profile=gc