Agreed, however I think the latter part of the intro is worthwhile to anyone who wants a deeper understanding of Rust.
I've always found that a in depth understanding of what you use pays off in unforeseen ways.
Though I do have another project that exports a C API, and that requires unsafe, though it's literally only for wrapping/unwrapping pointers.
It's a WIP, but mostly feature complete at this point. I'm working on DNSCrypt at the moment.
[ed: just found src/config/test - looks more like a "better bind" than "djbdns in rust"]
My insiration started with yet another Bind exploit, and then grew from there. Unlike djbdns, I want this really to have as little manual operation as possible. After DNSCrypt I'm going to look at implementing a version of Raft on top of DNS updates/notifies, etc, to make server resiliency even better. DNSCrypt is next, mostly so thy I can use it for private comms between DNS nodes.
djb's is amazing, but what I'm looking for is to build something more flexible and more feature rich.
The code is well documented ;)
Operational docs will come, but I haven't really had an opportunity to focus on those yet.
Additionally, if nobody writes unsafe Rust, who's going to maintain the abstractions that the rest of us rely on? :)
Specially for basic data structures like trees, graphs and double linked lists.
These data structures are write once. You write them once, verify them, and use them as much as you want. The doubly linked list is in the stdlib. A tree without parent pointers is possible with zero cost in safe rust. A tree with parent pointers IIRC exists in a crate somewhere. So you will rarely be implementing these, just using these with safe code.
While we use datastructures to teach the "basics" of languages like C and C++, that doesn't mean that they are basic and any language where they are hard is crap. Rust makes them hard so that the rest of your code is easy to write. And since these are write-once, they have a minimal to zero impact on the amount of unsafe code in your codebase.
Keep in mind basically all of Rust's libcollections uses unsafe code for perf and low-level representation reasons. They can all be made safe using the strategies every other safe language uses (and eating the associated downsides).
Also keep in mind Rust's data structures are basically language primitives in a lot of other languages!
So unless proven otherwise by the profiler, no need to make use of unsafe code.
Ada requires explicit use of unsafe code for memory deallocation, but it is not required when using RAII pools.
So unless a custom allocator is required, the standard pools can be used.
In Rust even a basic double linked list requires unsafe.
Then there are those that make use of unsafe to try to express code that cannot be proven by the type system, instead of plain memory corruption issues.
Thankfully the core team is against this trend.
> So unless proven otherwise by the profiler, no need to make use of unsafe code.
> Ada requires explicit use of unsafe code for memory deallocation, but it is not required when using RAII pools.
So, if you want to write hash tables like this without unsafe code, you're in luck: Rust lets you do it!
(As an aside, I keep seeing these fantastical claims about Ada that, when you dig into them, come with the exact same or more restrictive semantics than Rust. Ada is a good language, but it isn't magical, and the region/lifetime/uniqueness systems in Rust actually solve real problems that Ada doesn't have a solution to.)
Ive been looking forward to seeing such a point-by-point comparison of safety features between Rust, Ada, and SPARK. I gave you or someone else involved in Rust the Safe and Secure Ada 2012 book listing those features to help. Just link to it in a reply to me if and when you publish such analyses.
Btw, even if I agree on restrictive semantics, the thing you didnt mention is results where Ada and esp SPARK are immune by default to so many error classes. Rust definitely had it beat on dynamic safety and probably concurrency. However, unsafe programming in SPARK is still quite safer than Rust. :)
Well this just isn't true. You can write a doubly linked list using Rc and Weak pointers and no unsafe code. This is the same as saying you can write a doubly linked list using GC'd pointers.
In particular, removing a node from a doubly-linked list has three steps: repoint prev->next at next, repoint next->prev at prev, deallocate. If you can write this in safe code, it's equally possible to write a procedure that fixes prev->next and deallocates, but leaves next->prev dangling. What do Ada and Modula-3 do to prevent this?
(If you're willing to sacrifice efficiency, you can always use reference-counting or actual GC. Or you can just stuff each node in a dynamically-allocated vector, and have the prev and next pointers be indexes into that vector, instead; you'll have semantically-dangling numbers, but you won't have memory unsafety. Both of these approaches can be done in safe Rust with the normal standard library.)
http://www.spark-2014.org/entries/detail/spark-2014-rational...
There's also formal verification work on linked lists. If any have simple VC's, they could be encoded in containers like above as well. Tools exist to do similar stuff for C, too.