Go nulls and SQL

No you can't, but Go will happily de-reference the pointer without a null check, and your "string" will blow up in production: https://go.dev/play/p/7EVa7q6VgIM

The distinction between pointer and optional is not vast. The distinction between pointer and not optional is.

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

You can call a value method on a nil pointer and it panics, though, which I think was a mistake.

>The distinction between pointer and optional is not as vast as people make it out to be.

The billion dollar mistake is overblown?

I don't think that's quite true. It's sort of the same in how it's used, but the main difference is that T? (or T | null) is a union, and Optional/Maybe/Option is a sum type. Out of all the implementations I've seen, T? can't be nested - you can't have T??, whereas it's quite possible to have a Option<Option<T>> (and it's sometimes useful).

Roughly, yes. But that's the point: an Optional type along with static typing preventing misuse can prevent these sorts of errors entirely.

It's semantically similar but not syntactic sugar, since it is not translated to Optional or wrapper types, so it also doesn't incur the overhead of Optional.

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.

Only if you want it to.

    #[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 },
        }
    }

You're explicitly choosing to panic if it is None. Would never pass a code review unless you can in very clear terms tell why it will never now or in the future be none.

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

The comment that you respondend to:

> > 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).

The quote is talking about plain pointers being dangerous.

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.

FFI is unsafe, by definition.

All it takes is a specially formatted comment

    /*
    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.

You can't. But a runtime panic also very easily causes an outage. At least it's not as subtle.

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.

You can't. But you can absolutely have a `nil` that will unavoiad runtime panics if you don't check it. And further, you only can't do this because go defines by fiat that the zero-value of a type must be legal. Of course, this is wildly inconvenient and annoying for many types, including those that come bundled in the standard library.

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.

I think we may have been talking past each other - I did mean SQL's CHECK() et al with "value checks". I agree with everything you've said.