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.

Then what? How much of the standard library and the library ecosystem compiles with nogc?

Subsetting languages (and comunities) usually doesn't end well...

Depends on the kind of code you write. std.algorithm? No problem

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

[1] https://wiki.dlang.org/Language_design_discussions#Automatic...

[2] http://www.digitalmars.com/d/archives/digitalmars/D/ARC_in_D...

The slides say the GC never collects, which is the same as having no GC.

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.

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

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

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.

So if you @nogc main(), you're set? Thanks.

Affirmative.

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

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

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.

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

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.

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.

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.

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.