chrislattner

This is fixed in Mojo btw, using the latest nightly:

``` $ cat test.mojo from std.utils import Variant

def main(): var x : Variant[Int, Pointer[Int, ImmStaticOrigin]] # set it to int x = 12345 # get a reference to the int (dynamically checked). ref elt_ref = x[Int]

    # Set it to the pointer.
    x = "hello".unsafe_ptr()

    # try to use the old reference to the int.
    print(elt_ref)

 $ mojo build x.mojo
 test.mojo:8:11: error: use of invalidated interior reference 'x["value"]'
     print(elt_ref)
          ^
 test.mojo:5:27: note: origin was invalidated here
     x = "hello".unsafe_ptr()
                           ^
 mojo: error: failed to run the pass manager

```

Indeed, this fall 100%

Thank you for the kind words! Are you saying that AI model innovation stopped at GPT-2 and everyone has performance and gpu utilization figured out?

Are you talking about NVIDIA Hopper or any of the rest of the accelerators people care about these days? :). We're talking about a lot more performance and TCO at stake than traditional CPU compilers.

Sure, I wasn't trying to start a fight either, I was just sharing my experience and opinion on having worked on both. Mojo (and C++) have closures, for example c++ does lambda type inference without a constraint solver.

In my opinion, constraint solving would be a bad design point for Mojo, and I regret Swift using it. I'm not trying to say that constraint solving is bad for all languages and use-cases.

Thanks, we'll update that. We shifted to putting Mojo into Compiler Explorer rather than having our own similar-but-different thing.

Mojo has overloading, generics and a much more advanced type system than Swift (dependent and linear types etc), and compile time in all phases is very important. The Mojo design seems to be working well - it gives expressive power, good error messages etc.

It feels like a much better design point overall.

Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. Mojo does contextual resolution, but it works more similar to how C++ resolves initializer lists etc.

Mojo learns a lot from the mistakes in Swift, including this one. Mojo compiles much faster and doesn't have exponential time type checking! :)

Exceptions in Mojo are just syntax sugar for Result types. You don't have to use them if you don't want, and the overhead is not like C++ exceptions.

Thank you, that's not entirely wrongbut not the full picture. Our initial explanation had two problems actually,

1) we were "ambitiously optimistic" (different way of saying "ego-driven naïveté" perhaps :) ) and 2) the internet misread our long-term ambitions as being short-term goals.

We've learned that the world really really wants a better Python and the general attention spans of clickbait are very short - we've intentionally dialed back to very conservative claims to avoid the perception of us overselling.

We're still just as ambitious though!

-Chris