HN user

chrislattner

924 karma
Posts0
Comments69
View on HN
No posts found.

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.

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

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.

It feels like a much better design point overall.

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

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/

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

We totally want to see Mojo go into all these places! It's just that Modular can't fund use of Mojo in (eg) gamedev or embedded development (at least not in the foreseeable future). Open sourcing the implementation is a big part of helping catalyze those developments in the community.

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

You're right that Mojo is a completely general purpose programming language. Community members are already building gui libraries and serving stuff etc.

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

Awesome, we'll be releasing a bunch more, but this is a pretty exciting starting point. The standard library has a lot of the lowest level details, and shapes most of the language - because so much of Mojo is library defined.

-Chris

LLVM has an autovectorizer which is quite good, but such tech is limited because (eg) it can't change memory layout.

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

Modular is enabling all of the above for different audiences. MAX provides an operator-graph level abstraction like PyTorch or JAX have, and we expect a bunch of high level libraries like nn.module to get built out over time by the community. You can also go directly to the GPU with a classical CUDA-like programming model for maximal control.

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.

I think you're being paranoid here :-). I encourage you to download mojo and try it out. This code is all OSS, so go nuts validating it yourself. If you'd like to know how mojo works there is a lot of information on the Modular blog:

https://www.modular.com/blog

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

Hey, thanks for your interest. I think it's interesting that you think I don't care about things like whitespace vs braces? In the Lex interview I was kidding around, but I assure you, I do care.

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

I was responsible for the S4TF effort at Google. In my opinion, it validated that some of the ideas are good (e.g. Graph Program Extraction is the algorithm that torch dynamo uses internally), that an efficient compiled language has benefits etc. However, I also learned that it should not be based on Swift and should not be based on TensorFlow. Other than those two things, everything is great ;-)

More on GPE if you're curious: https://llvm.org/devmtg/2018-10/slides/Hong-Lattner-SwiftFor...