chrislattner
``` $ 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-Chris Lattner (yes, affiliated with Modular :-)
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.
We have a public roadmap and are hard charging about improving the language, check out https://docs.modular.com/mojo/roadmap/ to learn more.
-Chris
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.
It feels like a much better design point overall.
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
Mojo also has a bunch of documentation https://docs.modular.com/mojo/ as well as hundreds of thousands of lines of open source code you can check out: https://github.com/modular/modular
The Mojo community is really great, please consider joining, either our discourse forum: https://forum.modular.com/ or discord https://discord.com/invite/modular chat.
-Chris Lattner
-Chris
-Chris
A relatively accessible example is the `Int` type: https://github.com/modularml/mojo/blob/main/stdlib/src/built...
implemented in terms of the index dialect (that Modular upstreamed to MLIR): https://mlir.llvm.org/docs/Dialects/IndexOps/
-Chris
In my experience, a diverse community of people who want similar but /different/ things is what builds out a thriving community. This is why LLVM is pretty great for example: lots of people have a shared view on what technical excellence means, but they all want different things so you get a well balanced ecosystem, not just "Apple's compiler".
-Chris
It might not be the best thing, but here's the rationale for why we do this: it's basically that Mojo is still early, and being "good" at something requires more than a language - you also need a library ecosystem and committed community around there. We don't think it is time to declare that Mojo is a great solution for GUI development (for example) until these things happen.
In contrast, Modular is pushing hard to build out the AI part of the ecosystem and already has MAX engine and even more things coming, so we're pretty confident that Mojo will be great in the AI domain.
As the community builds out, we can expand positioning where it makes sense. We just don't want to overclaim.
-Chris
-Chris
Speaking as someone who has spent more than 20 years writing compilers (e.g. LLVM, MLIR, etc), my opinion is that autovectorizers are a class of tech that are best applied to get speedups on legacy code bases. If you care about performance a lot, you shouldn't use them IMO - they are unpredictable and have performance cliffs.
-Chris
In between we have something we're cooking that I think will be pretty interesting for GPU kernel authors, but it isn't public yet. :-)
The nice thing about this is that it is one system that scales, instead of a bunch of different/inconsistent tech built by different teams over many years, held together with duct tape. Simple and consistent makes it much easier to do the kinds of research and experimentation that power AI ecosystem.
e.g. these might be interesting:
https://www.modular.com/blog/mojo-llvm-2023 https://www.modular.com/blog/what-is-loop-unrolling-how-you-...
If you still have doubts, you could join the 20,000+ people in discord chatting about Mojo stuff: https://discord.com/invite/modular
-Chris
Braces are strictly worse than whitespace indentation for several reasons. Brace-based languages:
1) Generally have the "dangling else" set of ambiguities. 2) Some (e.g. C) allow but do not require braces which leads to style debates. The ones that require braces are more verbose. 3) Require more punctuation clutter, and consume more vertical whitespace in practice. 4) ... use braces that are completely redundant with indentation in practice!
It's super funny to see people defend curly based languages. Using curlies but not indenting properly is almost always a sign of a bug (e.g. clang has warnings for this sort of thing due to the "goto fail" and other debacles.
That said, as you also know, Python compat is not optional for us, so Mojo doesn't actually a choice at all here. I find it amusing though that your post acknowledges thoughtfulness in language design and thinks this is an example of a lapse of judgement. :P
-Chris
More on GPE if you're curious: https://llvm.org/devmtg/2018-10/slides/Hong-Lattner-SwiftFor...