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
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.
Mojo doesn't have C++-like exceptions, but does support throwing. The codegen approach is basically like go's (where you return a bool + error conceptually) but with the python style syntax to make it way more ergonomic than Go.
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.
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.
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.
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.
Thank you for all the great interest in the podcast and in Mojo. If you're interested in learning more, Mojo has a FAQ that covers many topics (including "why not make Julia better" :-) here:
https://docs.modular.com/mojo/faq/
Super impressive app and experience, it is incredible that you can get Swift to do this with such interactivity! Rebuilding Swift to be interpreted is a bold move,
If you're interested in compiler nerdery, you should totally check out the source code, you'll see just how much we meant by "Syntactic sugar for MLIR" :-)
``` $ 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]
```