[quotemstr]

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users?

Me: You're right. Java has come a long way. Let's download...

Rust: No! No no on. Not like that!

---

Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn GC. Rust's safety-plus-malloc niche should be much smaller than it is.

[AlotOfReading]

If you're manually calling malloc in Rust, your code is almost certainly wrong. It might be called as an implementation detail when you create new objects, but std can generally be used as if it were managed automatically.

[quotemstr]

I'm using malloc as synecdoche for all forms of allocation, including Arc<Box<T>> stuff.

[tjoff]

GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance.

For scripting etc. it is perfect though.

[quotemstr]

Even if you're one of those people who believes the highest levels of performance require manual memory management (I'd disagree, but whatever), you'd do well to consider the performance of real-world GC against performance of the Arc/Box/dyn/clone-heavy "high-level Rust" [1] [2] that people and LLMs usually write.

Maybe you can write a carefully-tuned arena-and-slotmap that beats the pants off any GC. GC doesn't have to compete against P99.9 systems programming excellence. It has to compete against an endless soup of Arc, Box, and clone, and it will win this match without breaking a sweat.

[1] https://hamy.xyz/blog/2026-01_high-level-rust

[2] https://llogiq.github.io/2020/05/30/hi.html

[tjoff]

Performance is not even a factor in my argument.

[wild_egg]

Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.

The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.

[tjoff]

I didn't say that. But if you think about memory then GC does more harm than good because you have no help from the language.

A GC is not the only fix for UAF and buffer overruns...

[pjmlp]

Depends very much which programming languages we're talking about.

There are enough managed languages with knobs allowing to do C like coding when required to do so.

[tjoff]

Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.

[wild_egg]

That really, really depends on the language.

[pjmlp]

It is perfectly convenient across D, Modula-2+, Modula-3, C#, Nim, Swift, Oberon, C++/CLI, and plenty others.

[rsyring]

For a lot of programming tasks, HAVING to think about memory is a disservice.

That's part of the reason why Python, go, Ruby, etc. are so popular.

There is no one right answer, it's very dependent on what's being built and where the ROI for the programming effort comes from.

[tjoff]

For some tasks, sure.

But you still have to think about memory in those languages.