SoylentNews is people
SoylentNews
from the Obfuscated-Rust-Competition-doesn't-sound-right dept.
In spite of my status and obvious bias as co-creator of D, I'll do my best to answer candidly; I follow Go and Rust, and I also definitely know where D's dirty laundry is. I'd encourage people with similar positions in the Rust and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be replaced alongside C, or be one of the candidates that's supposed to replace C, the C++ language is a key part of the equation. It's the closest language to C and the obvious step up from it. Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement.
Each language has a number of fundamental advantages (I call them "10x advantages" because they are qualitatively in a different league compared to at least certain baselines) and a number of challenges. The future of these languages, and their success in supplanting C, depends on how they can use their 10x advantages strategically, and how they overcome their challenges.
[Another way to look at this is to ask "What is wrong with C?" and then assess how well these languages solve those problems. -Ed.]
(Score: 0) by Anonymous Coward on Friday November 13 2015, @05:05PM
Parent said:
"It [GC] can also lead to situations where resources are locked and waiting for the GC. Like if you are done with a file but that file will remain locked until the GC finds it and runs any deconstructor/dispose methods."
-AND-
"GC doesn't exactly prevent memory leaks though. Your program can keep pushing junk onto an array/list until it exhausts available memory."
My Reply:
GC absolutely prevents memory leaks. "Memory Leak" means "unreachable data", as in, an object is no longer in any scope, so your program cannot ever access it from that moment onward. That is *it*.
"Memory leak" does not mean:
1) General memory issues due to logic errors
2) Insufficient RAM to hold your program or data
3) Automatic management of non-memory resources is not handled in a timely enough fashion
It is true that Java conflated GC with automatic management of non-memory resources (i.e., it encouraged programmers to leave files open for who knows how long and just push responsibility for closing them onto the GC) by way of its "finalize()" method, and that was a mistake. That, properly, is always the programmer's responsibility.
GC takes care of memory leaks, and that is all it does.
(Score: 2) by tibman on Friday November 13 2015, @07:05PM
If a program continues to consume more and more memory while running then it is often said to have a memory leak. A logic error and failure to free are both bugs that result in a program consuming all available memory in a system. You are right though that my use of the term is the laymans use. That is a lame excuse in my opinion. But i'm fine with excluding run-away memory use from GC duties for the sake of argument (and exactness).
#3 was not in reference to memory leaks. It was in reference to the GC calling dispose/desconstruct on objects before freeing the memory. Which is a duty of the GC. A non-memory resource is just another instance of a class, nothing special. The GC can't know when to call dispose and when not to. Manually freeing memory use to always be the programmer's responsibility but we invented a whole new term to deal with that failure, memory leak. I'd prefer it if "non-memory resource (that is still using memory) leak" didn't become a thing.
SN won't survive on lurkers alone. Write comments.