Great conversation and information here, thanks a lot for sharing. Chris referred to directories of the Mojo compiler source code - I thought just the stdlib was open sourced so far? Am I right in thinking this is not accessible to us still? Also, I was surprised to hear some of the questions from the team about many of these points: do I understand correctly that Chris is hacking away at this in real time and then sharing with the team as it comes along? I'm mostly curious about how the work is being divvied up in the team at Modular. edit: I watched the first seconds of the video again and it answered a lot of the questions I had, thanks.
Does anyone think PyPy rewritten in 🔥Mojo🔥instead of python, could be faster than CPython❓ They say It's already faster, actually, but how much faster can it go? I propose the name PyJo because MoPy sounds slow. 😀 Once 🔥Mojo🔥is stable, and finished they should do that and make it the standard implementation instead of CPython.
Very interesting talk, thanks for posting it. It gives me more confidence that coding in Mojo will handle lifetimes while avoiding some of the complicated issues which I've seen come up when programming in Rust.
Very explanatory! I'd love to see more of these talks like the advanced lifetimes mentioned. They might´ve been initially for internal devs but they definitely show what is happening for the rest building stuff on a new language
Before this one becomes production ready, they have started to discredit Rust already. Be careful in believing all of these, specially when the guy is from industry ( ex Apple / Swift ). Market manipulation is a something very normal for them.
Do you have any plans to open-source Mojo (the compiler not the stdlib)? I feel it would be a learning opportunity for compiler designers interested in MLIR and also make developing new kernel ops/layers easier.
20:02 While the policy to not allow mutations of “borrowed” values seems acceptable, the policy around the same for RValues seems like it will just create annoyances. It’s common for good API programming for a function to massage and normalize its input arguments to, for example, suppport robustness, i.e., “be liberal in what you accept”. This would always require the Mojo programmer to come up with new names internally, or purposely misname the input parameter from the most natural so they can more natural names may be used for the internal variables. It will also require more experienced programmers to retrain their habits when using Mojo, adding another roadbump. Is this really a problem that needed to be solved? I remain excited about Mojo, but as someone who thinks Rust makes too many compromises for safety to be run to write it in, I’d hate to see Mojo go in the same direction.
borrowed and owned are key words that are at least simpler to understand, why not have mutable/changeable instead of inout as a key word which is a bit more clear to the user ?
Did I got it right: if I have a value of a non-copyable type, which is a type with move-semantics in my Book, I need to be explicit and use the transfer (aka move) operator when passing that value to a function that wants to own that value, so that it does the only thing it can, namely moving? Whereas when I have a type that is copyable, the compiler pulls all tricks to avoid copying it? And whether it gets moved or copied depends on the circumstances, it is not even sufficient to look at a function signature? I have my doubts that this is easy to teach. The semantics in Rust are clear: a type has either copy (the Copy trait) or move semantics, and if you want to pass a copy of a value with move semantics over to anyone instead of moving that value to them, you have to be explicit and clone the thing (if that's possible, i.e. the type has the Clone trait). This has the additional benefit that you can spot immediately where allocations happen (which are very often unnecessary in Rust). You do not want hidden allocations.
Instead of "inout self" isn't it clearer to have "init self". Where init means that it takes in an uninitialized value that must be initialized at the end of the function. With an init keyword, there is no need for special case magic.
It is not necessarily an initialization. What is being passed in can already have a value (it is often used as `inout self` to help initialize self, but it does not have to be an initialization). "inout" is more like "mutable" and says that the value I am using can be mutated, and this change will be propagated to the caller. A lot of people seem to not like inout as a keyword, but I believe it came from the swift language
@@Jowbaka In __init__ methods, yes. But inout can be used in any function or method. It's not strictly for initialization. As it says in the video, inout is basically an LValue type. It's mutable/assignable, and when the value changes, the newly set value is still there after the function has returned. In an __init__ method, if you forget to assign an initial value, the compiler will flag that as an error
@@MestisoHapa inout works well for all other functions, but to me _init_(init self) is clearer than _init_(inout self), because in a regular usage inout always requires the argument to already be initialized before calling the method or function. Another possibility is _init_(out self) (from c++ proposal, not my idea).
@@Jowbaka But then you're adding a new keyword that's only applicable in one scenario. AFAIK, you're right, in other functions the inout parameter would already need to be initialized, but I don't see that as requiring a distinction between the concepts of initialization and mutability/assignment. Initialization is always assignment but it's not mutation. And that's what an LValue is...either mutability or assignment. So instead of having to learn two keywords, you just need to learn one. Also, keywords should always be considered thoroughly, because it means you can no longer use it as a symbol elsewhere in the language (unless you make a much more complicated parser). They could have gone the route of C# also, with separate "in" and "out" parameter keywords. But since Chris Lattner made Swift, and Swift already has inout (and therefore, a lot of swift programmers are already familiar with the concept), I guess Chris decided to reuse it for Mojo. Me personally, I would have preferred 'mut' (and there was some discussion about it github.com/modularml/mojo/blob/main/proposals/lifetimes-keyword-renaming.md#inout-keyword--ref-or-mutref-)
Started learning mojo recently. I’m mostly excited to get to tensors. But I know I have to go through the basics of Strings, Lists, Dicts, and Sets before I move on. Logic flow is pretty straight forward as well. But, really excited to start working on AI related problems.
I recently made a very fun game in Python for this, then wondered what are all the options to possibly earn money from it accepting donations only... and suddenly thought it should be especially for smartphones. However... I don't know if Mojo can help make that happen sometime very soon I hope.
very well explained, thanks!! Personally i (and think many more people) just need 1 more think to be fully invested, the capacity of creating a python library with mojo.
42:17 So what happens with early destruction under control flow? Will ASAP destruction be able to eliminate an allocation in this case: ``` var s = String("mojo") if false: use(s) ``` Not sure if I have access to IR tools as a simple user Also a design question: does __init__() allow partially initialized objects or is it a compiler error?
It's too bad most of the newfangled languages are inspired by the same languages they intend to replace. Ada is an excellent language with decades of success in industry, yet it's largely ignored.
The point behind Mojo is it's a superset of Python to make adoption and implementation much easier. Python devs should have very little trouble getting up to speed. It's designed to be familiar and usable out of the box without having to learn a whole new syntax. That design choice was done on purpose.
@@liquidmobius Python is such an ugly language. While it's easy to learn, it feels more like a scripting language. Its code lacks structure and feels like it will fall off the page. I yearn for Algol-like languages with English keywords like Object Pascal and Ada.
@@bobweiram6321 I actually started learning Ada a few weeks ago, with the goal being to become relatively proficient with Spark. My main interest is safe systems-level languages, and Ada/Spark fits that bill perfectly. Time will tell if I stick with it or not. I'm moving more towards embedded, so we'll see. As far as Mojo though, it's specifically targeted at the AI space, since ML is done primarily in Python. It's designed to make deployment easier, so developers don't have to rewrite their models in C++ or Rust. So in that sense, it's really targeted at a specific niche. They are planning on broadening it to more general-purpose use case. I personally really like it, but wouldn't even consider it for general-purpose systems programming.
@@bobweiram6321 Python is structured, it just does not use parentheses to distinguish code blocks (replaced by indentation), which is actually an advantage. The algo language is the predecessor of the C language, and the C language tends to use symbols to represent a block. Instead of using begin/end, in other words, your head is the same as it was decades ago. don't get me wrong, I don't hate using parentheses to represent code blocks. I just hate the { that starts the code at the end of the line and I can't find the corresponding ending. Even if the IDE can mark the ending for me, I also hate that they are not on the same X. coordinate
I have done rust for about 5 years, and I hoped that rust would catch on more, but there's a theory in economics called Network Effects, and essentially it means that the more people use something., the more other people will use that thing. It's contagious (and I suppose you could say addicting too). The simple fact is that people don't want to learn all the new syntax and rules of rust even if it has the speed of C/C++ with greater memory safety and higher level abstractions. While I'm not the biggest fan of python (not an expression oriented language, non-lexical scoping, types are optional, etc), it IS the lingua franca of machine learning and scientific computing in general. So it makes sense for Modular to "meet programmers where they are". It's also a proven strategy that worked with javascript -> typescript, and objective-c -> swift.
I REALLY want to use mojo...but they still don't have basic backwards compatibility features like lambda done. I worry mojo won't get off the ground because they're too focused on hardware performance and aren't building enough features to justify the switch... to get that hardware performance.
depending on how you want to count when mojo was first started, it's only either a year, or 2 years old. As a point of reference, Graydon Hoare worked on rust alone for 2 years before he even released it internally within Mozilla. Then it was a another year inside Mozilla, and then (IIRC) 3 more years open sourced until rust got GA'ed in 2015. Mojo is still a toddler at this point.
mojo is aiming to be a superset of python. There's a subset of mojo that will look exactly like python. But when you need the speed of C/C++/rust, then you will have to roll up your sleeves and understand how memory works and not rely on everything being a heap allocated object with dynamic fields.
@@deepfakescoverychannel6710 the whole raison d'etre of mojo is so that pythonistas can gradually learn systems programming concepts to make their code faster. They wont have to learn all of C or Rust all at once. Moreover, C and Rust don't have native SIMD for example (without dropping to non-portable assembly or experimental crates), or the concept of GPU/NPU address spaces. Native vectorization will be simpler and more portable in mojo than C/Rust
@@deepfakescoverychannel6710 the whole raison d'etre of mojo is that pythonistas can take their code and make gradual improvements as they learn more about systems level programming concepts. They don't have to make a leap into an entirely new language like C or Rust. It is a proven strategy that worked with javascript -> typescript and objective-C -> swift. Moreover, C or Rust are not SIMD native nor are they hardware accelerator agnostic with the concept of Address Spaces (eg, CUDA's unified memory). And even if you drop to assembly, it wont be hardware portable. That's one of the nice things that MLIR (versus say clang compiling to LLVM IR) brings to the table.
right, but who said Mojo is a serious programming language yet. It's still in development and find out how to do things stage. Windows support is unnecessary at this stage and might be implemented when the foundation is set up.
@silas-bv1ql are you delulu? most games programmers, enterprise business, anybody who wants to deliver high end applications to end users, quality sound engineering, video/special effects... these are all written on windows for windows, and sometimes mac. most linux programmers spend all day writing vim scripts. linux is falling apart. even the linux foundation is spending their money on anything but linux.
Please more videos just like this! I also really appreciated the additional explanations with code examples 👌
agreed. this is appropriately technical, with useful Q/A. And the interjections were welcome.
@@PanBolorum 💯
great introduction to ownership, please more videos from Chris Lattner, he has great ability to explain things!
"You don't have to write std::move" ok im sold
Thank you for sharing this publicly!
What a cliff hanger at the end!!!
Any possible timeframe for native windows support?
Great conversation and information here, thanks a lot for sharing. Chris referred to directories of the Mojo compiler source code - I thought just the stdlib was open sourced so far? Am I right in thinking this is not accessible to us still?
Also, I was surprised to hear some of the questions from the team about many of these points: do I understand correctly that Chris is hacking away at this in real time and then sharing with the team as it comes along? I'm mostly curious about how the work is being divvied up in the team at Modular.
edit: I watched the first seconds of the video again and it answered a lot of the questions I had, thanks.
Very excited with mojo. learn from Rust but doesn't want to be Rust !
Does anyone think PyPy rewritten in 🔥Mojo🔥instead of python, could be faster than CPython❓
They say It's already faster, actually, but how much faster can it go?
I propose the name PyJo because MoPy sounds slow. 😀
Once 🔥Mojo🔥is stable, and finished they should do that and make it the standard implementation instead of CPython.
Coming from a high-level language background, really appreciate this content!
Very interesting talk, thanks for posting it. It gives me more confidence that coding in Mojo will handle lifetimes while avoiding some of the complicated issues which I've seen come up when programming in Rust.
Very explanatory! I'd love to see more of these talks like the advanced lifetimes mentioned. They might´ve been initially for internal devs but they definitely show what is happening for the rest building stuff on a new language
Am an iOS developer working with swift and I love this Mojo language.
Same, Chris has made my life so much more pleasant!
Before this one becomes production ready, they have started to discredit Rust already.
Be careful in believing all of these, specially when the guy is from industry ( ex Apple / Swift ).
Market manipulation is a something very normal for them.
Do you have any plans to open-source Mojo (the compiler not the stdlib)? I feel it would be a learning opportunity for compiler designers interested in MLIR and also make developing new kernel ops/layers easier.
20:02 While the policy to not allow mutations of “borrowed” values seems acceptable, the policy around the same for RValues seems like it will just create annoyances. It’s common for good API programming for a function to massage and normalize its input arguments to, for example, suppport robustness, i.e., “be liberal in what you accept”. This would always require the Mojo programmer to come up with new names internally, or purposely misname the input parameter from the most natural so they can more natural names may be used for the internal variables. It will also require more experienced programmers to retrain their habits when using Mojo, adding another roadbump. Is this really a problem that needed to be solved?
I remain excited about Mojo, but as someone who thinks Rust makes too many compromises for safety to be run to write it in, I’d hate to see Mojo go in the same direction.
borrowed and owned are key words that are at least simpler to understand, why not have mutable/changeable instead of inout as a key word which is a bit more clear to the user ?
Did I got it right: if I have a value of a non-copyable type, which is a type with move-semantics in my Book, I need to be explicit and use the transfer (aka move) operator when passing that value to a function that wants to own that value, so that it does the only thing it can, namely moving? Whereas when I have a type that is copyable, the compiler pulls all tricks to avoid copying it? And whether it gets moved or copied depends on the circumstances, it is not even sufficient to look at a function signature? I have my doubts that this is easy to teach. The semantics in Rust are clear: a type has either copy (the Copy trait) or move semantics, and if you want to pass a copy of a value with move semantics over to anyone instead of moving that value to them, you have to be explicit and clone the thing (if that's possible, i.e. the type has the Clone trait). This has the additional benefit that you can spot immediately where allocations happen (which are very often unnecessary in Rust). You do not want hidden allocations.
45:54 What if all the fields are transferred? Do I need to initialize all of them again or the compiler knows the field is kind of destroyed already?
Think about how much you pay to go to a CS program in an University these days. This is free!
Instead of "inout self" isn't it clearer to have "init self". Where init means that it takes in an uninitialized value that must be initialized at the end of the function. With an init keyword, there is no need for special case magic.
It is not necessarily an initialization. What is being passed in can already have a value (it is often used as `inout self` to help initialize self, but it does not have to be an initialization). "inout" is more like "mutable" and says that the value I am using can be mutated, and this change will be propagated to the caller. A lot of people seem to not like inout as a keyword, but I believe it came from the swift language
@@MestisoHapa but in _init_(inout self), then self is uninitialized, right?
@@Jowbaka In __init__ methods, yes. But inout can be used in any function or method. It's not strictly for initialization. As it says in the video, inout is basically an LValue type. It's mutable/assignable, and when the value changes, the newly set value is still there after the function has returned. In an __init__ method, if you forget to assign an initial value, the compiler will flag that as an error
@@MestisoHapa inout works well for all other functions, but to me _init_(init self) is clearer than _init_(inout self), because in a regular usage inout always requires the argument to already be initialized before calling the method or function. Another possibility is _init_(out self) (from c++ proposal, not my idea).
@@Jowbaka But then you're adding a new keyword that's only applicable in one scenario. AFAIK, you're right, in other functions the inout parameter would already need to be initialized, but I don't see that as requiring a distinction between the concepts of initialization and mutability/assignment. Initialization is always assignment but it's not mutation. And that's what an LValue is...either mutability or assignment.
So instead of having to learn two keywords, you just need to learn one. Also, keywords should always be considered thoroughly, because it means you can no longer use it as a symbol elsewhere in the language (unless you make a much more complicated parser). They could have gone the route of C# also, with separate "in" and "out" parameter keywords. But since Chris Lattner made Swift, and Swift already has inout (and therefore, a lot of swift programmers are already familiar with the concept), I guess Chris decided to reuse it for Mojo.
Me personally, I would have preferred 'mut' (and there was some discussion about it github.com/modularml/mojo/blob/main/proposals/lifetimes-keyword-renaming.md#inout-keyword--ref-or-mutref-)
Awesome share. Looking forward to part II :)
Started learning mojo recently. I’m mostly excited to get to tensors. But I know I have to go through the basics of Strings, Lists, Dicts, and Sets before I move on. Logic flow is pretty straight forward as well. But, really excited to start working on AI related problems.
Mojo has learned things from Rust, but does not want to be Rust - Hallelujah.
Uhh but Rust is winning anyway 🦀
Wow, how early destruction works with tail calls really impresses me.
No doubt chris is a great engineer..
But he is not a good teacher.. for beginners..😂
Teaching should be left to Indians..
😁
Hope the next prt will be sooner than later.
I enjoyed this so much
Excited for this type of content!
I recently made a very fun game in Python for this, then wondered what are all the options to possibly earn money from it accepting donations only... and suddenly thought it should be especially for smartphones. However... I don't know if Mojo can help make that happen sometime very soon I hope.
Can't wait for the day I will be able to replace C/C++/Numba/Python with Mojo.
very well explained, thanks!! Personally i (and think many more people) just need 1 more think to be fully invested, the capacity of creating a python library with mojo.
42:17 So what happens with early destruction under control flow? Will ASAP destruction be able to eliminate an allocation in this case:
```
var s = String("mojo")
if false:
use(s)
```
Not sure if I have access to IR tools as a simple user
Also a design question: does __init__() allow partially initialized objects or is it a compiler error?
`__init__` requires `self` to be fully initialized before it returns. Otherwise, you will receive a compile-time error.
It's too bad most of the newfangled languages are inspired by the same languages they intend to replace. Ada is an excellent language with decades of success in industry, yet it's largely ignored.
The point behind Mojo is it's a superset of Python to make adoption and implementation much easier. Python devs should have very little trouble getting up to speed. It's designed to be familiar and usable out of the box without having to learn a whole new syntax. That design choice was done on purpose.
@@liquidmobius Python is such an ugly language. While it's easy to learn, it feels more like a scripting language. Its code lacks structure and feels like it will fall off the page. I yearn for Algol-like languages with English keywords like Object Pascal and Ada.
@@bobweiram6321 I actually started learning Ada a few weeks ago, with the goal being to become relatively proficient with Spark. My main interest is safe systems-level languages, and Ada/Spark fits that bill perfectly. Time will tell if I stick with it or not. I'm moving more towards embedded, so we'll see. As far as Mojo though, it's specifically targeted at the AI space, since ML is done primarily in Python. It's designed to make deployment easier, so developers don't have to rewrite their models in C++ or Rust. So in that sense, it's really targeted at a specific niche. They are planning on broadening it to more general-purpose use case. I personally really like it, but wouldn't even consider it for general-purpose systems programming.
@@bobweiram6321 Python is structured, it just does not use parentheses to distinguish code blocks (replaced by indentation), which is actually an advantage. The algo language is the predecessor of the C language, and the C language tends to use symbols to represent a block. Instead of using begin/end, in other words, your head is the same as it was decades ago. don't get me wrong, I don't hate using parentheses to represent code blocks. I just hate the { that starts the code at the end of the line and I can't find the corresponding ending. Even if the IDE can mark the ending for me, I also hate that they are not on the same X. coordinate
I have done rust for about 5 years, and I hoped that rust would catch on more, but there's a theory in economics called Network Effects, and essentially it means that the more people use something., the more other people will use that thing. It's contagious (and I suppose you could say addicting too).
The simple fact is that people don't want to learn all the new syntax and rules of rust even if it has the speed of C/C++ with greater memory safety and higher level abstractions. While I'm not the biggest fan of python (not an expression oriented language, non-lexical scoping, types are optional, etc), it IS the lingua franca of machine learning and scientific computing in general. So it makes sense for Modular to "meet programmers where they are". It's also a proven strategy that worked with javascript -> typescript, and objective-c -> swift.
a good lesson about memory and mojo, thanks modular !
best part 43:01, and really love this series.
"python level programmer" lol
When part 2 is comming
As I write this, how is Mojo on version 24? Python, released decades ago is on version 3, my Julia says version 1.9.2.
They are going by a year.release versioning system. For example, 24.3 is the 3rd release in 2024.
@@MestisoHapa Thank you
Fantastic! Subbed!!
Thanks!
I REALLY want to use mojo...but they still don't have basic backwards compatibility features like lambda done. I worry mojo won't get off the ground because they're too focused on hardware performance and aren't building enough features to justify the switch... to get that hardware performance.
depending on how you want to count when mojo was first started, it's only either a year, or 2 years old. As a point of reference, Graydon Hoare worked on rust alone for 2 years before he even released it internally within Mozilla. Then it was a another year inside Mozilla, and then (IIRC) 3 more years open sourced until rust got GA'ed in 2015. Mojo is still a toddler at this point.
Real devs use dark mode…. Dark mode…. Please, have slides that are darker. My eyes are searing.
Real devs also use light mode, funnily enough. Some also have difficulty reading light-on-dark text, such as those with astigmatism.
ownership. in python? are you serious?
mojo is aiming to be a superset of python. There's a subset of mojo that will look exactly like python. But when you need the speed of C/C++/rust, then you will have to roll up your sleeves and understand how memory works and not rely on everything being a heap allocated object with dynamic fields.
@@MestisoHapa if i need the speed of C i will code in C or ISPC(intel) which is more future-proof and stable than mojo
@@deepfakescoverychannel6710 the whole raison d'etre of mojo is so that pythonistas can gradually learn systems programming concepts to make their code faster. They wont have to learn all of C or Rust all at once.
Moreover, C and Rust don't have native SIMD for example (without dropping to non-portable assembly or experimental crates), or the concept of GPU/NPU address spaces. Native vectorization will be simpler and more portable in mojo than C/Rust
@@deepfakescoverychannel6710 the whole raison d'etre of mojo is that pythonistas can take their code and make gradual improvements as they learn more about systems level programming concepts. They don't have to make a leap into an entirely new language like C or Rust. It is a proven strategy that worked with javascript -> typescript and objective-C -> swift.
Moreover, C or Rust are not SIMD native nor are they hardware accelerator agnostic with the concept of Address Spaces (eg, CUDA's unified memory). And even if you drop to assembly, it wont be hardware portable. That's one of the nice things that MLIR (versus say clang compiling to LLVM IR) brings to the table.
@@deepfakescoverychannel6710 Intelligent people want something in-between with better tradeoffs
it's not a serious programming language if it doesn't support windows.
right, but who said Mojo is a serious programming language yet. It's still in development and find out how to do things stage. Windows support is unnecessary at this stage and might be implemented when the foundation is set up.
@silas-bv1ql are you delulu? most games programmers, enterprise business, anybody who wants to deliver high end applications to end users, quality sound engineering, video/special effects... these are all written on windows for windows, and sometimes mac.
most linux programmers spend all day writing vim scripts.
linux is falling apart. even the linux foundation is spending their money on anything but linux.
11:06 not sure why you would want to make all those changes in the Rust version while *v = vec![8, 8] would have simply worked