Hacker News Reader

Comment by davidw | Hacker News Reader

> For those who haven’t been following Rust, there are around seven different kinds of pointers: @ (garbage collected heap allocation), ~ (uniquely owned heap allocation), & (borrowed pointer to heap/stack allocation), * (raw C pointer, only useable in unsafe code), and mutable versions of the first three of those (actually, I’m not sure if there’s a mut & pointer, so maybe just six pointers in total).

I am not sure I like the sound of that. I guess having the unsafe stuff available is very useful for certain things, but it all sounds a bit messy, too.

View on HN

We're moving the garbage-collected pointers (@) out into a library, so by default we'll have only a single pointer, ~ (and there's no mutable version of this). We'll still have & and &mut, but those aren't pointers, they're references (it's our own fault for calling them "borrowed pointers" in our documentation).

So depending on how you count, that's either one or three pointer types, which I'm happy with. The "unsafe" pointers exist only for C interop and have no bearing on normal code, so it's inaccurate to count them.

Being able to talk about memory allocation in a safe way is one of the key objectives of Rust. Rust is the only modern language (i.e. not C or C++) I know of that allows one to mix GC'ed and manually allocated memory, and heap and stack allocated memory.

Reasoning about mutability is necessary for safe (and fast!) concurrency.

> Rust is the only modern language (i.e. not C or C++) I know of that allows one to mix [...] heap and stack allocated memory.

Technically I believe (to verify) Go does that as well, but the mix is implicit and the system (not the developer) will decide on its own whether a value should be stack- or heap-allocated.

C# will also allocate value types local variables on the stack (technically all local variables are stack-allocated, but for reference types it obviously stack-allocates a reference to the heap, the end-result is that under the usual understanding of "stack allocation" only value type local variables and parameters are stack-allocated)

JVM HotSpot does this, too, implicitly, by means of EscapeAnalysis.

By "Being able to talk about memory allocation" I meant that the programmer has control over these things.

You can do it in D as well in much the same way as in C#. (You can get manual memory management with heap allocation as well, but you lose the safety then.)

It's not nearly as bad as it seems. GC is rarely needed and you won't write a lot of *s (I think bindgen will write virtually all of the ones you do need anyway.)

That leaves ~ and & which you don't normally need to think about, you could get pretty far writing ~ for all allocations and & in all fn signatures. You could write a video game like this with the SFML bindings for example.

mut doesn't really complicate things in terms of which pointer you're picking. I've screwed up mut here and there, but I feel like it's its own subject.

Reply on news.ycombinator.com