> Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value.

By this logic no language on earth has automatic memory management. I've spent time troubleshooting a memory leak in JavaScript in the past month, caused by someone keeping a pointer around longer than necessary.

Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. I'm not sure what definition of automatic you're working off of, but if it excludes JavaScript it doesn't seem especially useful.

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually.

Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed because you need to think about which pointer type to use and using gc'd pointer types like Arc has a syntax overhead (like say when a pointer is cloned).

Swift has „weak” references for when you don’t want to bump the reference count. Does that make it manual?

Most GC langs have these features too they're just not in your face. Technically C# has true value types like C++.

Rust makes the distinction between stack and heap references, like C++. Other, more high-level languages don't - there's only one kind of reference, you can't take a reference to a stack object. Maybe you implement that by making all objects heap allocating (Java) or you just say they have to be copied every time (C# struct). That's really where the difference is.

There's a lot of juicy, juicy performance there. The problem is taking references to stack variables is problematic. Tracking heap objects with a GC or a ref counter is really trivial in comparison IMO, at least when you try to combine the systems.

> Most GC langs have these features too they're just not in your face.

That's what I meant by "strong and widely used default". Defaults and syntactic sugar do matter and influence the type of code written.

The assessment on C# does not match language spec at all.

Not only instance methods on C# structs are implicitly byref, you can easily pass structs by reference via ref, out and in keywords. On top of that, ref structs can hold `byref` pointers aka 'ref' keyword which can point to arbitrary memory, or have references to other structs/variables/anything.

There is also regular C syntax with &T and T* for unmanaged references/pointers. On top of that, .NET's compiler has gotten very good at struct optimizations and pretty much ensures they stay in registers all the time unless address-taken, including SIMD registers for Vector<T> and Vector128/256/512<T> even their "deconstructed" form when specified width is not supported so they get handled as e.g. 256x2. There was a big jump in codegen quality in .NET 8 which can now sometimes trade blows with GCC and Clang around struct optimizations.

All these features are first-class and are heavily used by all kinds of performance-sensitive code.

Also, structs can implement interfaces and can be generic arguments that satisfy interface constraints, which works exactly like generics with trait bounds in Rust - you get a generic instantiation aka monomorphized function body, making the abstraction zero-cost.

Wow, I was not aware of the monomorphization of structs in C#. That's very interesting, I wonder how you're able to mix generic structs and generic classes seamlessly.

> you can easily pass structs by reference via ref, out and in keywords. On top of that, ref structs can hold `byref` pointers aka 'ref' keyword which can point to arbitrary memory

These are not features I've encountered. I wonder how you solve dangling references when those references could point to automatic stack variables.

> Wow, I was not aware of the monomorphization of structs in C#. That's very interesting, I wonder how you're able to mix generic structs and generic classes seamlessly.

The handling is transparent, in a way. As implemented by CoreCLR, class-type generic arguments have shared representation named __Canon. This means that, for example, a `Dictionary<int, string>` has a generic instantiation indicated as `Dictionary<int, __Canon>` where __Canon is an implicit generic type argument passed alongside relevant calls. Statics referencing that do get exact address, and there is quite a bit of complexity regarding runtime handling of this as far as virtual calls and other edge cases are involved, but as a programmer you are never exposed to that directly. It's an implementation detail, and even un-monomorphized cases work rather fast in most situations, like standard data containers.

> These are not features I've encountered. I wonder how you solve dangling references when those references could point to automatic stack variables.

Not sure what you mean by automatic stack variables, but the idea behind byref pointers\managed references\'ref's is that they are not allowed to be boxed or otherwise placed on the heap.

This lifetime restriction enables key scenarios:

- byrefs can point to object interiors without hindering GC throughput

- byrefs can point to stack memory, allowing `var span = (stackalloc byte[32]);` and more

- byrefs can point to any unmanaged memory without requiring excessive range checks by GC

This way you can use `ref T` to represent any memory location and `Span<T>` to represent any contiguous memory range up to 2B elements, without having to carry around bespoke overloads and types that disambiguate between containers and memory sources, much like you would usually see in most other GC-based languages.

There is also additional lifetime analysis in Roslyn to prevent you from returning 'scoped' 'ref's to an outer scope, like having a ref point to an integer in the current method body and returning it to the caller - this will not compile, unless you override it with unsafe [UnscopedRef] which you should never do unless you are absolutely certain (every time I used it and was absolutely certain, the compiler was right and I was not :D). This also works "through" ref structs and other tricky scenarios, which means you can return a ref that points to a middle of heap-allocated array - the scope of object exceeds current method, and byref can keep the array rooted even if no other reference to it exists. The main restriction is byrefs can mostly flow "downward" as not to escape the scope they originate from, but that's a given in most scenarios in Rust just as much.

There is a basic walkthrough about byrefs here: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

C# is good at systems programming - it also has portable SIMD and intrinsics, static linking, native compilation and zero-cost FFI. Engineers getting surprised by this fact rather than upset is the happier but unfortunately less frequent outcome :)

> I wonder how you solve dangling references when those references could point to automatic stack variables.

By restricting them, to, essentially, disallow storing `ref`s on the heap.

I've found it's kinda helpful to think of Rust/modern C++ style management as semi-automatic memory management. You control when things are allocated and freed, but you don't bother with the minutia of it unless you're writing a low-level container type.

This is contrast to something like C/Zig, where things are fully manual, or something like Python or Javascript where things are fully handled for you.

Pointers in JavaScript? I’m far from a JS expert, but didn’t think the language had pointers. Could you explain what you mean here?

I'm not aware of any mainstream language that doesn't have pointers, the question is whether they expose pointers as a first-class language construct (i.e. you can choose to not dereference them or to do pointer arithmetic) or use them as an implementation detail.

In JavaScript's case it's an implementation detail, but one that is extremely relevant when maintaining something in production.

Correction about JavaScript: All non-primitive data types are pass by reference. So not just implementation detail as no valid js interpreter will pass those by value.

It's not up to the implementation to decide whether to pass by reference or not, but it is up to the implementation whether to use pointers under the hood to model passing by reference. Since there's no pointer arithmetic, other models could theoretically be used to accomplish the same semantics [0], it just happens to be that pointers are by far the most logical choice.

[0] As a silly example: a JavaScript implementation could technically store object references as a URL of an API that allows interacting with the object, as long as this is transparent to the user and the program behaves the same as a pointer implementation (minus non-functional characteristics like performance).

Makes sense, thanks!

Most variables on JavaScript are (essentially) pointers. A common mistake people make in the language is keeping references to objects in a global map, which prevents them from being garbage collected (often a bad caching implementation).

You can use things like WeakMap or WeakRef as one solution, but there are usually better options

> you can write entire Rust programs without once calling `free` manually.

If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement.

It feels like people are equating "manual memory management" with "onerous memory management." People are usually going to want to do the boring thing with memory, and everything in the standard library by default does the boring thing with memory. If you write boring structs and enums, you'll derive boring memory management. But it's not part of the language, it's part of the library.

> If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement.

I meant `free` because I'm contrasting with C.

> It feels like people are equating "manual memory management" with "onerous memory management."

Manual memory management is onerous, but I'm very specifically talking about manual. If I can write a whole program without thinking about memory, the language does not require manual memory management. It may support it, but it doesn't require it the way that C or Zig do. You do not "have to explicitly manage memory" as OP claimed.

You can't call Drop::drop for type T at all. Try it if you don't believe me.

It would be unacceptable to allow this because Drop::drop says it only takes a mutable reference &mut T (and indeed it does) but now the thing is destroyed, so, that wasn't just a mutable reference at all!

You can call core::mem::drop<T> but well, look at it, here's the code:

pub fn drop<T>(_x: T) {}

Like, duh, we give it a T and then it doesn't give anything, the T is gone. That's not magic library code by the way, if we make our own:

pub fn vanish<T>(_x: T) {}

Now we can call our vanish function and the same happens.

So yeah, automatic memory management.

To be fair I don't think this is enough to say automatic memory management, otherwise C++ would be automatic memory management too (and maybe it is, just poorly implemented?)

Yes, C++ has automatic memory management.

As with the rest of the language, the automatic memory mangement requires that your program has no mistakes - which requires inhuman amounts of care during implementation and testing. So, that's obviously a spectacularly bad idea, but it's still automatic memory management.

Yeah, the correct statement would be ‘Rust is the first mainstream language without GC, that guarantees memory safety’ (with obviously the caveat of unsafe blocks, but than you can also sun.misc.unsafe yourself into segfault in java).