Please more videos just like this! I also really appreciated the additional explanations with code examples 👌
@PanBolorum7 ай бұрын
agreed. this is appropriately technical, with useful Q/A. And the interjections were welcome.
@liquidmobius7 ай бұрын
@@PanBolorum 💯
@romanpopov10417 ай бұрын
great introduction to ownership, please more videos from Chris Lattner, he has great ability to explain things!
@garanceadrosehn96917 ай бұрын
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.
@JaceComix7 ай бұрын
Coming from a high-level language background, really appreciate this content!
@Ivoshevo7 ай бұрын
Am an iOS developer working with swift and I love this Mojo language.
@denisblack98977 ай бұрын
Same, Chris has made my life so much more pleasant!
@JJOULK3 ай бұрын
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
@georgioszampoukis19667 ай бұрын
Any possible timeframe for native windows support?
@samuel.ibarra4 ай бұрын
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?
@narendrapatwardhan684 ай бұрын
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.
@olafschluter7065 ай бұрын
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.
@itsmeonline-cw8xq4 ай бұрын
Awesome share. Looking forward to part II :)
@g1m0kolis7 ай бұрын
Thank you for sharing this publicly!
@Iturner72Ай бұрын
the example at 8:56 was money
@LiminalThought6 ай бұрын
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.
@BulbaWarrior7 ай бұрын
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?
@NickSmit_7 ай бұрын
`__init__` requires `self` to be fully initialized before it returns. Otherwise, you will receive a compile-time error.
@malekabbassi92757 ай бұрын
I enjoyed this so much
@BracingRex69896 ай бұрын
a good lesson about memory and mojo, thanks modular !
@oscbit7 ай бұрын
Excited for this type of content!
@alurma6 ай бұрын
What a cliff hanger at the end!!!
@Navhkrin7 ай бұрын
"You don't have to write std::move" ok im sold
@rezabani9904Ай бұрын
doesn't this kind of MLIR optimization slows the compilation speed?
@alurma6 ай бұрын
Wow, how early destruction works with tail calls really impresses me.
@Little-bird-told-me7 ай бұрын
Very excited with mojo. learn from Rust but doesn't want to be Rust !
@Jowbaka7 ай бұрын
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.
@MestisoHapa7 ай бұрын
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
@Jowbaka7 ай бұрын
@@MestisoHapa but in _init_(inout self), then self is uninitialized, right?
@MestisoHapa7 ай бұрын
@@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
@Jowbaka7 ай бұрын
@@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).
@MestisoHapa7 ай бұрын
@@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-)
@budiardjo66106 ай бұрын
best part 43:01, and really love this series.
@kevinkkirimii7 ай бұрын
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 ?
@billb62837 ай бұрын
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.
@MestisoHapa7 ай бұрын
They are going by a year.release versioning system. For example, 24.3 is the 3rd release in 2024.
@billb62837 ай бұрын
@@MestisoHapa Thank you
@keoghanwhimsically22685 ай бұрын
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.
@blaster_proАй бұрын
Is the talk about lifetimes available??? Please make so if it is not.. thanks in advance
@ephemer7 ай бұрын
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.
@АртемФедоров-ю7бАй бұрын
What about native concurrency?
@TheQwerty25847 ай бұрын
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.
@PauloFeodrippe9 күн бұрын
The video is great! Just the edit that’s kinda weird, it makes me anxious as it has almost no pauses, the silent parts have been removed 😅
@sirinath7 ай бұрын
Hope the next prt will be sooner than later.
@kilosierraalpha7 ай бұрын
Fantastic! Subbed!!
@gorandev7 ай бұрын
Thanks!
@TheNaive7 ай бұрын
When part 2 is comming
@kevinkkirimii7 ай бұрын
Mojo has learned things from Rust, but does not want to be Rust - Hallelujah.
@ThankYouESM7 ай бұрын
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.
@ScottzPlaylists7 ай бұрын
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.
@wayne88637 ай бұрын
Think about how much you pay to go to a CS program in an University these days. This is free!
@PaulJurczak7 ай бұрын
Can't wait for the day I will be able to replace C/C++/Numba/Python with Mojo.
@LawrenceColeman-up6tx7 ай бұрын
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.
@MestisoHapa7 ай бұрын
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.
@hellolk774 ай бұрын
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.
@bobweiram63217 ай бұрын
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.
@liquidmobius7 ай бұрын
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.
@bobweiram63217 ай бұрын
@@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.
@liquidmobius7 ай бұрын
@@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.
@yuan.pingchen30567 ай бұрын
@@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
@MestisoHapa7 ай бұрын
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.
@Lircking5 ай бұрын
"python level programmer" lol
@damonguzman7 ай бұрын
Real devs use dark mode…. Dark mode…. Please, have slides that are darker. My eyes are searing.
@TwoToTheSix6 ай бұрын
Real devs also use light mode, funnily enough. Some also have difficulty reading light-on-dark text, such as those with astigmatism.
@deepfakescoverychannel67107 ай бұрын
ownership. in python? are you serious?
@MestisoHapa7 ай бұрын
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.
@deepfakescoverychannel67107 ай бұрын
@@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
@MestisoHapa7 ай бұрын
@@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
@MestisoHapa7 ай бұрын
@@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.
@Justin-wj4yc6 ай бұрын
@@deepfakescoverychannel6710 Intelligent people want something in-between with better tradeoffs
@_vk034 ай бұрын
No doubt chris is a great engineer.. But he is not a good teacher.. for beginners..😂 Teaching should be left to Indians..
@tao41243 ай бұрын
😁
@androth15027 ай бұрын
it's not a serious programming language if it doesn't support windows.
@letsplaychannel62766 ай бұрын
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.
@androth15025 ай бұрын
@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.
@SciDiFuoco137 ай бұрын
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