3 ms·
Parsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.
by philippta 2y ago
Parsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.
- VWWHFSfQ 2y agoI think you're confusing "garbage" with just normal heap allocation. Rust will free that memory automatically when the JSON strings go out of scope. There's no "stop the world" thing that periodically scans and deletes stuff while your program is running like in Go or JavaScript. Because there's nothing to delete. There's no "garbage".
- philippta 2y agoFor one-shot programs like Babel, Prettier, Terser, etc. mentioned in this article, I don‘t see how the lack of a garbage collector is a strong argument for an alternative language.
- whstl 2y agoNobody is making this argument for JS tooling. The article does mentions GC, but that's just demonstrating differences between JS and Rust. The other popular JS-tooling alternative is esbuild, which is built in Golang, which has a GC. If anything, the two most common arguments in favor of Rust for this specific use case are null-pointer safety and speed.
- hot_gril 2y agoThe article honestly doesn't make any sense. Even the title is wrong.
- flohofwoe 2y agoAt least reference-counting is typically considered a form of garbage collection (e.g. using Rc<> or Arc<> in Rust, or std::shared_pointer in C++). Arguably, RAII calling destruction code at the end of a scope could also be considered garbage collection, the garbage is just very short lived ;) I guess 'automatic memory management' is the less controversial term which covers both traditional GC and RAII, the downsides are very similar though.
- VWWHFSfQ 2y agoIt's different because the free() is deterministic, the instruction is encoded into the binary. Completely different than garbage collection where there is a whole runtime that has to periodically go figure out what can be safely deleted and what can't.
- anon-3988 2y agoThis is a strange distinction. So something is garbage because it is not used? In Rust, a Vec is only deallocated at the end of the function, regardless of when it is actually stopped being used. Are those garbage too? At this point, garbage just means whatever does not follow RAII. And RAII is not the best solution either. For throughput reasons, GC languages can be siginificantly faster exactly because it doesn't have to clean those "garbage" at every step.
- VWWHFSfQ 2y ago> GC languages can be siginificantly faster exactly because it doesn't have to clean those "garbage" at every step. Which GC languages are significantly faster than Rust and C++?
- hot_gril 2y agoIt can happen in practice. For example, I see a lot of C++ code with extra string copying that would be hard to avoid. Like if some func takes a const vector<string>& and you have a string in any structure besides a vector, you're gonna copy that string.
- hot_gril 2y ago(of course Java's pointers-everywhere approach has downsides and is generally slower, but there are scenarios where this works to your advantage)
- VWWHFSfQ 2y agoSo a theoretical GC language can hypothetically be faster than Rust or C++. Which language? Does one exist?
- hot_gril 2y agoIt'd be Golang if anything. Java might have too much overhead to be faster than C++ without negligence, but that's not because of the GC.
- om8 2y agoSure, what's the issue? Do you think that there is an algorithm that a) does not do this, b) can't be implemented in rust, but can be implemented in C or other language?
- philippta 2y agoThe issue is that GCed languages get a bad rep, while the amount of allocated and freed objects is the same in GCed and non-GCed languages.
- diarrhea 2y agoYes, but that is not garbage.