I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe".
Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.
I think `unsafe` is important to talk about. It's the escape hatch that lets you subvert the type system and do things that the compiler cannot statically reason about. The ability to implement Arc in pure Rust code is very important. But I do agree that it could have been presented perhaps in a different way.
Agreed. My experiments with rust have been uphill because I've been fighting with lifetimes, ownership and borrowing.
For the most part I failed to see that I -needed- unsafe code in some situations. Instead I was trying (failing) to annotate my code to ridiculous levels with lifetimes. It was really frustrating.
I don't think the current docs do a great job of putting unsafe in a suitable perspective. It's somewhat downplayed IMO.
Still, I've learned now and it's been pretty pleasant after that.
FWIW I've been doing c++ for maybe 18 years, writing device drivers, game engines, compiler development. I thought rust was made for me but it's been tough, much more so than any other language except maybe SML!
> Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.
Right, this is my point. I should find a way to make it a bit more clear.
I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. After all, there's a reason you want that low-level control in the first place, right? The ability to escape things when you have to relaxes people.
> I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best.
Well, the best way to combat that would be demonstrate that cool things can be done safely in Rust, but that probably requires a lot more than fits in your introduction.
I think you could allay that fear by addressing it directly, rather than saying that Rust's secret sauce is unsafety.
Hm. I thought that talking about building ARC and discussing its implementation was something cool that directly addresses it. What would you like to see?
I think talking about how ARC is implemented in Rust is cool. I would just pitch it differently.
I think what I don't like about your current description is that it makes it seem like unsafety is what allows you to _have_ Arc in the language. Instead, unsafe blocks are what allow you to _implement_ Arc inside the language.
I'd start the footnote this way:
---------------
A footnote: Implementing Arc
So, the Rust language doesn't let us use shared mutable state in dangerous ways, but what happens if we really need to get down and dirty? For example, what if we wanted to _implement_ `Arc` ourselves?
In fact, `Arc` and `RWArc` are both implemented in Rust. Inside their implementations, they use locks, low-level memory operations, and everything else you might see in a C++ program. However, anytime we use these features, we have to wrap them in an `unsafe` block.
...
---------------
I hope that conveys the different emphasis that I'm talking about.
I think that's a necessary approach. The first time I encountered Rust, in a treatment that covered unique and managed but not unsafe/raw pointers, my impression was: ‘You promised GC was optional, but I can't even write a DAG’.
Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.