5 ms·

The D Language (http://dlang.org/ http://dlang.org/) has a @nogc pragma (https://dlang.org/spec/attribute.html#nogc https://dlang.org/spec/attribute.html#nogc).

The D Language (http://dlang.org/ http://dlang.org/) has a @nogc pragma (https://dlang.org/spec/attribute.html#nogc https://dlang.org/spec/attribute.html#nogc). You just annotate functions that you don't want to use the GC in with it and it'll assert that they don't use it.

bjz_ 10y ago
But then you lose memory safety
- WalterBright 10y ago
  That's being fixed.
  - Ygg2 10y ago
    Wouldn't that cause duplication of interfaces? Rust had that problem when it went down having no-gc and having gc, too.
    - WalterBright 10y ago
      D's strong support for templates makes that a non-issue.
- deleted 10y ago
  [deleted]
p0nce 10y ago
Since you can: - disable the GC - deregister threads so that they are not stopped by GC - eventually avoid the runtime altogether There really is no realtime system that D can't do. The whole anti-GC thing is a giant strawman that consider all GC stop-the-world, unavoidable, and overarching. Academia decided in favor of GC decades ago, and industry has been following suit for good reasons: mental overhead associated with finding owners to everything.
- jjnoakes 10y ago
  You speak as if a GC is unconditionally better than alternatives and it is a solved problem but using a GC has issues as well. On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free. Ownership is also important for any non-memory resource (file handles, mutexes, etc). GCs release those "whenever", maybe never, unless you close manually. And even though manual memory management has some small non-deterninistic overhead for heap coalescing (which one can usually work around with pools), most GCs I've worked with add measurable overhead. This equates to more cost per server, more load, more battery life drained, higher response times...
  - p0nce 10y ago
    > On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free. I don't think it follows and it's rather the reverse: it what I share has a global owner (ie. the GC), I don't have to lock or copy by definition: once it stops being reachable it will be collected. That's why some lockfree algorithms are enabled by the GC. With ownership you would have to have a unique owner, or reference counts. GC does require write barriers or stop-the-world though so let's say it's a draw :) > Ownership is also important for any non-memory resource (file handles, mutexes, etc). GCs release those "whenever", maybe never, unless you close manually. Yeah, it's a big problem that the GC even attempts poorly to close them. But D has scope guards and RAII builtin so for the 50% of non-memory resources you still have to think about ownership indeed. That's more complicated that the C++ situation. But realtime it does not prevent, you may well find yourself having more time to optimize :)
    - jjnoakes 10y ago
      > if what I share has a global owner (ie. the GC), I don't have to lock or copy by definition Then how you do avoid data races? Two shared references which can mutate your shared data requires either a copy, a lock, immutability, or a single writer.

bjz_ 10y ago

But then you lose memory safety

WalterBright 10y ago
That's being fixed.
- Ygg2 10y ago
  Wouldn't that cause duplication of interfaces? Rust had that problem when it went down having no-gc and having gc, too.
  - WalterBright 10y ago
    D's strong support for templates makes that a non-issue.
deleted 10y ago
[deleted]

p0nce 10y ago

Since you can: - disable the GC - deregister threads so that they are not stopped by GC - eventually avoid the runtime altogether There really is no realtime system that D can't do. The whole anti-GC thing is a giant strawman that consider all GC stop-the-world, unavoidable, and overarching. Academia decided in favor of GC decades ago, and industry has been following suit for good reasons: mental overhead associated with finding owners to everything.

jjnoakes 10y ago
You speak as if a GC is unconditionally better than alternatives and it is a solved problem but using a GC has issues as well. On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free. Ownership is also important for any non-memory resource (file handles, mutexes, etc). GCs release those "whenever", maybe never, unless you close manually. And even though manual memory management has some small non-deterninistic overhead for heap coalescing (which one can usually work around with pools), most GCs I've worked with add measurable overhead. This equates to more cost per server, more load, more battery life drained, higher response times...
- p0nce 10y ago
  > On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free. I don't think it follows and it's rather the reverse: it what I share has a global owner (ie. the GC), I don't have to lock or copy by definition: once it stops being reachable it will be collected. That's why some lockfree algorithms are enabled by the GC. With ownership you would have to have a unique owner, or reference counts. GC does require write barriers or stop-the-world though so let's say it's a draw :) > Ownership is also important for any non-memory resource (file handles, mutexes, etc). GCs release those "whenever", maybe never, unless you close manually. Yeah, it's a big problem that the GC even attempts poorly to close them. But D has scope guards and RAII builtin so for the 50% of non-memory resources you still have to think about ownership indeed. That's more complicated that the C++ situation. But realtime it does not prevent, you may well find yourself having more time to optimize :)
  - jjnoakes 10y ago
    > if what I share has a global owner (ie. the GC), I don't have to lock or copy by definition Then how you do avoid data races? Two shared references which can mutate your shared data requires either a copy, a lock, immutability, or a single writer.