4 ms·

Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together

by necubi 12y ago

Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together nicely. Rust has (and may again) offer something like optional GC, but it will operate at the value level rather than the program level and thus doesn't really solve the library problem. Programming languages are designed in a huge, multi-dimensional space. Should the language be static or dynamically typed (or optionally typed)? Interpreted or compiled (or JIT'd)? Manually memory managed or gc'd? Powerful or simple type system? Large (C++) or small (scheme)? Batteries included? Hosted on a runtime? Each of those questions (and of the dozens more than go into designing a language) involves tradeoffs. Manual memory management makes a language suitable for domains like kernels and games, but inevitably requires the user be aware of where and how memory is being allocated and deallocated. Small dynamically typed programs tend to be (in my experience) faster and simpler to write, but static typing makes maintain large codebases much easier. I strongly believe there will never be a language that is the best available for all domains. Currently I find that I need three languages to cover my bases: * A dynamic, batteries-included scripting language (Ruby) * A static, fast, gc'd language (Scala) * A static, fast, non-gc'd language (C++) I'm hoping that Rust will collapse the last two, but there are still a lot of tradeoffs.

coldtea 12y ago
>Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together nicely. Rust has (and may again) offer something like optional GC, but it will operate at the value level rather than the program level and thus doesn't really solve the library problem. Well, you could make 2 compilers for languages with the same syntax, and 2 sets of libraries (GC and no-GC) with mostly the same APIs, divergent only in whether they have GC or not. For low level stuff you use "GCLESSLANG" (as a better C) and for the other stuff you use "GCLANG". Otherwise the 99% of the syntax is the same, and the 2 langs are designed to easily call into one another. They could share most of the parser and compiler too. This would basically give you the feel that you use one and the same language, switching between GC and no-GC version. It's a money and resources thing, not some "cannot make this work" thing.
- geofft 12y ago
  I think Rust attempted to do a much more conservative version of this (same language, different sigils on pointers depending on whether pointers were refcounted or ownership-transferred) and determined that it didn't work in practice. Libraries have to use one scheme or the other, nobody made APIs that exposed both schemes, and calling between them was too much of a hurdle. So in practice people ended up settling on a single pointer type, which was -- somewhat surprisingly for the language designers -- the non-refcounted one. And the language got rid of syntax for the refcounted one, and everything became more usable. I could believe that with more money and resources everything would have been rosy, but my understanding of the facts doesn't particularly support this.

by necubi 12y ago

coldtea 12y ago

>Optional gc is not something I've seen work in practice. Apple abandoned their attempt because of the difficulty getting gc'd and non-gc'd code to play together nicely. Rust has (and may again) offer something like optional GC, but it will operate at the value level rather than the program level and thus doesn't really solve the library problem. Well, you could make 2 compilers for languages with the same syntax, and 2 sets of libraries (GC and no-GC) with mostly the same APIs, divergent only in whether they have GC or not. For low level stuff you use "GCLESSLANG" (as a better C) and for the other stuff you use "GCLANG". Otherwise the 99% of the syntax is the same, and the 2 langs are designed to easily call into one another. They could share most of the parser and compiler too. This would basically give you the feel that you use one and the same language, switching between GC and no-GC version. It's a money and resources thing, not some "cannot make this work" thing.

geofft 12y ago
I think Rust attempted to do a much more conservative version of this (same language, different sigils on pointers depending on whether pointers were refcounted or ownership-transferred) and determined that it didn't work in practice. Libraries have to use one scheme or the other, nobody made APIs that exposed both schemes, and calling between them was too much of a hurdle. So in practice people ended up settling on a single pointer type, which was -- somewhat surprisingly for the language designers -- the non-refcounted one. And the language got rid of syntax for the refcounted one, and everything became more usable. I could believe that with more money and resources everything would have been rosy, but my understanding of the facts doesn't particularly support this.