Hacker News new | ask | show | jobs
by dbaupp 3919 days ago
As you say, Rust is aimed at being a C++ replacement mainly for systems programming, and having a garbage collector is a hinderance there. Sure people will use it for not-strictly-systems-programming things, but that's on their head: they evaluate the trade-offs (e.g. if they can do without a GC) and choose Rust. Compromising the core goal (memory safety without garbage collection) by including a pervasive GC just because some people might make a slightly silly choice and use Rust where some other tools is better is just wrong. It would make Rust inappropriate for the places where there is essentially no other choice like it, putting in into a class with many other alternatives (e.g. Haskell, OCaml, D etc.).

In any case, on one hand you complain about slow, bloated software, and on the other about Rust not having a GC. The unpredictability of a GC being a major component of bloat in a lot of software. Don't get me wrong: it is possible to write sleek software in a managed languages with GCs, but for many tasks this generally requires fighting against the GC, with things like object pools and buffers (basically reimplementing the standard techniques from non-GC'd languages), and, of course, it is definitely possible to write bloated software without one.

Rust is designed to make it easier to write code without a GC, by adopting many of the advantages that garbage collectors/managed languages bring to table (and more, e.g. static protection against iterator invalidation). There's been a lot of people from Ruby, Python, JavaScript (etc.) backgrounds adding lower-level/more-control programming to their toolbox via Rust, something that was too daunting previously. This means that they can write software (or at least, sensitive parts of their code) that doesn't suffer from the overhead/bloat of the managed languages.

Lastly, Rust's memory management is nothing like "manual memory management" in C (or historical C++), I mean, it compiles down to be essentially the same thing at runtime, but what the programmer writes is very different. The combination of lifetimes, destructors and generics mean that it is difficult to do it wrong: memory leaks are rare, and the compiler will tell you about any dangling pointers, etc.