4 ms·

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that regard. I have this burning thought in the back of my head that there just has to be a simpler way to offer it than Rust does it too.

ori_b 10y ago
Yes. I'm currently trying to think of a good way to add it to Myrddin, which currently makes it more or less manual. Doing it in a simple way is a tough problem. The simplest solution is to add the moral equivalent of 'null' -- objects that transition to an idempotently destructable state, which solves a lot of complexity with the data flow and analysis (yay!) at the cost of some safety (boo), and nulls (louder boo).
- jesserayadkins2 10y ago
  My language (Lily) handles the problem by trying to avoid the gc where it can. Lily is statically-typed, built-in classes can't be inherited from, and there's no C-like casting. With those rules in mind, most objects can't become cyclical. It's impossible for a list of strings to loop back onto itself, for example. It helps that the value classes backing enums (like Option and Either) are immutable, which I so far suspect prevents a cycle. That at least allows you to group classes into three groups: These never cycle (Integer) These may cycle (List) These always cycle (Dynamic, linked lists?)
  - ori_b 10y ago
    One of the goals I have is to keep the required runtime absolutely minimal, as well -- I'm ok with the compiler inserting some user-defined code in the appropriate places to initialize or release values, but I'd like to avoid growing the required code in https://github.com/oridb/mc/tree/master/rt https://github.com/oridb/mc/tree/master/rt unless it's absolutely necessary. And yes, that ~60 lines per platform is really all that's needed. (And actually, I should be able to merge more of it for SysV platforms.) So, I've thought about a GC, but I'd really prefer not to have it.
  - girvo 10y ago
    Can I just say that Lily is amazingly neat, and is exactly the language I was working on myself! Seems we have a shared delusion ;)
duaneb 10y ago
Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only way it really manages this is by tying references into what amounts to a proof assistant. Every simpler method of which I can think either sacrifices capability (e.g. no references at all; only raii + copy on write) or it becomes a GC with all its wonderful trade offs. GC isn't terrible, though. Azul has struck an amazing balance between latency and eagerness—even if you can't afford it the technology does exist. If you don't have latency, memory restrictions, or embedding requirements, rust may be overkill.
- the_duke 10y ago
  I think you meant -> 'extreymely difficult to get INcorrect in the way rust does'
  - Ygg2 10y ago
    Unless this is a joke, its meaning is correct, i.e. "proven correct like Rust".
    - StavrosK 10y ago
      I think he misunderstood the comment to mean "it's hard to get memory allocation wrong when writing a Rust program".
- vardump 10y ago
  > If you don't have latency, memory restrictions, or embedding requirements Add power consumption to that list.
- quotemstr 10y ago
  > Memory management is difficult, extremely difficult, to get correct in the way rust does Memory management isn't hard --- you just need to pay attention to detail and not say "YOLO, let's abort on OOM" like the Rust stdlib does. Rust is an unacceptable language for anyone who cares about robustly responding to heap exhaustion.
yamadapc 10y ago
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.

ori_b 10y ago

Yes. I'm currently trying to think of a good way to add it to Myrddin, which currently makes it more or less manual. Doing it in a simple way is a tough problem. The simplest solution is to add the moral equivalent of 'null' -- objects that transition to an idempotently destructable state, which solves a lot of complexity with the data flow and analysis (yay!) at the cost of some safety (boo), and nulls (louder boo).

jesserayadkins2 10y ago
My language (Lily) handles the problem by trying to avoid the gc where it can. Lily is statically-typed, built-in classes can't be inherited from, and there's no C-like casting. With those rules in mind, most objects can't become cyclical. It's impossible for a list of strings to loop back onto itself, for example. It helps that the value classes backing enums (like Option and Either) are immutable, which I so far suspect prevents a cycle. That at least allows you to group classes into three groups: These never cycle (Integer) These may cycle (List) These always cycle (Dynamic, linked lists?)
- ori_b 10y ago
  One of the goals I have is to keep the required runtime absolutely minimal, as well -- I'm ok with the compiler inserting some user-defined code in the appropriate places to initialize or release values, but I'd like to avoid growing the required code in https://github.com/oridb/mc/tree/master/rt https://github.com/oridb/mc/tree/master/rt unless it's absolutely necessary. And yes, that ~60 lines per platform is really all that's needed. (And actually, I should be able to merge more of it for SysV platforms.) So, I've thought about a GC, but I'd really prefer not to have it.
- girvo 10y ago
  Can I just say that Lily is amazingly neat, and is exactly the language I was working on myself! Seems we have a shared delusion ;)

duaneb 10y ago

Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only way it really manages this is by tying references into what amounts to a proof assistant. Every simpler method of which I can think either sacrifices capability (e.g. no references at all; only raii + copy on write) or it becomes a GC with all its wonderful trade offs. GC isn't terrible, though. Azul has struck an amazing balance between latency and eagerness—even if you can't afford it the technology does exist. If you don't have latency, memory restrictions, or embedding requirements, rust may be overkill.

the_duke 10y ago
I think you meant -> 'extreymely difficult to get INcorrect in the way rust does'
- Ygg2 10y ago
  Unless this is a joke, its meaning is correct, i.e. "proven correct like Rust".
  - StavrosK 10y ago
    I think he misunderstood the comment to mean "it's hard to get memory allocation wrong when writing a Rust program".
vardump 10y ago
> If you don't have latency, memory restrictions, or embedding requirements Add power consumption to that list.
quotemstr 10y ago
> Memory management is difficult, extremely difficult, to get correct in the way rust does Memory management isn't hard --- you just need to pay attention to detail and not say "YOLO, let's abort on OOM" like the Rust stdlib does. Rust is an unacceptable language for anyone who cares about robustly responding to heap exhaustion.

yamadapc 10y ago

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.