I'll be honest, this is a seriously impressive language by an absolute giant in the field. To oversimplify a bit, it has the safety of Rust, the performance of C, with the syntax of Python.
Couldn’t agree more, but I think something that’s understated is that via MLIR you’re basically getting access to a free hardware optimization abstraction layer! The docs (and some folks who’ve messed around with Mojo more than me) have shown off how easy it is to literally command SIMD, which is usually just something most programmers can only hope their interpreter or compiler happen to do. So sick!
This is great but if it’s built on top of LLVM…and touching hardware to that degree-it’s hardly worth a look for the next 5 years for any GP programmer. People truly don’t grasp just how little being a superset of Python matters-because the vast majority of people are productive in Python due to C / C++ libs. It’ll be a crapshoot waiting for X lib to support Mojo’s way of doing things-the same way Typescript was supposed to be drop in superset of JS; but anybody that actually did web dev knows it was anything but seamless. And all languages have the speed of C by Mojo’s standards 😅 Love these two guys though, awesome interview
Chapters: 00:00:00 - Python as a high-performance parallel programming language? 00:03:05 - The Journey to Building a New Language 00:05:55 - Writing High-Performance Loop Nests and IR 00:08:47 - MLIR and AST Generation 00:11:40 - Choosing Python for AI Development 00:14:23 - Introducing Mojo: A Different Language 00:17:01 - Interoperability with C in Mojo 00:19:50 - Introducing Mojo's Type System 00:22:38 - The Nature of Typing and Conversion 00:25:19 - Language Libraries and Data Types 00:28:16 - Hardware Acceleration and Library Extensibility 00:31:08 - The Power of Mojo and SIMD Vectors 00:33:51 - The Max Engine and Custom Operators 00:36:41 - Building bridges in the AI world 00:39:23 - Mojo programming in Python 00:42:26 - Compile time metaprogramming with Mojo 00:45:06 - Compile-time Python Programming 00:48:03 - Memory management in Mojo 00:50:58 - Lifetime Management in Rust and Mojo 00:53:45 - The Journey of Rust and Mojo 00:56:36 - Creating New Values in a List 00:59:19 - Parallelization and Threading in Mojo 01:02:09 - Parallelization in Mojo Programming Language 01:04:48 - Portable Algorithms and Applications 01:07:36 - GPUs and Multi-dimensional Vectors 01:10:37 - Utilizing Hardware Accelerators and Memory Hierarchy 01:13:25 - Mojo: Talking MLIR and LLVM 01:16:16 - The Growth of Mojo and the Open Source Community 01:19:00 - The Excitement of Open Development and Patent Coverage 01:21:37 - The Community Side of Programming 01:24:12 - Conclusion with Kris Jenkins
Kris, you never disappoint! I've listened to Chris talk about language design before. He has a brilliant approach, meet people where they're at, not where you want them to be. You have to be able to set your own ego aside in order to do that.
Outstanding interview. Chris is a true language engineer. Great interview as it gives a large audience an idea of the architectural drivers and technical challenges that led to mojo. Few people ever get properly exposed to these considerations to appreciate what it takes to do innovative language design and engineering.
Another fantastic episode. What a great guest. Really articulate, and you guys had great energy. Mojo is genuinely very exciting as a language. Zig was exciting too, but I can really see where Mojo fits in, and I think it could be really important in the next 10 or so years.
Holy heck! This completely changed how I see mojo working out. I assumed it was some second-system project that ignored cython, and was making a moonshot fueled by hype. It'-s so incredibly funny that the real motivation is the part of it that no one ever mentions, the MILR backend!
MOJO is my last hope for solving the "computer language disaster". This man has all it needs to get it done (in time). Great Interview (as always). 👍👍👍👍👍
With reference to Rust dealing with immutablity with memcpy... I wish I could remember what talk it was... it might have been Anjana Vakil ❤ ... talking about implementing immutable trees of immutable values without copying in JavaScript... it was such good stuff.
Excellent interview! Chris Lattner is an amazing engineer. Would it be possible to get Bjarne Stroustrup for an interview? Is the man still alive? If so, it would be really interesting to hear the thoughts from the man who created the most influential programming language ever created, just a thought. Thanks for such a wonderful interview.
This was impressive and I had a lot of fun following along and searching through things you all were mentioning throughout the discussion. I have a lot more to learn!
Does Mojo has Halide/TVM like constructs? If not, why not? The main Mojo example uses for loops, but at 1:05:20 Chris mentions high level abstractions to avoid for loops.
Nice interview, I really like your format. For me Nim do the job for now. It would be interesting to have an interview with the creator of the V language (Vlang) Alex Medvedniko :)
@@lojicdotcomwhy would most people care about the compiler being open source? From my understanding they will open source that too, just not now. They probably won’t open source their MAX engine which makes sense as that’s their actual money maker.
Someone needs to document as much as possible in a formal study over the next decade so we can finally empirically understand why some languages get adopted and others don't. There are so many good languages available now it is almost overwhelming.
0:00 - Introduction and questioning Python’s potential as a high-performance language. 0:25 - Introducing Mojo and its creator, Chris Lattner. 0:43 - Chris Lattner’s notable contributions to programming languages. 1:13 - Lattner’s ability to work from Python syntax down to hardware level. 1:22 - Mojo’s approach: combining Python syntax with high performance. 1:37 - Start of the interview with Chris Lattner. 1:57 - Lattner's background and achievements. 2:18 - Discussing LLVM and Clang as foundational projects. 2:32 - Development of Swift and its motivations. 3:05 - Swift's design and adoption by the Objective-C community. 3:32 - Transitioning to why Mojo was created. 4:00 - Starting Mojo from hardware efficiency needs. 4:46 - Building Mojo’s code generation before focusing on syntax. 5:09 - Challenges in programming modern hardware. 5:40 - Introduction to MLIR (Multi-Level Intermediate Representation). 6:05 - Differences between LLVM and MLIR. 6:39 - Use of MLIR for domain-specific compilers. 7:26 - Explaining multiple levels of abstraction in MLIR. 8:04 - Benefits of MLIR in compiler development. 9:06 - Decision to adopt Python syntax for Mojo. 10:03 - Challenges and benefits of building a new language. 10:54 - Importance of meeting developers where they are with familiar syntax. 11:59 - Compatibility and integration with the Python ecosystem. 12:35 - Discussion on Mojo’s type system and performance optimizations. 13:28 - Targeting AI and high-performance computing sectors. 14:26 - Addressing the absence of a language like Mojo in the current market. 15:01 - How familiar Mojo is to Python programmers. 15:16 - Mojo’s current development status and future features. 16:18 - Compatibility with existing Python packages. 16:49 - Explaining progressive typing in Mojo. 18:18 - Benefits of having real types in Mojo. 19:04 - Integrating Python’s dynamic features with Mojo’s static typing. 20:35 - Metaprogramming capabilities in Mojo. 21:23 - Memory management and referencing in Mojo. 22:17 - Differences between Rust and Mojo in handling lifetimes. 24:24 - How Mojo manages resources efficiently. 26:09 - Explaining zero-cost abstractions in Mojo. 27:25 - Parallelism and handling multiple cores in Mojo. 28:11 - Handling matrix operations and memory hierarchy. 29:14 - Optimizing for specific hardware in Mojo. 30:23 - Creating portable algorithms for GPUs and CPUs. 31:54 - High-level programming and libraries in Mojo. 32:19 - Discussing AI model building and deployment. 33:15 - Shifting focus from research to deployment in AI. 34:31 - Integration of AI researchers and production engineers. 35:54 - Addressing the complexity of AI deployment with Mojo. 36:51 - Benefits of using Mojo for AI and high-performance computing. 38:22 - Explaining the max engine and graph compiler. 39:01 - Overcoming current limitations in AI graph compilers. 40:09 - Challenges and benefits of building Mojo from scratch. 41:00 - Example use cases and improvements in Mojo. 42:22 - Practical benefits for Python programmers using Mojo. 43:00 - Encouraging community growth and contributions. 44:23 - Meeting developers’ needs with familiar tools. 45:02 - How Mojo simplifies and extends Python’s capabilities. 46:00 - Using Mojo for high-performance numeric programming. 47:04 - Emphasizing practicality and usability in Mojo’s design. 48:22 - Potential for community-driven improvements and optimizations. 49:05 - Future developments and community engagement. 50:00 - Final thoughts on Mojo’s impact and vision. 51:04 - Encouraging Python developers to explore Mojo. 52:09 - Closing remarks and encouragement to join the Mojo community. 53:16 - Additional resources and ways to get involved with Mojo. 54:00 - Encouraging Python programmers to contribute to Mojo’s development. 54:35 - The importance of inclusivity and collaboration in the open-source community. 55:12 - How Mojo handles performance-critical applications. 56:05 - The integration of async-await for high-performance applications. 56:34 - The differences between Mojo and Rust in terms of memory management. 57:06 - Using Mojo’s type system to manage resource lifetimes efficiently. 58:08 - The benefits of exclusive ownership in Mojo’s type system. 59:00 - Simplifying memory management for developers with Mojo. 1:00:03 - Discussing the practical aspects of implementing parallelism in Mojo. 1:01:00 - Options for parallelizing code in Mojo. 1:02:04 - Potential future development of an actor system for Mojo. 1:03:05 - Encouraging the use of high-level abstractions for parallelism. 1:04:10 - Handling different CPU architectures and their impact on performance. 1:05:20 - Practical examples of writing efficient code for different hardware. 1:06:14 - Benefits of portable algorithms in high-performance computing. 1:07:02 - Importance of optimizing memory hierarchy usage. 1:08:09 - Practical tips for working with two-dimensional arrays and matrices. 1:09:02 - Leveraging modern hardware features for performance gains. 1:10:16 - The future of high-performance computing and evolving hardware. 1:11:28 - How Mojo bridges the gap between hardware advancements and software development. 1:12:32 - Using Mojo’s advanced features for specific hardware optimizations. 1:13:39 - Practical application of MLIR in real-world scenarios. 1:14:25 - Benefits of using Mojo for AI research and deployment. 1:15:35 - The practicality of transitioning Python code to Mojo. 1:16:28 - Current status of Mojo’s development and future roadmap. 1:17:14 - The importance of community feedback and contributions. 1:18:00 - Concluding thoughts on Mojo’s potential impact on programming. 1:19:00 - Encouraging developers to experiment with Mojo. 1:20:02 - How Mojo aims to improve the developer experience. 1:21:06 - The broader vision for Mojo’s role in the programming ecosystem. 1:22:09 - Final remarks on the inclusivity and accessibility of Mojo. 1:23:00 - Encouraging the use of Mojo for various programming needs. 1:24:00 - Closing statements and thanks from Kris Jenkins. 1:24:10 - Encouraging listeners to like, share, and subscribe for future episodes. 1:24:30 - Kris Jenkins’ final goodbye and signing off the episode.
Sounds like what Julia is currently doing with a different syntax and fancy approaches like leveraging multiple dispatch. Chris is a legend and it would be good to see how Mojo disrupts the data science and AI space
Julia isn’t a superset of Python though. I would say this is very different than the approach Julia took. The biggest factor here from a developer’s standpoint is that, when completed, mojo will be a superset of Python. You would be able to compile already exiting Python code with mojo as is and get a noticeable performance improvement and you can integrate mojo into that codebase bit by bit and gain significant performance, safety and control improvements. Julia can’t do that and that isn’t their approach. They built what they consider as a better, separate language for scientific computing.
No. He uses libraries written in a mix of Mojo and his new IR (Intermediate Representation) to do the Code Generation rather than have a bloated monolithic compiler for a robust, parallel superset of Python. Presumably this IR compiles again from there in a form that suits the native architecture of the host machine, but I don't know much about LLVM or its replacement so I don't know if they are doing Java / Julia style static compile whole file first, or more immediately responsive at the cost of performance as it interprets this simple IR which pretty closely maps to Opcodes for most chips.
@@____uncompetative It compiles to machine code. But it doesn't do all compilation AoT. It's a hybrid mechanism between JIT and AoT depending on whether function is declared with def or fn. This allows you to match C++/Rust performance with fn and python dynamism with def. Compiler is also really fast, even when compiling pure static files, it takes few milliseconds to get the job done. In fact, it is so fast that you can compile->run projects faster than Python does bytecode compile -> Launch
@@Navhkrin Thank you. That's very informative. It sounds like they have a good language that could in time displace C++ with sufficient library support.
Mojo seems to have a sharp focus on abstracting the hardware acceleration. Regarding the title question, Nim has a pythonic syntax and is quite mature. It would be nice to know the differences between them.
My biggest question is: Does compiling my existing Python projects with a thin Mojo wrapper bring performance advantages or will I have to port it to native Mojo?
short answer, no. Some python syntax is supported but no all. And you need a cpython interpreter to use libraries, so no performance gains there. The plan of modular is to support any python script as it, but that is not the case nowadays.
Has the Arch compiler dropped yet or they still only supporting Ubuntu and RedHat? Love the tail call optimisation and strong typing. Machine learning/cuda style use case is great but it also pushes python towards being that viable functional programming lang while at the same time improving performance.
I have a question - does Mojo require powerful hardware to run? As it could do a lot and im afraid I may not have what it takes hardware-wise for it to be used optimally... Or could it just be run with the same specs like Python? I know it really depends on what you're doing with it but im speaking in general terms as well as in more broad ones
There's an official VSCode plugin: docs.modular.com/mojo/faq#is-there-ide-integration And I've been using Neovim. The mojo support was was straightforward to set up, as it's already part of in 'neovim/nvim-lspconfig'. Well, straightforward if you're already using Neovim for other coding. :-)
I think it is a very neat move to use a syntax plenty of people know and use it for a bit different language. Also, having a python with compilation to binary is on my wishlist already. :)
I think for specialist use cases this is going to be awesome. But I always wonder about language speed when developing run of the mill business applications (which Ive done for 35+ years), you have network latency, disk i/o database performance so real world code performance is less of an issue.
It extends Python to those Domains, so you can write GPU code with mojo instead of cuda or cuda binding to python while still able to write all the CPU code that python normally is used for.
Amazing as always. I would love it if you did an episode on NATS the message broker technology. Given the popularity of the kafka and big data episodes, i think it would fit right in
The one thing I never understood: WHY make it a superset of python, i.e. introducing a ton of new syntax, instead of just using all the syntax python already has, namely typing and decorators, and just use those by making them mandatory, if you want to have the speedups?
The tech is probably cool but I can sense that this is going to generalize and extend and abstract its way into a complex ecosystem that mortals don't understand but which corporations will pay for. I'm way over on the "small languages for everything" front so it offers very little for me.
As I remember him explain it, in another interview. The reason why the programming language didn't start out as open source, was because of bad experience from his previous one, where he listened to what everyone wanted and had to redo a lot of work, over and over again and still there will always be those that are mad that things didn't turn out the way they wanted. That's why he wants to make the language on his own, until it reaches a certain maturity, before he open source it. The service parts (including the ability to contact them and get help), that is the business model of Modular, might never be open source. But they are not a part of the language. They are written in it, so technically someone else can write something similar. Without their service, you will still be able to get a few x (up to about 10x, but might get closer to 15x when it is complete) better speed, with the same Python code running on Mojo, without having to do anything (because of their more modern and intelligent compiler). If you start using Mojo specific functions then that's when you can see 100x and 1000x numbers (by utilizing vector hardware, multi threading etc). Numbers higher than that, is basically cherry picking problems that can be up to 35 000x (at this point and the language isn't even done).
I fear this will be another of those "open source" projects that get ruined by the company trying to squeeze money out of it.. they're too numerous these days not to take that into consideration. It's a very interesting language but I'll wait at least a few years to see how free and open it is then..
I find that Mojo has a lot of hype around it. However, I’ve only been programming in Python for about 2 years and I find that the Mojo docs don’t have nearly enough examples.
A Language which can: Function at a low level Uses English language words Incremental compilation (only the line which needs to be changed.) Design your own function and reuse it use of small, simple functions Extend the compiler by writing new functions
When Stroustrup took C and bolted layer after layer of new and good concepts onto it, C++ became a large, if not cluttered, language without beauty. Still very successful, though. I wonder if taking Python and bolting new and shiny things onto it is doomed to become a large complicated clutter and if starting from scratch with a type system and an actor model and parallelism and ... would not be wiser (looking a Julia, maybe?). Me, I would love to see some strong data sciences modules be written for something clean and pragmatic and widely spread such as Golang, but that is not going to happen.
I really like the design advances from zig and rust, but they totally missed the boat on accelerators. Programming languages should help you get the most out of your hardware, and cpus have largely plateaued. There are going to be 100s of billions invested into AI, and they can't get enough accelerators, so getting the most out of what they have will be critical. I hope mojo can get enough funding (perhaps from AMD & MS) to execute on the promise.
Idk where you're seeing that. I'm on Linux, it's very straightforward: run curl to install modular, download mojo, modify your path. I've been compiling mojo code for the last 24 hours, no login. To use the MAX SDK you have to authorize, but not to compile mojo code.
Why would you base a language around interoperability with 2 vastly different languages, when the only benefit is getting a head start on the ecosystem building? The trade-offs made now become permanent technical debt for the life of the language, while the benefits fade after a few months while breaking the intuitive readability and usability of the language. By the time we graduate school you have 12 years of using the character set for a well defined math/grammar rules and you are turning half your character set into a push/pull door. When you start redefining words or mixing languages, you lose readability and intuitivity causing bugs. Ie. square brackets [ ] define sets, while parenthese ( ) are used for grouping, while : is used for listing separate items. These rules are engrained in our brain and become instinctive. What you call breaking your brain is not something to laugh off, because it becomes a constant mental load on the developer and a major stumbling block. When you write a language like C you are really writing algebra equations and using standard grammar rules. That is why things like arrow functions in JS are harder to interpret, as it redefines what we know about a syntax we have used all our life. When people talk about a language being bad, it is usually the syntax they are talking about.
No offense, but have you considered that the guy who built LLVM, Clang, Swift, and OpenCL might understand things about the trade offs of different approaches that you’re not aware of? This guy has decades of experience writing some of the most useful and widely used tools/languages in the world. I’m inclined to trust his judgment. That’s not to say you can’t have opinions, but you should at least be skeptical of your own opinions and ask yourself whether it’s possible someone who’s been doing this his whole life at the very highest level might know something you do not.
I think he meant CPython, which as the standard Python is interpreted so is very insecure for production code. Using compiled Mojo Python code should be fine.
They initially committed to progressively open sourcing it and they have been doing just that. They won’t open source their MAX engine which isn’t part of the language. What are you complaining about?
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
I'll be honest, this is a seriously impressive language by an absolute giant in the field. To oversimplify a bit, it has the safety of Rust, the performance of C, with the syntax of Python.
Couldn’t agree more, but I think something that’s understated is that via MLIR you’re basically getting access to a free hardware optimization abstraction layer!
The docs (and some folks who’ve messed around with Mojo more than me) have shown off how easy it is to literally command SIMD, which is usually just something most programmers can only hope their interpreter or compiler happen to do.
So sick!
like Nim for the last 7 years?
@@alelondon23but nim isn’t a superset of Python; Mojo aims to be one and it’s getting there fast
This is great but if it’s built on top of LLVM…and touching hardware to that degree-it’s hardly worth a look for the next 5 years for any GP programmer.
People truly don’t grasp just how little being a superset of Python matters-because the vast majority of people are productive in Python due to C / C++ libs.
It’ll be a crapshoot waiting for X lib to support Mojo’s way of doing things-the same way Typescript was supposed to be drop in superset of JS; but anybody that actually did web dev knows it was anything but seamless.
And all languages have the speed of C by Mojo’s standards 😅
Love these two guys though, awesome interview
@@alelondon23nim is alot of fun 🤩
Chapters:
00:00:00 - Python as a high-performance parallel programming language?
00:03:05 - The Journey to Building a New Language
00:05:55 - Writing High-Performance Loop Nests and IR
00:08:47 - MLIR and AST Generation
00:11:40 - Choosing Python for AI Development
00:14:23 - Introducing Mojo: A Different Language
00:17:01 - Interoperability with C in Mojo
00:19:50 - Introducing Mojo's Type System
00:22:38 - The Nature of Typing and Conversion
00:25:19 - Language Libraries and Data Types
00:28:16 - Hardware Acceleration and Library Extensibility
00:31:08 - The Power of Mojo and SIMD Vectors
00:33:51 - The Max Engine and Custom Operators
00:36:41 - Building bridges in the AI world
00:39:23 - Mojo programming in Python
00:42:26 - Compile time metaprogramming with Mojo
00:45:06 - Compile-time Python Programming
00:48:03 - Memory management in Mojo
00:50:58 - Lifetime Management in Rust and Mojo
00:53:45 - The Journey of Rust and Mojo
00:56:36 - Creating New Values in a List
00:59:19 - Parallelization and Threading in Mojo
01:02:09 - Parallelization in Mojo Programming Language
01:04:48 - Portable Algorithms and Applications
01:07:36 - GPUs and Multi-dimensional Vectors
01:10:37 - Utilizing Hardware Accelerators and Memory Hierarchy
01:13:25 - Mojo: Talking MLIR and LLVM
01:16:16 - The Growth of Mojo and the Open Source Community
01:19:00 - The Excitement of Open Development and Patent Coverage
01:21:37 - The Community Side of Programming
01:24:12 - Conclusion with Kris Jenkins
Kris, you never disappoint! I've listened to Chris talk about language design before. He has a brilliant approach, meet people where they're at, not where you want them to be. You have to be able to set your own ego aside in order to do that.
23:35 the guy developed swift and says "I'm still new to languages". What a humble guy. Really appreciate the interview. Very interesting!
This channel is a hidden gem and it deserves atleast 10x the current number of subscribers. Thank you for this excellent interview !
Outstanding interview. Chris is a true language engineer. Great interview as it gives a large audience an idea of the architectural drivers and technical challenges that led to mojo. Few people ever get properly exposed to these considerations to appreciate what it takes to do innovative language design and engineering.
This is a historical interview and goes straight to favorites.
Another fantastic episode. What a great guest. Really articulate, and you guys had great energy. Mojo is genuinely very exciting as a language. Zig was exciting too, but I can really see where Mojo fits in, and I think it could be really important in the next 10 or so years.
This is by far the best developer focused channel on RUclips. Amazing!
Thanks, glad you think so!
Holy heck! This completely changed how I see mojo working out. I assumed it was some second-system project that ignored cython, and was making a moonshot fueled by hype. It'-s so incredibly funny that the real motivation is the part of it that no one ever mentions, the MILR backend!
I really like the interviewer here, intelligent questions and he let's is guests actually talk, seems to be a rarity these days
Yeah lex is a disaster
Chris seemed to be genuinely happy to share everything he did, phenomenal interview.
Chris Lattner is great. Thank you for interviewing him!
MOJO is my last hope for solving the "computer language disaster". This man has all it needs to get it done (in time). Great Interview (as always). 👍👍👍👍👍
python, the computer language disaster. yep, that sums it up. lol
@scififan698 you are a rust or cpp fan ?
With reference to Rust dealing with immutablity with memcpy... I wish I could remember what talk it was... it might have been Anjana Vakil ❤ ... talking about implementing immutable trees of immutable values without copying in JavaScript... it was such good stuff.
Excellent interview! Chris Lattner is an amazing engineer. Would it be possible to get Bjarne Stroustrup for an interview? Is the man still alive? If so, it would be really interesting to hear the thoughts from the man who created the most influential programming language ever created, just a thought. Thanks for such a wonderful interview.
This was impressive and I had a lot of fun following along and searching through things you all were mentioning throughout the discussion. I have a lot more to learn!
I'm new to programming. I'm glad I watched this interview early.
Does Mojo has Halide/TVM like constructs? If not, why not? The main Mojo example uses for loops, but at 1:05:20 Chris mentions high level abstractions to avoid for loops.
Just discovered this channel, what a great interview.
Great interview! Happy I found your channel!
Nice interview, I really like your format. For me Nim do the job for now.
It would be interesting to have an interview with the creator of the V language (Vlang) Alex Medvedniko :)
Chris, I really enjoy your interviews and the quality of guests you land. I have no doubt your channel will grow in following tremendously.
Thanks! I hope so. 😀
Thanks for the interview!
And Mojo is/will be JIT, or do I have to compile a bundle to run a binary? Or can I do both? It sounds amazing!
Soon as they open source this I’m rewriting everything I’ve ever written in mojo
I think they did recently
@@eyekey346 I think they've only open sourced the standard library, and some other bits, but not the compiler yet.
@@lojicdotcomwhy would most people care about the compiler being open source? From my understanding they will open source that too, just not now. They probably won’t open source their MAX engine which makes sense as that’s their actual money maker.
Someone needs to document as much as possible in a formal study over the next decade so we can finally empirically understand why some languages get adopted and others don't. There are so many good languages available now it is almost overwhelming.
Wonderful conversation. Enjoyed the nuances of IR and AST and all kinds of compiler construction areas. Made me go to my grad school :)
0:00 - Introduction and questioning Python’s potential as a high-performance language.
0:25 - Introducing Mojo and its creator, Chris Lattner.
0:43 - Chris Lattner’s notable contributions to programming languages.
1:13 - Lattner’s ability to work from Python syntax down to hardware level.
1:22 - Mojo’s approach: combining Python syntax with high performance.
1:37 - Start of the interview with Chris Lattner.
1:57 - Lattner's background and achievements.
2:18 - Discussing LLVM and Clang as foundational projects.
2:32 - Development of Swift and its motivations.
3:05 - Swift's design and adoption by the Objective-C community.
3:32 - Transitioning to why Mojo was created.
4:00 - Starting Mojo from hardware efficiency needs.
4:46 - Building Mojo’s code generation before focusing on syntax.
5:09 - Challenges in programming modern hardware.
5:40 - Introduction to MLIR (Multi-Level Intermediate Representation).
6:05 - Differences between LLVM and MLIR.
6:39 - Use of MLIR for domain-specific compilers.
7:26 - Explaining multiple levels of abstraction in MLIR.
8:04 - Benefits of MLIR in compiler development.
9:06 - Decision to adopt Python syntax for Mojo.
10:03 - Challenges and benefits of building a new language.
10:54 - Importance of meeting developers where they are with familiar syntax.
11:59 - Compatibility and integration with the Python ecosystem.
12:35 - Discussion on Mojo’s type system and performance optimizations.
13:28 - Targeting AI and high-performance computing sectors.
14:26 - Addressing the absence of a language like Mojo in the current market.
15:01 - How familiar Mojo is to Python programmers.
15:16 - Mojo’s current development status and future features.
16:18 - Compatibility with existing Python packages.
16:49 - Explaining progressive typing in Mojo.
18:18 - Benefits of having real types in Mojo.
19:04 - Integrating Python’s dynamic features with Mojo’s static typing.
20:35 - Metaprogramming capabilities in Mojo.
21:23 - Memory management and referencing in Mojo.
22:17 - Differences between Rust and Mojo in handling lifetimes.
24:24 - How Mojo manages resources efficiently.
26:09 - Explaining zero-cost abstractions in Mojo.
27:25 - Parallelism and handling multiple cores in Mojo.
28:11 - Handling matrix operations and memory hierarchy.
29:14 - Optimizing for specific hardware in Mojo.
30:23 - Creating portable algorithms for GPUs and CPUs.
31:54 - High-level programming and libraries in Mojo.
32:19 - Discussing AI model building and deployment.
33:15 - Shifting focus from research to deployment in AI.
34:31 - Integration of AI researchers and production engineers.
35:54 - Addressing the complexity of AI deployment with Mojo.
36:51 - Benefits of using Mojo for AI and high-performance computing.
38:22 - Explaining the max engine and graph compiler.
39:01 - Overcoming current limitations in AI graph compilers.
40:09 - Challenges and benefits of building Mojo from scratch.
41:00 - Example use cases and improvements in Mojo.
42:22 - Practical benefits for Python programmers using Mojo.
43:00 - Encouraging community growth and contributions.
44:23 - Meeting developers’ needs with familiar tools.
45:02 - How Mojo simplifies and extends Python’s capabilities.
46:00 - Using Mojo for high-performance numeric programming.
47:04 - Emphasizing practicality and usability in Mojo’s design.
48:22 - Potential for community-driven improvements and optimizations.
49:05 - Future developments and community engagement.
50:00 - Final thoughts on Mojo’s impact and vision.
51:04 - Encouraging Python developers to explore Mojo.
52:09 - Closing remarks and encouragement to join the Mojo community.
53:16 - Additional resources and ways to get involved with Mojo.
54:00 - Encouraging Python programmers to contribute to Mojo’s development.
54:35 - The importance of inclusivity and collaboration in the open-source community.
55:12 - How Mojo handles performance-critical applications.
56:05 - The integration of async-await for high-performance applications.
56:34 - The differences between Mojo and Rust in terms of memory management.
57:06 - Using Mojo’s type system to manage resource lifetimes efficiently.
58:08 - The benefits of exclusive ownership in Mojo’s type system.
59:00 - Simplifying memory management for developers with Mojo.
1:00:03 - Discussing the practical aspects of implementing parallelism in Mojo.
1:01:00 - Options for parallelizing code in Mojo.
1:02:04 - Potential future development of an actor system for Mojo.
1:03:05 - Encouraging the use of high-level abstractions for parallelism.
1:04:10 - Handling different CPU architectures and their impact on performance.
1:05:20 - Practical examples of writing efficient code for different hardware.
1:06:14 - Benefits of portable algorithms in high-performance computing.
1:07:02 - Importance of optimizing memory hierarchy usage.
1:08:09 - Practical tips for working with two-dimensional arrays and matrices.
1:09:02 - Leveraging modern hardware features for performance gains.
1:10:16 - The future of high-performance computing and evolving hardware.
1:11:28 - How Mojo bridges the gap between hardware advancements and software development.
1:12:32 - Using Mojo’s advanced features for specific hardware optimizations.
1:13:39 - Practical application of MLIR in real-world scenarios.
1:14:25 - Benefits of using Mojo for AI research and deployment.
1:15:35 - The practicality of transitioning Python code to Mojo.
1:16:28 - Current status of Mojo’s development and future roadmap.
1:17:14 - The importance of community feedback and contributions.
1:18:00 - Concluding thoughts on Mojo’s potential impact on programming.
1:19:00 - Encouraging developers to experiment with Mojo.
1:20:02 - How Mojo aims to improve the developer experience.
1:21:06 - The broader vision for Mojo’s role in the programming ecosystem.
1:22:09 - Final remarks on the inclusivity and accessibility of Mojo.
1:23:00 - Encouraging the use of Mojo for various programming needs.
1:24:00 - Closing statements and thanks from Kris Jenkins.
1:24:10 - Encouraging listeners to like, share, and subscribe for future episodes.
1:24:30 - Kris Jenkins’ final goodbye and signing off the episode.
Great talk. Pity that so many ads spoil the flow.
Sounds like what Julia is currently doing with a different syntax and fancy approaches like leveraging multiple dispatch. Chris is a legend and it would be good to see how Mojo disrupts the data science and AI space
Julia isn’t a superset of Python though. I would say this is very different than the approach Julia took. The biggest factor here from a developer’s standpoint is that, when completed, mojo will be a superset of Python. You would be able to compile already exiting Python code with mojo as is and get a noticeable performance improvement and you can integrate mojo into that codebase bit by bit and gain significant performance, safety and control improvements. Julia can’t do that and that isn’t their approach. They built what they consider as a better, separate language for scientific computing.
Julia is missing the actual static typing and low level stuff though..
Question: When Chris says code generation, he's means machine code n NOT bytecode/IR ?
No. He uses libraries written in a mix of Mojo and his new IR (Intermediate Representation) to do the Code Generation rather than have a bloated monolithic compiler for a robust, parallel superset of Python. Presumably this IR compiles again from there in a form that suits the native architecture of the host machine, but I don't know much about LLVM or its replacement so I don't know if they are doing Java / Julia style static compile whole file first, or more immediately responsive at the cost of performance as it interprets this simple IR which pretty closely maps to Opcodes for most chips.
@@____uncompetative It compiles to machine code. But it doesn't do all compilation AoT. It's a hybrid mechanism between JIT and AoT depending on whether function is declared with def or fn. This allows you to match C++/Rust performance with fn and python dynamism with def.
Compiler is also really fast, even when compiling pure static files, it takes few milliseconds to get the job done. In fact, it is so fast that you can compile->run projects faster than Python does bytecode compile -> Launch
@@Navhkrin Thank you. That's very informative. It sounds like they have a good language that could in time displace C++ with sufficient library support.
This guy is an absolute legend! Chris Lattner is too, of course :D
Im very interested in Mojo. It still seems to be too young for me but as Rust developer I look forward to moving to Mojo at some point.
Learning Mojo would be like doing a computer course with best practices with years of Chris Lattner experience, all combined into one language
Omg! Yes! Chris is my hero.
What a treat, thanks for this. Love hearing Chris Lattner talk
I really hope Mojo can deliver on its promises
Very good episode. Congratulations.
Mojo seems to have a sharp focus on abstracting the hardware acceleration. Regarding the title question, Nim has a pythonic syntax and is quite mature. It would be nice to know the differences between them.
Nim is very very good in speed and executable size. Very nice language. Very nice way to interface with Python too.
Don't waste your time on a not used language like Nim. It's only nice for Personal projects and it has a lot of bad decisions.
My biggest question is: Does compiling my existing Python projects with a thin Mojo wrapper bring performance advantages or will I have to port it to native Mojo?
there's a demo that you can prob find online showing that just wrapping python code into mojo already can make it quite fwster
short answer, no. Some python syntax is supported but no all. And you need a cpython interpreter to use libraries, so no performance gains there. The plan of modular is to support any python script as it, but that is not the case nowadays.
Has the Arch compiler dropped yet or they still only supporting Ubuntu and RedHat?
Love the tail call optimisation and strong typing. Machine learning/cuda style use case is great but it also pushes python towards being that viable functional programming lang while at the same time improving performance.
I have a question - does Mojo require powerful hardware to run? As it could do a lot and im afraid I may not have what it takes hardware-wise for it to be used optimally... Or could it just be run with the same specs like Python? I know it really depends on what you're doing with it but im speaking in general terms as well as in more broad ones
It's like 100x lighter than Python. And because its compiler is faster than C++ or Rust's Mojo is basically as light as it gets.
@@Navhkrin Wow ok, thanks a lot!
Looking forward to seeing Mojo evolve. Maybe I'll have an option to transition to from Cython - as long as there is an upside.
awesome interview thanks!
What IDE would you recommend for Mojo?
There's an official VSCode plugin: docs.modular.com/mojo/faq#is-there-ide-integration
And I've been using Neovim. The mojo support was was straightforward to set up, as it's already part of in 'neovim/nvim-lspconfig'. Well, straightforward if you're already using Neovim for other coding. :-)
Notepad for you should be ok
Use Ms Word is enough for pojo😂
PyCharm
Lol why notepad? @@r2com641
A good replacement for rust... now that caught my ear. Looking forward to mojo.
I think it is a very neat move to use a syntax plenty of people know and use it for a bit different language. Also, having a python with compilation to binary is on my wishlist already. :)
If a guy like Lattner is fed-up with C++, what should us mortals do?
I think for specialist use cases this is going to be awesome. But I always wonder about language speed when developing run of the mill business applications (which Ive done for 35+ years), you have network latency, disk i/o database performance so real world code performance is less of an issue.
Great interview with a compiler legend. Thanks!
This is a very well done interview. :)
Nice!! Lattner is a Genius.
Awesome interview I agree with the other commenter that said you should have 10x the subscribers!!!!
Thanks! Hopefully in time, we will. 🤞
Mojo just might be good enough to pry my fingers off of D, Julia and Crystal. It's on my list of languages to try.
Those are unique languages, what has your experience been with them
please make a book for MLIR
Maybe this is a dumb question, but does mojo replace python or triton/cuda/open*l?
It extends Python to those Domains, so you can write GPU code with mojo instead of cuda or cuda binding to python while still able to write all the CPU code that python normally is used for.
Amazing as always. I would love it if you did an episode on NATS the message broker technology. Given the popularity of the kafka and big data episodes, i think it would fit right in
Im so interested in mojo i hope it was released soon on windows.
Haircut looks good (also the green polish), longer hair has that wizardy-vibe though :D depends on what you're going for :D
Haha, not specifically aiming for wizard but I’m happy to get there by accident. 😁
APL/Morten Kromberg/Aaron Hsu/Arthur Whitney interview When?
One thing to convince Chris Lattner is to use type inference where possible than gradual typing and being dynamic.
Another great interview. It's been a breeze and very informative. Thank you!
The memory leak joke made me do a sharp nose exhale
You had me at "replacement for cuda". ❤
Cuda.jl in Julia is a replacement for cuda.
when will Mojo be ready for Windows?
It will come GPU support
Chris is a compiler titan. Mojo looks cool.
The one thing I never understood: WHY make it a superset of python, i.e. introducing a ton of new syntax, instead of just using all the syntax python already has, namely typing and decorators, and just use those by making them mandatory, if you want to have the speedups?
Python syntax has semantics - if people use type annotations for mypy, you don't want that to interfere with compilation.
@@ZeroPlayerGame Ever heard about mypyc? They do exactly that: Use the annotations for compilation.
Ideally you want anything that is written in the current CPython to just run. If you want to use the Mojo "extensions", you just use the Mojo types.
You should have called it Monty instead of Mojo.
Monty is funnier, but Mojo is a much better name.
The tech is probably cool but I can sense that this is going to generalize and extend and abstract its way into a complex ecosystem that mortals don't understand but which corporations will pay for. I'm way over on the "small languages for everything" front so it offers very little for me.
Kepp up the Good Work Chris and Chris, you are doing gods work. #chrislike
Are you the same person who does the Morgonaut Channel?
No.
Woooww!!! Chris lattner❤🔥❤🔥❤🔥
But will Mojo be full opensource and free?
I understood yes, it will be, but the world of GPUs seems so closed to me, and cloud service companies tend to be vendor locked.... Am I too paranoid?
#1:17:58
@bart2019 Yep, as I said above, I'm just a little paranoid about GPUs and service provider companies 😅
As I remember him explain it, in another interview. The reason why the programming language didn't start out as open source, was because of bad experience from his previous one, where he listened to what everyone wanted and had to redo a lot of work, over and over again and still there will always be those that are mad that things didn't turn out the way they wanted.
That's why he wants to make the language on his own, until it reaches a certain maturity, before he open source it.
The service parts (including the ability to contact them and get help), that is the business model of Modular, might never be open source. But they are not a part of the language. They are written in it, so technically someone else can write something similar.
Without their service, you will still be able to get a few x (up to about 10x, but might get closer to 15x when it is complete) better speed, with the same Python code running on Mojo, without having to do anything (because of their more modern and intelligent compiler).
If you start using Mojo specific functions then that's when you can see 100x and 1000x numbers (by utilizing vector hardware, multi threading etc). Numbers higher than that, is basically cherry picking problems that can be up to 35 000x (at this point and the language isn't even done).
I fear this will be another of those "open source" projects that get ruined by the company trying to squeeze money out of it.. they're too numerous these days not to take that into consideration. It's a very interesting language but I'll wait at least a few years to see how free and open it is then..
why would you want a dynamically typed language that isn't typesafe?
Every time I listen to this guy I have to google a bunch of stuff lol.
have you seen the new BLEND language? it is a similar concept, high performance + massively parallel language with Python-esque syntax
great podcast
Great interview, thanks for the great content!
this will be Chris Lattners Masterpiece, i am beyond excited, thanks for this amazing interview
Python's syntax is its best innovation.
I find that Mojo has a lot of hype around it. However, I’ve only been programming in Python for about 2 years and I find that the Mojo docs don’t have nearly enough examples.
That’s because Mojo is still a work in progress that hasn’t even been truly released yet.
Here’s to you Chris Lattner, the 10000x programmer 🤣
Such bliss! Apparently, PyTorch and Numba doesn’t exist.
still not available on the most used OS.
I thought it's turtles all the was down!?😂
Haircut looking good!
Awesome, but I really wish to see a roadmap?
A Language which can:
Function at a low level
Uses English language words
Incremental compilation (only the line which needs to be changed.)
Design your own function and reuse it
use of small, simple functions
Extend the compiler by writing new functions
When Stroustrup took C and bolted layer after layer of new and good concepts onto it, C++ became a large, if not cluttered, language without beauty. Still very successful, though. I wonder if taking Python and bolting new and shiny things onto it is doomed to become a large complicated clutter and if starting from scratch with a type system and an actor model and parallelism and ... would not be wiser (looking a Julia, maybe?).
Me, I would love to see some strong data sciences modules be written for something clean and pragmatic and widely spread such as Golang, but that is not going to happen.
Great video, by the way.😊
I wonder how this compares to taichi?
I really like the design advances from zig and rust, but they totally missed the boat on accelerators. Programming languages should help you get the most out of your hardware, and cpus have largely plateaued. There are going to be 100s of billions invested into AI, and they can't get enough accelerators, so getting the most out of what they have will be critical. I hope mojo can get enough funding (perhaps from AMD & MS) to execute on the promise.
Also open source the whole stack as quickly as possible.
Mojo: Login to compile your code - lol
Idk where you're seeing that. I'm on Linux, it's very straightforward: run curl to install modular, download mojo, modify your path. I've been compiling mojo code for the last 24 hours, no login. To use the MAX SDK you have to authorize, but not to compile mojo code.
You misspelled his name :)
I know! 😭 I missed out a 't', and only realised after it was published. RUclips doesn't let you edit videos, so I will have to live with my shame. 😔
@@DeveloperVoices the interview is excellent BTW
Thanks!
@@DeveloperVoices ask him to legally change his name so the video title is correct
@@blindshellvideos😂
this guy looks exactly like that one actor and i cant get over it
Over here, we're all trying to guess which actor you could mean. 😁
@@DeveloperVoices your guest looks like Jed Reese, had to look it up lmao first saw him in the ringer.
@@BrentMaliceOh wow that is a CRAZY resemblance!
Why would you base a language around interoperability with 2 vastly different languages, when the only benefit is getting a head start on the ecosystem building? The trade-offs made now become permanent technical debt for the life of the language, while the benefits fade after a few months while breaking the intuitive readability and usability of the language. By the time we graduate school you have 12 years of using the character set for a well defined math/grammar rules and you are turning half your character set into a push/pull door. When you start redefining words or mixing languages, you lose readability and intuitivity causing bugs.
Ie. square brackets [ ] define sets, while parenthese ( ) are used for grouping, while : is used for listing separate items. These rules are engrained in our brain and become instinctive. What you call breaking your brain is not something to laugh off, because it becomes a constant mental load on the developer and a major stumbling block.
When you write a language like C you are really writing algebra equations and using standard grammar rules. That is why things like arrow functions in JS are harder to interpret, as it redefines what we know about a syntax we have used all our life. When people talk about a language being bad, it is usually the syntax they are talking about.
it's not the "only" benefit, it's arguably the only benefit which matters for actual adoption.
No offense, but have you considered that the guy who built LLVM, Clang, Swift, and OpenCL might understand things about the trade offs of different approaches that you’re not aware of? This guy has decades of experience writing some of the most useful and widely used tools/languages in the world. I’m inclined to trust his judgment. That’s not to say you can’t have opinions, but you should at least be skeptical of your own opinions and ask yourself whether it’s possible someone who’s been doing this his whole life at the very highest level might know something you do not.
@@therainman7777 don't need to go so hard on it, but yeah, the guy's smart, he knows adoption matters in the real world far far more than elegance.
Why do people think that python isn't good for deploying ?
(In the context of AI)
Global Interpreter Lock would be 1 problem I think
I think he meant CPython, which as the standard Python is interpreted so is very insecure for production code. Using compiled Mojo Python code should be fine.
The Mojo installer blackscreened my PC and that's the end of my Mojo journey
😂
What is intolerable... is that Mojo is not even open source. Bleh.
Making a language open source before its specs are finalized is a great way to put it into development hell.
They initially committed to progressively open sourcing it and they have been doing just that. They won’t open source their MAX engine which isn’t part of the language. What are you complaining about?
@@playea123Nothing. People just love to complain. They truly, deeply, love it.
@@Navhkrinso is Zig development hell?
@@stretch8390yes and zig sucks