411–420 of 460 posts
Earlier quoted context omitted.
I think the poster to whom you're responding means things like Cell and/or RefCell, which allow mutation behind the scenes while still being safe.
Right, but I think their main complaint is that RefCell is implemented using "unsafe" -- hence my point about "unsafe".
Earlier quoted context omitted.
> Naive ARC is AFAIK very expensive as it causes a lot of updates It also means you can't really rely on CoW after fork(). After a while your whole heap will be duplicated in every process because of the RC updates.
Lots of things that people do don't work after `fork()`, though, to the point where `fork()` has become largely irrelevant in new code. For example, threads are not generally compatible. You can also easily run into issues with open files, file locks, etc. Of course, your point might still be relevant in "legacy" environments with poor threading support anyway. I would argue that those are gradually going away, as ev…
Earlier quoted context omitted.
Well, you can use weak pointers appropriately in a safe setting. It's not fun though. Alternately, you can use a layer of indirection, such as throwing all your graph nodes in a big vector and having them use indices to refer to one another. So I would perhaps revise that statement to " easy cyclic data structures, memory safety, memory management without tracing, pick two".
Fair enough. But with the vector approach, now you can have something that looks a lot like a use-after-free error!
Earlier quoted context omitted.
Here's a benchmark that includes an energy comparison: https://thenewstack.io/which-programming-languages-use-the-l... . It's interesting that speed does not directly correlate with energy consumption and the the energy consumption of functional languages was much higher than imperative.
That's more a measure of indirection than of garbage collection.
Earlier quoted context omitted.
> when we push down a "bump" of complexity in one place, seventeen bumps at least as large can crop up elsewhere. I think you've taken the metaphor about a waterbed and design advice a bit too literally. :) When you push complexity down in one area and it pops up in another, there's no guarantee that it's of the same overall magnitude, as it would be in a real waterbed. Sometimes it's larger, and sometimes it's small…
The waterbed theory in fact explicitly states that the amount of complexity is preserved no matter how it is distributed. The Wikipedia definition of it explicitly talks about how the volume of water remains constant due to its incompressibility. If that isn't taken literally, it informs of nothing we don't already suspect. It tells us that for each functional requirement, there is at least one piece of code in the s…
It informs you of nothing you didn't already suspect. I think it's useful to remind people of something that's fairly obvious ans self explanatory if you think about it, but not everyone does, and having an easy and slightly odd metaphor to point to helps the point to get across. The fact that you think it's obvious is actually one of its major benefits. You can immediately start exploring the consequences of it instead of spending time proving it. Honestly, of all the criticisms to level at a metaphor, "too obvious" isn't one I would consider worth bringing up. Obvious metaphors are used to good effect all the time.
Edit to address your prefixed paragraph:
> The waterbed theory in fact explicitly states that the amount of complexity is preserved no matter how it is distributed.
If you read carefully, it says that the minimum level of complexity may not be reduced. Who is to say the minimum level of complexity has already been reached? Or that pushing down a level above the minumum in some area won't cause only the minimum level to rise elsewhere (or vice-versa)?
Earlier quoted context omitted.
ARC is just garbage collection that doesn't always work (circular references).
True! And ARC in Rust suffers from the same problem (note that while ARC in Rust and ARC in Swift are the same thing, the "A" happens to stand for different words in each case).
Earlier quoted context omitted.
A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases. https://thenewstack.io/which-programming-languages-use-the-l...
The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code. Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C). Highly dynamic…
Shouldn't it be relatively simple to implement malloc/free as a wrapper around a garbage collector and compare like with like? Maybe we'd need some more annotations to cover copying, referencing, etc.
For that matter if GC was faster I'm sure we'd have seen this in a number of large C/C++/rust programs already
Earlier quoted context omitted.
> Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff That's a description of tracing GC, not a definition of GC. GC is whatever technology that enables what you've called automatic memory management: a kind of illusion that there is infinite memory, from the programmer's perspective. That might involve some mix of reference counting (Python is probably the biggest…
> GC is whatever technology that enables what you've called automatic memory management: a kind of illusion that there is infinite memory, from the programmer's perspective. That's definitely not what McCarthy meant by it. I understand that's probably a common view nontheless, but I can use sbrk() and the fact my computer has gobs of ram/swap, and I'm not going to call that garbage collection. I don't think this defi…
Earlier quoted context omitted.
That's what smart pointers/ref counting is for
C++ is the flagship language for smart pointers and UAF memory corruption flaws are endemic to it.
Earlier quoted context omitted.
> Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the resources here while you're at it? You are missing the point. The main point behind GC is removing the complexity of writing the software. Writing your own destructors, thinking about when to free your memory or writing lifetime annotations, needing to design your app in…
> mental overhead that is removed by GC and it is replaced by GC when your program behaves unexpectedly because, whoopsie , that's the one time the GC decided to run. Good luck debugging or even reproducing that.
GC usually runs on allocations, so it's quite predictable. The amount of time spent on collection is pretty much as indeterminate as the time spent on malloc/free.