Hacker News Reader

Comment by philippta | Hacker News Reader

Just because a language doesn’t have a garbage collector doesn’t mean you don’t create any garbage to collect.

Not sure I understand what you mean by this. Rust doesn't create "garbage" in the technical sense. It has RAII. It's a different thing.

Parsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.

I 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".

At 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.

It'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.

For 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.

Nobody 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.

The article honestly doesn't make any sense. Even the title is wrong.

This 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.

> 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++?

It 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.

(of course Java's pointers-everywhere approach has downsides and is generally slower, but there are scenarios where this works to your advantage)

So a theoretical GC language can hypothetically be faster than Rust or C++.

Which language? Does one exist?

It'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.

You can avoid this with custom allocator in C++ for example, you don't have to actually do memory work at synchronous time (aka in destructor)

Thanks, this exactly my point.

Sure, 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?

The 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.

Yes, but that is not garbage.

Reply on news.ycombinator.com