4 ms·

Very strange to have no GC as a innovative feature for a modern programming language. Personally I think Dlang get it right by making GC as a default and provid

Very strange to have no GC as a innovative feature for a modern programming language. Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. As a comparison, auto industry is moving toward fully automatic transmission especially for the EV but software industry is still undicided and seems cannot even come up with a robust GC mechanism that is on par with no GC in term of performance. With no GC, interpreted programming language e.g. Python will most probably being used well into the future alongside Mojo/C++/Rust because majority of AI/data science/machine learning programmers cannot even bother to touch the underlying codes for the fear of programming complexity of these no GC languages.

ecs78 4y ago
Traditional GC isn’t less complex to program then automatic reference counting. Traditional GC has its place in short running extension languages, but in longer running programs you run the same risk of memory leaks as automatic reference counting since you can still over-retain from a poor ownership model. What goes wrong is slightly different, but with automatic reference counting it is easier for the compiler to find and report these issues. I feel you are conflating this with no automatic memory management which would be a higher barrier. Automatic reference counting greatly simplifies inter-op with low-level code and running on specialized hardware vs Python with interop.
- kaba0 4y ago
  RC is GC, but without cleaning up cyclic references. In general, leaking memory is not a security problem (and with a good debugger it is trivial to fix), so I don’t think it is too important a property. Leaking every cyclic reference is a bit more of a problem, but it has solutions like the occasional tracing phase like with a “traditional”, mark’n’sweep GC, but at that point why not just go with them as they are much more performant?
dist1ll 4y ago
> Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. I vehemently disagree. D's GC is the #1 reason for its fade into obscurity, instead of becoming a viable C++ competitor. Now it's completely overshadowed by Rust's success.
- shrimp_emoji 4y ago
  Same. To me, it seems like a step backwards (towards Java) to Rust's step forward with borrow checking and move semantics.
- teleforce 4y ago
  The truth is we can only speculate whether the main reason D is less popular now due to its GC or D can be more popular now if it never had GC. Most of the D standard libraries are written in no GC thus performance is not an issue there and D with GC is not a sloth either. Based on programming language (PL) popularity evidence, generally for the similar age language for example Python (1991) vs C++ (1985), and Go (2009) vs Rust (2015), the PL with GC are way more popular than those without GC [1]. Regarding Rust vs D popularity, time will tell. When at the same age of D now, circa 2000s Perl was notably more popular than Python but then Perl lose its steam and fade into obscurity. Regarding the sibling's comment on borrow checker, D now can support borrow checker and it's just a feature like its many capable features and Rust actually took it from Cyclone [3]. [1]TIOBE Index for April 2023: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [2]Ownership and Borrowing in D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [3]Cyclone (programming language): https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language)
shrimp_emoji 4y ago
> Very strange to have no GC as a innovative feature for a modern programming language. It's because, first, there was manual memory management, which was error-prone. Then came garbage collection, which was safe but slow. Most recently came borrowing and move semantics, which offers the best of both worlds -- safety and speed -- at the cost of some (arguably justified) cognitive overhead and code flexibility.
- adgjlsfhk1 4y ago
  Garbage collection isn't slow. good GC systems have similar overhead to malloc/free.
- kaba0 4y ago
  GC is first and foremost a code design tool. Not having a GC causes less flexible code, every refactor will likely has to reimagine the memory ownership model at every relevant area. So I absolutely don’t think of the borrow checker as superior to a GC, it’s a different tool with different tradeoffs. It was a good choice for a low-level language like Rust, but not necessarily for a high level language.

ecs78 4y ago

Traditional GC isn’t less complex to program then automatic reference counting. Traditional GC has its place in short running extension languages, but in longer running programs you run the same risk of memory leaks as automatic reference counting since you can still over-retain from a poor ownership model. What goes wrong is slightly different, but with automatic reference counting it is easier for the compiler to find and report these issues. I feel you are conflating this with no automatic memory management which would be a higher barrier. Automatic reference counting greatly simplifies inter-op with low-level code and running on specialized hardware vs Python with interop.

kaba0 4y ago
RC is GC, but without cleaning up cyclic references. In general, leaking memory is not a security problem (and with a good debugger it is trivial to fix), so I don’t think it is too important a property. Leaking every cyclic reference is a bit more of a problem, but it has solutions like the occasional tracing phase like with a “traditional”, mark’n’sweep GC, but at that point why not just go with them as they are much more performant?

dist1ll 4y ago

> Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. I vehemently disagree. D's GC is the #1 reason for its fade into obscurity, instead of becoming a viable C++ competitor. Now it's completely overshadowed by Rust's success.

shrimp_emoji 4y ago
Same. To me, it seems like a step backwards (towards Java) to Rust's step forward with borrow checking and move semantics.
teleforce 4y ago
The truth is we can only speculate whether the main reason D is less popular now due to its GC or D can be more popular now if it never had GC. Most of the D standard libraries are written in no GC thus performance is not an issue there and D with GC is not a sloth either. Based on programming language (PL) popularity evidence, generally for the similar age language for example Python (1991) vs C++ (1985), and Go (2009) vs Rust (2015), the PL with GC are way more popular than those without GC [1]. Regarding Rust vs D popularity, time will tell. When at the same age of D now, circa 2000s Perl was notably more popular than Python but then Perl lose its steam and fade into obscurity. Regarding the sibling's comment on borrow checker, D now can support borrow checker and it's just a feature like its many capable features and Rust actually took it from Cyclone [3]. [1]TIOBE Index for April 2023: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [2]Ownership and Borrowing in D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... [3]Cyclone (programming language): https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language)

shrimp_emoji 4y ago

> Very strange to have no GC as a innovative feature for a modern programming language. It's because, first, there was manual memory management, which was error-prone. Then came garbage collection, which was safe but slow. Most recently came borrowing and move semantics, which offers the best of both worlds -- safety and speed -- at the cost of some (arguably justified) cognitive overhead and code flexibility.

adgjlsfhk1 4y ago
Garbage collection isn't slow. good GC systems have similar overhead to malloc/free.
kaba0 4y ago
GC is first and foremost a code design tool. Not having a GC causes less flexible code, every refactor will likely has to reimagine the memory ownership model at every relevant area. So I absolutely don’t think of the borrow checker as superior to a GC, it’s a different tool with different tradeoffs. It was a good choice for a low-level language like Rust, but not necessarily for a high level language.