Please more videos just like this! I also really appreciated the additional explanations with code examples 👌

@PanBolorum

Ай бұрын

agreed. this is appropriately technical, with useful Q/A. And the interjections were welcome.

@liquidmobius

Ай бұрын

@@PanBolorum 💯

great introduction to ownership, please more videos from Chris Lattner, he has great ability to explain things!

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.

Am an iOS developer working with swift and I love this Mojo language.

@denisblack9897

Ай бұрын

Same, Chris has made my life so much more pleasant!

Any possible timeframe for native windows support?

Thank you for sharing this publicly!

Excited for this type of content!

I enjoyed this so much

Wow, how early destruction works with tail calls really impresses me.

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.

a good lesson about memory and mojo, thanks modular !

"You don't have to write std::move" ok im sold

Thanks!

best part 43:01, and really love this series.

Fantastic! Subbed!!

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.

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 ?

What a cliff hanger at the end!!!

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_

Ай бұрын

`__init__` requires `self` to be fully initialized before it returns. Otherwise, you will receive a compile-time error.

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.

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.

@MestisoHapa

Ай бұрын

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

Ай бұрын

@@MestisoHapa but in _init_(inout self), then self is uninitialized, right?

@MestisoHapa

Ай бұрын

@@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

@Jowbaka

Ай бұрын

@@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).

@MestisoHapa

Ай бұрын

@@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-)

Very excited with mojo. learn from Rust but doesn't want to be Rust !

Hope the next prt will be sooner than later.

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.

@MestisoHapa

Ай бұрын

They are going by a year.release versioning system. For example, 24.3 is the 3rd release in 2024.

@billb6283

Ай бұрын

@@MestisoHapa Thank you

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.

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.

When part 2 is comming

Think about how much you pay to go to a CS program in an University these days. This is free!

Can't wait for the day I will be able to replace C/C++/Numba/Python with Mojo.

Mojo has learned things from Rust, but does not want to be Rust - Hallelujah.

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.

@MestisoHapa

Ай бұрын

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.

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.

@liquidmobius

Ай бұрын

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.

@bobweiram6321

Ай бұрын

@@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.

@liquidmobius

Ай бұрын

@@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.pingchen3056

Ай бұрын

@@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

@MestisoHapa

Ай бұрын

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.

ownership. in python? are you serious?

@MestisoHapa

Ай бұрын

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

Ай бұрын

@@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

@MestisoHapa

Ай бұрын

@@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

@MestisoHapa

Ай бұрын

@@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-wj4yc

23 күн бұрын

@@deepfakescoverychannel6710 Intelligent people want something in-between with better tradeoffs

Real devs use dark mode…. Dark mode…. Please, have slides that are darker. My eyes are searing.

@TwoToTheSix

16 күн бұрын

Real devs also use light mode, funnily enough. Some also have difficulty reading light-on-dark text, such as those with astigmatism.

it's not a serious programming language if it doesn't support windows.

@letsplaychannel6276

Ай бұрын

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.

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