Why Rust? [pdf]

For example, `Option<i32>` is probably (the compiler gets to choose) going to be represented as two four-byte values: the discriminant, which distinguishes the `Some` and `None` cases, and then a space for the value `v`, for when the discriminant says we have `Some(v)`. Since zero is a perfectly fine value for an `i32`, we have to store the discriminant separately.

But note that this is just a flat eight-byte value. There's no heap allocation involved. It's just as if you'd written in C:

    struct O { enum { Some, None } discriminant; int32_t value };

Say you have a function, `f : (bool, T) -> Option<T>`.

    function f<T>(cond : bool, value : T) : Option<T> {
      if cond {
        return value                 // equivalent: Some(value)
      } else {
        return null                  // equivalent: None
      }
    }

    let x = f(false, f(false, 1))    // equivalent: None
    let y = f(true, f(false, 1))     // equivalent: Some(None)

The C++ case where a distinction between `foo = null` and `*foo = null` exists is indeed much closer to a an option type. You're right to point it out.

Developers like to say they want choice when it comes to formatting, but take it away and you're left with resigned programmers who are very productive at reading code.

^^ Perhaps not the right outlet for this, but maybe you can point me to where this discussion is taking place.

I built rustfmt with nightly Rust and it dynamically links all kinds of shared objects from the Rust install. This doesn't happen for a simple hello world so there must be something different in rustfmt's build.

That doesn't mean that everything that's available on nightly will be available in stable in seven weeks, of course. Everything lands as stable and then is made stable at some point in the future, at least one full cycle after it's landed. There's lots of pre-Rust 1.0 stuff that's still nightly-only.

  >  What are the technical reasons you can't guarantee an absence of leaks?

As for how safe Rust can leak:

    let x = Box::new(5);
    std::mem::forget(x);

    use std::cell::RefCell;
    use std::rc::Rc;

    fn forget<T>(val: T) {
        struct Foo<T>(T, RefCell<Option<Rc<Foo<T>>>>);
        let x = Rc::new(Foo(val, RefCell::new(None)));
        *x.1.borrow_mut() = Some(x.clone());
    }

It is technically possible to guarantee the absence of leaks by introducing a `?Leak` trait to the language. There was a point in time when many wanted Rust to go that way, but it was ultimately decided against (it complicates other things).

this is probably a silly question because the content, though it might always be in RAM, will be branched to an order-of-magnitude less than it'll be used (once it's been loaded to cache)...but still, there should be an observable temporal-boundary to the context stored in cache and branch predictor in a procedural language, that would be manifest as an abstraction-boundary in a more parallelized environment

Like a fertilizer that stimulates growth while young but a crutch which stunts advancement in old age.

You might want to check that the property "the number of black nodes from the root to any leaf is the same" is always valid. With unit testing, you'd implement the insertion and deletion functions, and write a unit test where you give them a few trees and make sure that the insertion and deletion functions don't break that property, probably by looping over every leaf and comparing the black-height. If this passes, you know that your functions are probably correct and at least not obviously broken, but you don't know that there isn't some edge case you haven't thought of.

With a language that supports proofs, you'd tell the compiler about the concept of black-height, and the type of a red-black tree would include the black-height. Therefore, in order to construct a valid red-black tree, you have to have constant black-height. Just as much as you couldn't construct a red node with a red child, you can't construct a node with two children of varying black-height. When you say that your insertion function returns a red-black tree, as part of type-checking, the compiler makes sure that these properties hold -- because in turn, every helper function you call, every constructor, etc. also requires these properties to hold so that they can return an object of type red-black tree.

The downside is that it's much more involved than a few randomly-selected test cases to convince the compiler that you're upholding the red-black tree rules in every single case. This textbook has an example of doing this in the Coq proof assistant (search for the section labeled "Dependently Typed Red-Black Trees"):

http://adam.chlipala.net/cpdt/html/MoreDep.html

In any case the distinction between "multiple processes" and "multiple threads" here is fairly minimal, at least on Linux or OS X. As far as the kernel is concerned, they're the same object (Linux calls them threads; Mach calls them tasks). It's just that sometimes, groups of these things share pointers to things like memory map or file descriptor table, and sometimes they have their own pointers. There isn't a whole lot of difference, either at the language level or the kernel level, between running multiple processes from the same executable image that map a shared heap versus just running multiple threads.

I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.

It is possible. For example, you could just remove threads and synchronization primitives. :)

But it's not easy -- IMO, compared to data races it's much harder to eliminate deadlocks statically without restricting expressiveness too much. It's even harder if you count I/O related deadlocks as deadlocks (e.g. deadlocking reads on Unix pipes).

The real goal is to find a strategy that works well enough, often enough. Dynamic GC gives up perfect collection (aiming to be merely good enough). Rust's data race guarantees prevent safely expressing some subset of correct programs.

Whether deadlock prevention can be done nicely enough for general case usage is an open question.

"Check out our awesome new car! It makes driving 'easy and safe'!"

"Does it prevent crashes?"

"No, that's impossible! But here, look at our onboard computer that prevents many types of driving errors."

I like Rust. I want it to succeed. But I think the rhetoric gets ahead of the language sometimes, and not prioritizing higher level concurrency tools because you have the borrow checker is a mistake.

I'm looking at the standard library and I see only threads and channels. Is there anything higher level? Parallel map, reduce, etc., something like OpenMP?