The whole idea of optional is to make not optional possible.

The billion dollar mistake is overblown?

I actually like the language support more, as it flows a lot better than the (flat)map chain you get in monadic style. Similar to async/await v.s. Future.

    #[derive(Default)]
    struct Foo {
        …
    }

    struct Bar {
        …
    }

    fn do_something(foo: Foo) -> Bar {
        # do something with Foo and return a Bar
        …
    }

    fn main() {
        let opt_foo: Option<Foo> = None;

        // panics
        let foo: Foo = opt_foo.unwrap();

        // panics, but with an error message of your choosing
        let foo: Foo = opt_foo.expect("foo was supposed to be there");

        // converts the Option (Some or None) to a Result (Ok or Err,
        // where Err can contain an error type or message and then passed
        // around or returned or whatever)
        let foo: Result<Foo> = opt_foo.ok_or("foo was supposed to be there");

        // replaces it with a value of your choosing if it's not there
        let foo: Foo = opt_foo.unwrap_or(Foo { … });

        // replaces it with the default value the type defines
        let foo: Foo = opt_foo.unwrap_or_default();

        // keeps it as `None`, or if it's actually something then
        // replaces the internal contents with the result of the
        // function call
        let bar: Option<Bar> = opt_foo.map(do_something);

        // does arbitrary logic in the match arm if foo is there
        match opt_foo {
            Some(foo) => { do something with foo },
            None      => { do something else },
        }
    }

The point is that you can't use the inner value without choosing a course of action if it happens to be none.

> > Sane languages have pointers which either can't be null or require you to check explicitly.

You cannot try to dereference a nullable pointer in safe Rust. It has got nothing to do with Optional (Some/None).

And in turn, the claim above was that some languages have plain pointers that aren't dangerous.

Yes, you can put a pointer into an Option that can fail, but that's a different issue. The point is that "can fail" is not built directly into the pointer type, and you can use pointers that don't have that risk.

And to be clear, that claim is not directly addressing the issue of SQL null. It's a baseline discussion of what pointers actually imply by nature of being pointers. We can then better build upon that knowledge after we separate "refers to a data location" and "might not have contents" into separate attributes.

    /*
    int g() {
     volatile int x;
     return x;
    }
    */
    import "C"

    import "fmt"

    func main() {
     fmt.Printf("%d\n", C.g())
    }

Which is fair and true, but you're chasing down a pointless detail. The point isn't that go is memory unsafe. It's not. The point is that Go's type-system is not powerful enough to express various types of type-safety, and as such it's an error-prone language where you can expect null pointer exceptions frequently.

Still. Rust is infinitely better in this regard. Go feels like a crude hammer, especially regarding the default interaction between deserialization and missing struct members.

There are other, very convincingly better options to this that many in this thread have been trying to teach you about in the expectation that your responses have been in good faith.