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!
I was skeptical when I first heard about Mojo, then I saw Chris's name, now I'm pretty sure we would be able to train huge LLM's on my microwave pretty soon. And I'm only slightly exaggerating in the faith I have in this man 😋
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). 👍👍👍👍👍
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.
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.
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!
@@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.
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 :)
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.
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.
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.
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.
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.
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
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. :-)
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.
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.
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.
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.
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.
Assuming I am a robot, I come across two nuts threaded onto a bolt, sandwiching some washers (they really didn´t want this to shake free). I can decide to remove this equipment, and my colleague can decide to help. I have a spanner, and he has a socket-driver. Whilst the socket driver is faster, it can´t tackle really long threads, due to lack of depth. So mostly he unbolts stuff, and asks me for the deeper threads. Hey, were working on a schedule to get this stuff unbolted, and repaired, before sun up. You get roasted on the moon.
Hang on, this isn´t working well. WTF. Why-o-why do americans insist on using inches, and wierd threads... ? We´ll use a different library. It´s not an exact fit, but I can wadge some white plumbing-tape around this nut, to help convert from mm to inch socket. Hey, it´s off, phew.
@@markcoren2842 Of all the languages I've programmed in, Swift is plain awful, especially when there were inspiring languages such as C#, Ada, Object Pascal and Java around. I would put it up there with Rust as one of my least favorite languages. It doesn't solve offer any real advantages over other languages. The syntax is hard to get your head around and very hard to read, such as the optional semicolon and return statements. Its curly brace usage is a gratuitous and a nightmare to visually parse. It relies too heavily on symbols instead of keywords. Finally, its OOP is quite limited and its constructors are overly complicated. It's too bad Apple chose it as the only first class language for developing iOS and MacOS apps.
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 🤩
23:35 the guy developed swift and says "I'm still new to languages". What a humble guy. Really appreciate the interview. Very interesting!
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.
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.
This is by far the best developer focused channel on TH-cam. Amazing!
Thanks, glad you think so!
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.
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
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 was skeptical when I first heard about Mojo, then I saw Chris's name, now I'm pretty sure we would be able to train huge LLM's on my microwave pretty soon. And I'm only slightly exaggerating in the faith I have in this man 😋
Chris Lattner is great. Thank you for interviewing him!
Chris seemed to be genuinely happy to share everything he did, phenomenal interview.
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 ?
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.
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.
I'm new to programming. I'm glad I watched this interview early.
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.
Thanks for the interview!
Just discovered this channel, what a great interview.
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!
Great interview! Happy I found your channel!
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. 😀
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.
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 :)
Omg! Yes! Chris is my hero.
Wonderful conversation. Enjoyed the nuances of IR and AST and all kinds of compiler construction areas. Made me go to my grad school :)
If a guy like Lattner is fed-up with C++, what should us mortals do?
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..
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.
Very good episode. Congratulations.
I really hope Mojo can deliver on its promises
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.
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!
What a treat, thanks for this. Love hearing Chris Lattner talk
This is a very well done interview. :)
A good replacement for rust... now that caught my ear. Looking forward to mojo.
Learning Mojo would be like doing a computer course with best practices with years of Chris Lattner experience, all combined into one language
awesome interview thanks!
Great talk. Pity that so many ads spoil the flow.
Nice!! Lattner is a Genius.
Great interview with a compiler legend. Thanks!
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
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.
Chris is a compiler titan. Mojo looks cool.
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.
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 I agree with the other commenter that said you should have 10x the subscribers!!!!
Thanks! Hopefully in time, we will. 🤞
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. :)
Im so interested in mojo i hope it was released soon on windows.
please make a book for MLIR
The memory leak joke made me do a sharp nose exhale
You should have called it Monty instead of Mojo.
Monty is funnier, but Mojo is a much better name.
Another great interview. It's been a breeze and very informative. Thank you!
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.
One thing to convince Chris Lattner is to use type inference where possible than gradual typing and being dynamic.
You had me at "replacement for cuda". ❤
Cuda.jl in Julia is a replacement for cuda.
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.
Kepp up the Good Work Chris and Chris, you are doing gods work. #chrislike
Here’s to you Chris Lattner, the 10000x programmer 🤣
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
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!
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?
Woooww!!! Chris lattner❤🔥❤🔥❤🔥
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
Every time I listen to this guy I have to google a bunch of stuff lol.
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.
Python's syntax is its best innovation.
Great interview, thanks for the great content!
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.
this will be Chris Lattners Masterpiece, i am beyond excited, thanks for this amazing interview
great podcast
when will Mojo be ready for Windows?
It will come GPU support
Such bliss! Apparently, PyTorch and Numba doesn’t exist.
Haircut looking good!
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.
have you seen the new BLEND language? it is a similar concept, high performance + massively parallel language with Python-esque syntax
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.
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.
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?
still not available on the most used OS.
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.
Are you the same person who does the Morgonaut Channel?
No.
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
Also open source the whole stack as quickly as possible.
I thought it's turtles all the was down!?😂
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!
Awesome, but I really wish to see a roadmap?
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.😊
The Mojo installer blackscreened my PC and that's the end of my Mojo journey
😂
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.
Assuming I am a robot, I come across two nuts threaded onto a bolt, sandwiching some washers (they really didn´t want this to shake free). I can decide to remove this equipment, and my colleague can decide to help. I have a spanner, and he has a socket-driver. Whilst the socket driver is faster, it can´t tackle really long threads, due to lack of depth. So mostly he unbolts stuff, and asks me for the deeper threads. Hey, were working on a schedule to get this stuff unbolted, and repaired, before sun up. You get roasted on the moon.
Hang on, this isn´t working well. WTF. Why-o-why do americans insist on using inches, and wierd threads... ? We´ll use a different library. It´s not an exact fit, but I can wadge some white plumbing-tape around this nut, to help convert from mm to inch socket. Hey, it´s off, phew.
Flexibility wins... and we fixed Mamma robot, so can have a million more siblings, to help mining operation...
@@wld-phWtf are you talking about?
You misspelled his name :)
I know! 😭 I missed out a 't', and only realised after it was published. TH-cam 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😂
He made opencl too? Wtf
Chris Lattner work on Swift was a disaster.
Care to actually substantiate your claim or was it just a bad day?
@@markcoren2842 Of all the languages I've programmed in, Swift is plain awful, especially when there were inspiring languages such as C#, Ada, Object Pascal and Java around. I would put it up there with Rust as one of my least favorite languages. It doesn't solve offer any real advantages over other languages.
The syntax is hard to get your head around and very hard to read, such as the optional semicolon and return statements. Its curly brace usage is a gratuitous and a nightmare to visually parse. It relies too heavily on symbols instead of keywords. Finally, its OOP is quite limited and its constructors are overly complicated. It's too bad Apple chose it as the only first class language for developing iOS and MacOS apps.
What happened?
TH-cam keeps deleting my comments.
Oh