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: 3, Interesting) by FatPhil on Friday November 13 2015, @01:42PM
"""
Weak story about D's relationship to garbage collection. GC is a great invention, but the decision to use it for D has instantly alienated a core market - existing C and C++ programmers. For those, the party line has historically been "Don't want GC? No problem! You can use D with RAII or manual management style as well!" Though true, that's next to useless because there's little support in the standard library for alternative memory management styles, which means the putative user would need to start with the language stripped down to the studs and create all the core infrastructure. Also, for those who are okay with using a GC, the quality of its implementation is lackluster. Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits.
"""
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Interesting) by Anonymous Coward on Friday November 13 2015, @02:21PM
I'm a relatively new programmer, so forgive the question. But what the heck is wrong with garbage collection? Don't we want this to prevent memory leaks and other issues?
(Score: 2) by turgid on Friday November 13 2015, @02:50PM
Not in timing-critical code and/or on the bare metal. Having said that, D naturally uses the C ABI and knows about C libraries so there should be no problem using standard C libraries.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday November 13 2015, @03:30PM
But if you're going to use standard C libraries anyway, then why not just use C to begin with?
(Score: 2) by turgid on Friday November 13 2015, @03:35PM
Because perhaps the other language is more powerful and let's you achieve more with fewer lines of code?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1) by Knowledge Troll on Friday November 13 2015, @03:09PM
Garbage collection in the language includes a run-time penalty that is anywhere from not that bad to really bad. There is not any free lunch with a computer and GC performs work that may not strictly be necessary or may not be optimal. Most of the time this is a fine compromise because not that many situations need hyper optimized code where the risk associated with not using GC beats the risk of having it in place. Another problem with garbage collection is it can be unpredictable.
tl;dr: if you know what you are doing and are careful it is not that hard to beat the pants performance wise out of a GC system with manual memory management.
(Score: 2, Insightful) by Anonymous Coward on Friday November 13 2015, @03:12PM
Garbage collection doesn't prevent memory leaks. It prevents unreachable memory, but not all memory leaks are in the from of unreachable memory. And reachable memory doesn't necessary mean that there's an obvious way to access this memory, it just means there is a chain of pointers from the base set to that allocation.
Garbage collection also doesn't prevent dangling pointers. Well, technically it does, but de facto a pointer to a logically dead object is still a dangling pointer, and there's absolutely no guarantee that this object has any valid state, as far as the program's logic is concerned. The object is sort of a "zombie", it's technically alive, but logically dead, and is only around because of a stale reference that shouldn't actually exist in the first place prevents the garbage collector from collecting it. This is also how memory leaks happen in garbage collected languages; while dangling pointers in non-GC languages only do harm if they are dereferenced, in GC languages their mere existence is harmful.
Now what garbage collection does do is prevent dangling pointers from falsely pointing to newly allocated objects. As the object they point to is technically still there, a new object cannot be allocated in the same place. Of course if you dereference a dangling pointer, you've already got an error in your program logic.
And yes, languages like Java do have pointers; they call them references and do the dereferencing implicitly, but for all intents and purposes they are pointers.
(Score: 0) by Anonymous Coward on Friday November 13 2015, @04:46PM
Parent said: "Garbage collection doesn't prevent memory leaks. It prevents unreachable memory, but not all memory leaks are in the from of unreachable memory."
The very definition of a memory leak is "unreachable memory". GC absolutely fixes that issue. You are complaining that GC doesn't fix logic errors in your program, and you are correct about that. It never claimed to do that.
GC does relieve the programmer of a big burden (memory leaks), albeit at a cost. This frees the programmer to think more about those other logic errors you talk about.
(Score: 0) by Anonymous Coward on Friday November 13 2015, @07:32PM
Please do read up on definitions, prior to exposing your ingnorance to the wider world.
(Score: 0) by Anonymous Coward on Saturday November 14 2015, @12:26AM
Alright, jackass, I will do just that. From https://en.m.wikipedia.org/wiki/Memory_leak [wikipedia.org] we get the definition:
Memory Leak
In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations[1] in such a way that memory which is no longer needed is not released.
---
You insist on calling other types of resource leaks "memory leaks".
I reread your post carefully and it appears that one of the code problems you are complaining about is that it can be hard to implement an object cache where you want the garbage collector to be free to collect the object in the cache without regard to the fact that the cache currently holds a reference to it. You are OK with that cached object disappearing and becoming a null reference at some point. Fortunately, Java added the WeakReference type later so you could easily implement the cache behavior I described with little effort on your part.
Frankly, your comments make you sound like a programmer who knows just enough to be dangerous.
(Score: 0) by Anonymous Coward on Saturday November 14 2015, @01:08AM
I noticed I wrote "your post" when making reference to a parent post written by a different (I hope) user. Replace that with "parent post" and the rest still stands.
(Score: 2) by tibman on Friday November 13 2015, @04:13PM
GC is slower than manually freeing. It could cause stutter each time it collects. It 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. Makes real-time difficult (i don't have any experience with that though).
GC doesn't exactly prevent memory leaks though. Your program can keep pushing junk onto an array/list until it exhausts available memory. I've seen that issue on long running systems where they are tracking live stats.
Personally, i really like GC. It solves more problems than it causes, imo. I hate JIT compiled languages though. Programs shouldn't ever have to "warm up" : P
SN won't survive on lurkers alone. Write comments.
(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.