A great video as usual, Arjan :) I think you missed one (the) major selling point of Mojo, which is the ability to write generic code and then compile it for specific hardware like GPUs or edge devices. It will mean a mojo/python dev can write highly optimised code without (re-)leaning low-level libraries/languages like Rust/C++/CUDA. I recommend people read about MLIR and MAX, from Modular - the creators of Mojo 🔥
To me the most compelling part of mojo is the promise that you'll be able to compile to various targets like wasm. Binaries under a mb would be awesome.
The killer feature of mojo is that it is a python superset. Moving from python to rust means a complete rewrite. Moving from python to mojo hopefully means you can incrementally update your python to mojo in the performance critical pieces. But yeah it's new so we will have to wait and see how this all works out.
That is an important point. It is one of the main reasons that languages like TypeScript, Swift, and Kotlin have really taken off in their respective platforms because they interop so well with what they are attempting to replace. TypeScript works well with JavaScript, Swift works well with Objective-C, Kotlin works well with Java. Languages like Rust do get a lot of hype, but in reality most developers in their day jobs are not migrating their codebases to Rust. Something like TypeScript, Swift, or Kotlin is a much easier sell as you can do small incremental changes rather than just a complete rewrite. Unless you have a brand new project or performance is so critical that you need to migrate to something like Rust, then you won't get buy in from senior managers. However, that is not to disrespect Rust. I think it is great that we have a lower level systems language like Rust with the performance of something like C and C++ while also being safer and more approachable than C and C++.
There is no comparison to python (or to any other languages). Python is way to common today and will only get better. The great thing about all these new languages, is they can work with python. Good example is Microsoft investing in both python and Rust over C#. Its a tell tale Python and links to other languages is a better/smarter option.
Python broke backwards compatibility and abandoned their community and it still can't thread across cores. Python can get better? I doubt it. There's a reason why companies are investing hundreds of millions of dollars to create langauges that replace Python - it's because it's so fundamentally flawed that it can't be fixed. Nobody's spending $100 million dollars trying to fix Java, that's for sure.
I've found Nim to my liking, too. It is easy to learn when coming from C and Python. It has a consistent syntax that's easy on the eyes. And it has a well-reasoned set of features. Best of all (for me), it can target embedded microcontrollers (with and without MMUs).
Absolutely on point. Two more things that may have been worth mentioning in the video is that: 1. It is based on a MLIR infrastructure 2. It is a language created to solve a fundamental problem - writing performant AI/ML code with all debugging and profiling advantages all while staying within the same context of one programming language.
Yes but its important to say that Mojo is not limited by this, you can use it for everything since it will have direct python Support and therefore all the packages from python without zero costs
Well mojo is meant mainly for machine learning. For most cases, python will be just fine and used by most people. Not everyone need the extra performance.
@@coenfuse I also don't understand the "Python isn't going away" argument. People actually mean CPython (so what about PyPy...). Who cares about the internal structure of Python, you care about the result. So if the results of Mojo and CPython code are identical, why use CPython?
Based on the title of the video, I anticipate it will demonstrate running Python code with Mojo to evaluate its performance speed. The key selling point of Mojo is running Python code as is and you get 3 times faster than python, no modifications required.
Why did the TH-cam title say "The End of Python?" This is not the title that appears next, namely "Choosing your language...". Sensational titles like the first one make me click "Do not recommend". I just thought I'd share this because your video is good.
It seems Mojo runs Python "as is" three times faster! That's nice for the users and also nice for our planet. The increase in speed typically comes from more efficient usuage of the CPU which directly means less energy consumption. Next to that 3x faster execution also means that (when thinking big) we only need a third of the physical hardware to run our software! I also like the ideas of borrowing and traits from Rust. This will probably make it easier to move towards Rust in the future and gain another 25x performance increase.
My two cents - I really dislike type hinting, there is a massive peer pressure for using them everywhere but they are in the end pointless because you can't actually depend on them (e.g. you can't always trust that a function will get an argument of a correct type just because you have provide a type hint). They don't actually improve your code only help you improve it and make it more readable just like docstrings but unlike docstrings clutter the code directly (which of course is a matter of preference). Mojo being strongly typed fixes that perfectly, the types finally do actually improve the code itself.
I'm normally against yet another language but there's something here that i think is crucial. The barrier to entry is so much lower because of the prevalence and simplicity of python. As an embedded C++ guy at heart who now is using python, i couldn't imagine trying to teach a junior C++ engineer these days, but this mojo looks achievable. Particularly if it's the juniors first introduction to strict typing.
C++ is not only being taught today, it has evolved into a very nice language, with C++17 onwards and QT Creator it just feels faster to develop and better documented than Python. I know because I just did a couple of university projects in both, C++ and Python.
@@NicolayGiraldo I am not saying it doesn't happen (I teach C++ myself, but not at work.) It's very different writing a C++ project for yourself and by yourself, vs in a team where, if you have a coding standards doc, there is constant argument about the readability vs benefit of qualifiers, for example. It's a very different environment in a workplace where everything has to be done yesterday; complexity and nuance is avoided because it takes too long to do in normal workflow, let along teach a young dev or apprentice, when compared to Python. Hope that makes a bit of sense!
yeah that is some major oversight from the Mojo team...I would reassign the keyword right away if I'm using Mojo. We can reassign keywords in Mojo, correct? just like we can in Python.
after some thoughts, like Arjan mentioned in the video that Mojo draws inspiration from Rust. in Rust the way we write mutable variable is by using 'let mut', and just 'let' for immutable variable. i think that's why they went with let for constant / immutable.
Needs to be mentioned that "owned" doesn't necessary means that the caller transfers ownership, just that you're guaranteed to own what you receive. There is a difference here, a value can be passed to an owned argument without transferring ownership, in that case a copy is created.
As fas as I understood, the main issue of integrating Python with C (I don't know if it is the same with Rust) is debugging. Switching context makes debugging troublesome. Mojo, which is not subject to context switching, should solve the issue. It's extremely interesting, but I found it closer to C or Rust than to Python. The performance, however, seems astonishing.
Yeah, Python ecosystem is a complete and total mess with all these incompatible projects that fix things that Python can't fix. Glad finally someone will fix Python for good and finally replace it with something that can thread across cores. RIP Python.
I like this video! It would be really cool, if you would come back to Mojo in the future to recap what has changed. :) Mojo has much more really cool features not mentioned here. Eg. whole metaprogramming at compile time (like Zig), where you could compute data during compilation. Another feature is related to having control over different optimizations like unrolling, passing directly via registers, passing by reference, inlining and much more ;) Also I agree, that at this stage it is still beta. Much more in terms of stability and usability will come in the future 😊
I think this ownership feature would require additional explanatory video with a lot of examples because it's quite exceptional. I've seen some programming languages so far, but this ownership thing doesn't look similar to anything I've seen before, and therefore it might be as well confusing for people using only Python and not having too much experience with other languages. Also, choosing "let" for constant values doesn't seem the best option. Why not explicitly call it "const"? That would be perfectly coherent with variables being initialized with "var" keyword: variables go with "var", constants with "const". And why structs has to be decorated? It would make more sense if structs were by default value types instead of classes being reference types, as it is the case in e.g. C#. Unless the creators of Mojo want to keep class as pure Python object and structs as pure Mojo objects and there will be another decorator to make structs type-static reference types. Then it would make sense to me. As for "DynamicVector", why not simply call it "List" with capital "L"? Mojo is building on top of Python, so this is similar situation as with C# and C++, and in C# there are C# versions of C++ objects, e.g. String vs string. Well, actually they are aliases, so there is no real difference, but the naming could be used as an example for new types in Mojo. If "DynamicVector" is supposed to be type-static version of Python lists, then naming it with that longer name is not the best decision. A good programming language has short but comprehensive names. If there's a need to make a distinction between dynamic and static collections, there is a list vs. array distinction. And actually they are both vectors, but "list" and "array" are shorter names than "vector" and I'd even say more common. And why a struct needs to inherit from CollectionElement to be a collection element? What's the benefit of implicitly not inheriting that? Why a struct has to be made special first before we can put in a collection? Really, it's very easy to make a new programming language cluttered and verbose with types, keywords, the necessity of writing a ton of code to perform a simple task. But a real art is to make it short and comprehensible, and this the general direction all programming languages are evolving to right now. So, I cannot understand why Mojo is going to be imperfect from the very beginning. Maybe they really want to go Python way and create Mojo 3 at some point loosely compatible with Mojo 2...
Ownership is the superpower of Rust. It is not trivial to grasp, esp. in larger projects. I don't think it is a good fit for the existing Python community. It isn't Python's garbage collector which makes the language slow, not at all.
Have a performance problem first, which cannot be solved within python. Most of the performance issues are language independent. Until then the robustness and ecosystem of a mature language like python is superior.
Sweet! Thank you for the rundown and for sharing this superb language. I prefer type safety over how Python allows reassignment to a different type, which can lead to issues. Of course, I also like templates that process generic types, like in C++, but I enjoy writing less code to get something done more, so I've only spent a little time in C++ or learning the standard template library. It makes my head hurt. LOL! I must have missed your introduction to Mojo, but I will look at it now; thanks again!
So im simply thinking: Im a machine learning engineer with python, yet i also learnt a clean, performance oriented way of computation via c++ for the means of parallel programming and working with cuda. I also know of the python library Numba, which seeks to increase performance by optimizing certain computations, where nowadays there is hardware available that python just does not take account of at the moment. Mojo seems to promise both of the advantages: a) allow me to code close(r) to the hardware, using the principles of parallel programming whilst still b) allowing me to remain in python and using jit compiled code for my tutorials and playing with the code. Latter is very important to me, becuase that is basically how i do datascience.
Numba does jit, Mojo does not, it is plain LLVM. And then there is JAX, also using a jit and able to make use of CUDA etc. Numba and JAX have a high chance to actually outperform Mojo. JITs are awesome. Java often outperforms C because of its amazing JIT. Moreover, Numba supports true explicit multithreading from within Python.
@@falklumoWrong, Wrong and Wrong. Why should someone use thousand of tools to speedup code. That introduces a Lot of dependencies for a project. In Mojo you have every python package for free with better performance in EVERY case and not just in certain cases like Numba. You simply switch your file names to mojo and you are done. Why do you defend python so much, it literaly makes no sense in this case. Mojo is Python + Rust, best of both worlds.
@@ITSecNEO I don't defend Python, I actually think it was a historic mistake. However, this does not make me think that forging a GC language and a Borrowing language into one is a great idea either ;)
@@ITSecNEO The Rust memory model requires discipline and experience. It is safe but adds a similar level of complexity to software projects as do pointers in C. I know Python programmers and most of them would not be capable to cope with it. Python projects most of the time are toy level projects only. Serious projects can be written in Mojo (some day), right. But all appropriate programmers I know of actually hate the syntax of Python and idiosyncrasies like True + False etc. They want hierarchical type systems which support refactoring. There is Rust which is great for systems programming. And there is Python which some day will become a grown up language with a GC, no GIL, a full type system, a true JIT and fast execution. But they won't merge. Their intersection aka Mojo is empty. P.S. If you wonder. I believe the most grown up language today is Kotlin (although I don't use it that often actually).
Mojo got me very excited. I wanted to try it out but had too much trouble installing it on Windows and eventually gave up. Truth is, I haven't done anything so far that Python couldn't keep up with. Python is strong because it's accessible, versatile, quick to deploy, and has at least a couple of libraries to choose from for any particular task you need. I believe that's what Mojo is going for, but still has a long way to go.
"Wanted to try" xD Thats the problem, you didnt even try Mojo but you claim things about Mojo which are wrong. Mojo is a Python superset, search this term up and you will understand that every statement from you about python also holds for Mojo
@@ITSecNEO They want it to be a Python superset. But at least according to the docs things aren't that smooth yet. There's no guarantee that every Python library will work, for example. There are other things in progress that I read on their website but don't remember the details right now. That's my experience. I spent a few hours trying to install it and eventually gave up. I'll just wait for further development because I've still got a ways to go with regular Python and will just focus on it right now. If you've actually tried Mojo and want to share your experience you're more than welcome to do so.
@@luisgentil Have you tried to install it via WSL? There is no official windows support at the moment. And yes, at the moment its not a superset, but it will be. Its not 1.0 yet, so we need to wait. For now, you should focus on python. With a strong understanding of python it will be very easy for you to learn Mojo once it reaches 1.0
@@ITSecNEO I've tried with WSL, but it was on my work computer, so probably ran into some proxy or firewall block of sorts that I couldn't get around. I could have tried installing it on my own computer or used Modular's Notebook if I just wanted to fiddle with it, but I wanted to create an automation project or feed it some heavy data to see what happened.
I don't get the hype about mojo * its not ready * its not opensource I'd prefer rust over mojo or rust/c-origin-programming language ffi python over mojo. The only selling point for mojo is to drag more ai/language model developer kind of people in a more performant environment (but there you already need to know, how safe programming and performance-stuff works ...and that goes around the selling-point itself). But hell ya, if this kinda works ...very skeptical, that its ecosystem/community can grow fast enough.
" its not ready" so? "its not opensource" so? "I'd prefer rust over mojo" rust is totally different than mojo. Dealing with borrow checker is hard and time-consuming. I think comparing mojo with rust, like ArjanCodes has done it, makes no sens. These langs have different purposes... "python over mojo" you don't understand that Mojo isn't against Python, but against C++.
@@gracjanchudziak4755 You didn't get a part of my comment right: (rust/c-origin-programming language ffi python) over mojo. Maybe I get the purpose of rust, but I don't get the purpose of mojo to do something additional or something better than yet established programming languages.
Aiming to be a Python superset is just a feature. The main goal of Mojo is to make it easy to compile code for non-CPU/GPU hardware. The selling point is that it will be very useful for building AI-related software to deploy in AI-custom hardware.
A variable has already mutability in the idea! Variable means it can change! If you don't want it to change, then call it a constant! This is a disservice Rust has done to the world of logic and language design.
I see your point, but in fp those are called variables because their values are not compile time constants. But I also would prefer 'const' over 'let' ;)
If the goal is to make it look like Python's syntax... ... the it should also look like it. E.g. these "fn" statements could easily be made into "def" statements! I think it will be these "small things" that will make it a success or not.
There is no need for Julia if Mojo gets to 1.0, you can use every Python Module in Mojo without any effort. The performance argument of julia is the only reason why Python devs would switch, which is no longer needed If Mojo arrives
Interesting stuff. Not in your case at all, but usually when I hear things like “python has bad performance or is inefficient,” it’s 99.9% of the time coupled with poorly written code, or being said by people who have no idea what they’re talking about. Not to say it isn’t true in some circumstances. The extra performance is there for the taking, but I hate that I feel the need to point out that simply using Mojo isn’t the same thing as writing faster core.
Thanks for this video Arjan, your up to date and bringing us the latest as ever. Some folks that did a lot of python went for go a bit ago now and perhaps some of that trend remains so I was interested to see what happens with mojo, however it perhaps being I believe less open ? When it first started out you could only run in a proprietary virtual environment so I wasn't too interested to spend time on it. Its looking like its a step further to running in your own tin now - thanks for showing us this intriguing demo. I still like go and can get a lot done with it so if I can't achieve performance I want in python and can get it done in go, its the path of least resistance for me so I tend to opt for that over rust as it has greater complexity and I know go now. If and when mojo becomes more stable and its use is more widespread over time it could become a contender in my way of thinking, rivalling both Go and Rust
First of all, if we're not talking about high-load microservices, Python is still one of the best solutions in terms of performance, if not the best. Secondly, it's not just about performance, but also about community, support, future proofing, and so on. Mojo might disappear because there's a simpler Python, a faster Golang, and a more flexible C group. Unfortunately, those 'new wave' languages won't be able to grab enough of the market to justify learning them.
@ArjanCodes, as always fantastic video with a nice clear way to follow along. It might have been nice to get some benchmarks about how much faster one can make a “complex” problem run, and maybe some ideas about interoperability
There is a real chance that python will be replaced by Mojo. There are so many projects which try to improve pyhton performance but nearly every project of those have a lot of limitations and are therefore often useless. Cython is the only useful way, but its a extra language to learn just to speed up the code. Mojo is the lang which every python programmer needs, barely new syntax but way better performance AND finally a real type system. It will be such a joy to use Mojo, hopefully it is 1.0 soon
So in that famous presentation, they benchmarked it against the hand-written python implementation of matrix multiplication. Nobody writes python like that in the real world. It's almost perfect glue language and you should use it as such - as bindings for battle-tested Fortran and C math libs. Yet people still claims that python is slow and it comes down mostly to 2 things: being bad dev (aka bootcamp Andy / react dev) or skill issue. For 99.9% of use cases, python is fast enough. And for the rest (eg low-latency HFT, embedded devices or some other mission-critical military grade software) you either use C/Cpp (maybe even Rust these days) or VHDL/Verilog (if you're coding algos directly for FPGAs).
They are marketing it as a "Python++" or "Python superset", which implies that any/99.9% Python code (starting from a `main` function...) is a valid Mojo code. But, in the 1st page of the documentation you also lean that for `def` function, arguments are sent by copy instead or reference. It means that any Python code using that behaviour (any serious project, if not all...) will be broken and have to be rewritten. It's like if C++ choosed to only implement reference but not pointers, or class but not struct, while still proudly calling itself a C superset. It's just stup^d. Wrapping all the scripts parts inside a `main` can be done quickly, but digging into all the logic of a program is much more complicate. Most project won't even try to switch. So for me, it's a big no. They are not building a Python superset but a kind of Rust with Python syntax. I just hope that this new competitor will motivate the Python ecosystem to build a modern decent JIT, taking advantage of type hints and llvm.
Earlier to learn a new language I needed to read a book. With your videos I don’t need it🙂 Keep it going. Looking forward to the video about coding in Apple Vision Pro
I didn't know that mojo was so much like rust!! Structs, traits, vectors... But now I'm a bit confused. I thought that the goal of mojo was to write code that is almost python but with a type safety layer. But if you have to learn new concepts like ownership, use structs and traits, then you're not writing python code at all! So why not use rust? It's got great interoperability with python Yes I'm confused and I don't really see the cases where mojo would make more sense than rust.
Mojo's main goal is to innovate on compiler technology (MLIR), particularly for AI-related hardware, not to be a type-safe superset of Python. They chose Python only because of its current dominance in machine learning.
Mojos selling point seems to be multiple features relating to the goal of 'make python _honestly_ parallel and concurrent for _massive_ speed gains'. Type checking and the psuedo borrow checker work towards that. Would love to have seen Arjan actually run the code, and maybe benchmark it Vs python and even Vs rust. Would likely need a more developed example to see the value though.
I’ve been using mojo for a few weeks now. It’s extremely underdeveloped. I personally don’t want to have to constantly revert back to python when mojo isn’t capable of things such as networking, sql, etc. the whole purpose of learning Mojo for me is to leave Python behind. Just as an example, you can’t perform terminal commands in mojo, you can’t even take in a user input without using Python. It’ll get there, but boy it’s just too underbaked at this point.
i don't think i ever worked in a python project that alowed me to be good to go just after installing python though, actually i find python to be even harder to setup than java.
Mine too. This sounds like almost the exact same pitch for Julia. I did give that one a whirl, but I still use Python. I keep meaning to go back and see if it's matured enough for me to realistically make the switch. It needed more native packages for the performance improvements to be noticeable. Looks like Mojo makes porting over from Python is almost just copy/paste which should speed up building a native ecosystem. If enough users adopt it, it could succeed where Julia seems to have stalled. But then again, Julia is an open source language developed and supported by MIT. Mojo, on the other hand is a 'proprietary' language... likely with a price tag/licensing subscriptions we'll have to shell out big bucks for. That sort of thing doesn't lend itself well to open source ecosystem building. Why should I make a package for free to expand the ecosystem for a proprietary language that could make the core developers mountains of money? That whole spirit of cooperation really goes out the window once you start having to pay monthly subscription fees.
*Python will be replaced? That would be great news,* it would make the world a much better place. *Python has only one advantage: there are great libraries. But the language, syntax and many concepts are just embarrassing and if you point this out to the architects, they argue with decades-old ideology* and they don't even understand the ingenious solutions of other programming languages to adapt them for Python and make the syntax better and the programs safer / more robust. *The nightmare of typical Python problems are, for example, the handling of properties and the overloading of methods. C#, for example, has solved these aspects brilliantly,* while the Python "solutions" not only look and feel like tinkering, they actually are. It feels like programming with a programming language that is decades old, that is not maintained and that blocks modern and great concepts.
The problem isn't the programming language. You can easily learn a new language. The real problem are the existing libraries. If this is trying to solve Python performance issue why just not try to fix python instead of creating new languages. That language is just another JavaScript.
It looks like they're trying to forcefully pull Python into another programming language and add some Rust features on top. Seems like they missed it big time on the elegance and readability features that make Python so popular. Speed alone is not enough.
If the first thing I need to do to use a new language is create an account somewhere I stop caring about how good the language is because I won't be using it anyway.
Mojo is going to be a super-set of Python. So, all the things that work in Python will work in Mojo as is at least that's the promise. So don't make any judgements right away.
Good to know this exist but wake me up when it passes production level test on one of major companies. For now it is one of many alternatives that you can learn and possibly end up never using it.
Mojo is open sourcing. Rust seems like a poor suggestion. If you are a "pythonista", then Mojo gives you a language which is a superset of Python, so you can be effective immediately. Trying to struggle learning rust, and fighting the borrow checker doesn't really gain you anything. I think Mojo is incredibly promising.
hmmm, i don't know, if i should like it. I do Python a lot, which i love and i do Rust, which i also love. Mojo seems kinda like an hybrid of those both. Mojo is based on borrowing and ownsership. And then there is Cython, which is fast as well. I think, i will stay away from Mojo.
No because np and pd are already in C/C++ underneath with just a slim layer of Python. To speed up Pandas, you need to use one of the multicore derivatives or Polars.
Sometimes, using the Numba JIT compiler @jit annotations within plain Python functions can outperform Numpy. Which is astonishing and makes you wonder what is the case for Mojo.
I think you are bit underestimating Mojo. It is far from a finished language for sure, but already in some benchmarks it is faster than C, Zig or Rust. It is also more memory efficient in the latest upgrade and seems to take almost no space on HDD. It's only gonna improve from there I'd suspect. Basically a perfect language for docker containers. We are talking here about like 50000x to 200000x speed increase over python, which is huge and they said they will support even GPUs over time (probably next update), so it's gonna get crazy. My theory is they want to slowly add and remove features till it will look just like a regular python code, but way faster, plus maybe add some unique features from Mojo superset syntax.
You said rust is an open language. It isn’t really, you can’t take its source code and compile it, except with another rust compiler. I forget who it was, maybe Kernighan, who laid out an evil compiler scheme that would look for patterns in code and produce evil programs, in arbitrarily specific circumstances. Anyway, good video.
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](http://i.ytimg.com/vi/MDblUyz0PtQ/mqdefault.jpg)
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
I didn't know that Jürgen Klopp taught Python and Software Engineering. This is amazing: Football & Python. The best.
A great video as usual, Arjan :) I think you missed one (the) major selling point of Mojo, which is the ability to write generic code and then compile it for specific hardware like GPUs or edge devices. It will mean a mojo/python dev can write highly optimised code without (re-)leaning low-level libraries/languages like Rust/C++/CUDA. I recommend people read about MLIR and MAX, from Modular - the creators of Mojo 🔥
Relearning? These devs mostly likely are already familiar with C++ enough. Python isn’t taking much to learn itself.
9:20 That's the best selling point for me, being able to selectively speed up code from within the mojo interpreter/JIT
To me the most compelling part of mojo is the promise that you'll be able to compile to various targets like wasm. Binaries under a mb would be awesome.
Could you make a video comparing Cython and Mojo?
Thanks.
Exactly what I wanted to ask !
The killer feature of mojo is that it is a python superset.
Moving from python to rust means a complete rewrite.
Moving from python to mojo hopefully means you can incrementally update your python to mojo in the performance critical pieces. But yeah it's new so we will have to wait and see how this all works out.
The best part, Python modules can be imported into Mojo right away. So piece by piece the codebase can be rewritten
That is an important point. It is one of the main reasons that languages like TypeScript, Swift, and Kotlin have really taken off in their respective platforms because they interop so well with what they are attempting to replace. TypeScript works well with JavaScript, Swift works well with Objective-C, Kotlin works well with Java.
Languages like Rust do get a lot of hype, but in reality most developers in their day jobs are not migrating their codebases to Rust. Something like TypeScript, Swift, or Kotlin is a much easier sell as you can do small incremental changes rather than just a complete rewrite. Unless you have a brand new project or performance is so critical that you need to migrate to something like Rust, then you won't get buy in from senior managers. However, that is not to disrespect Rust. I think it is great that we have a lower level systems language like Rust with the performance of something like C and C++ while also being safer and more approachable than C and C++.
You can also write Python interfaces to Rust binaries for performance critical parts. The python-mjml is a pretty basic example.
Like Cython ? @@MiesvanderLippe
Let me know in 3 years how you're getting on 🤣
There is no comparison to python (or to any other languages). Python is way to common today and will only get better. The great thing about all these new languages, is they can work with python. Good example is Microsoft investing in both python and Rust over C#. Its a tell tale Python and links to other languages is a better/smarter option.
Python broke backwards compatibility and abandoned their community and it still can't thread across cores. Python can get better? I doubt it. There's a reason why companies are investing hundreds of millions of dollars to create langauges that replace Python - it's because it's so fundamentally flawed that it can't be fixed. Nobody's spending $100 million dollars trying to fix Java, that's for sure.
Thats why Mojo is a superset. We need this for iOT devices that will embed AI models.
Nim is also a language "close" to Python. Compiled and very fast. Not the same interop as in Mojo, but there is a library for that.
I've found Nim to my liking, too. It is easy to learn when coming from C and Python. It has a consistent syntax that's easy on the eyes. And it has a well-reasoned set of features. Best of all (for me), it can target embedded microcontrollers (with and without MMUs).
And it compiles to Javascript and C/C++, so you can do back and frontend in Nim!
Mojo will generate GPU code, though.
@@russianbotfarm3036 yes but Mojo is proprietary p
@@russianbotfarm3036 A general purpose language for a math-focused coprocessor? Doesn't sound like the right tool for the job.
Eager to see this mature. Static typing and speed is all I want from Python.
Absolutely on point. Two more things that may have been worth mentioning in the video is that:
1. It is based on a MLIR infrastructure
2. It is a language created to solve a fundamental problem - writing performant AI/ML code with all debugging and profiling advantages all while staying within the same context of one programming language.
Yes but its important to say that Mojo is not limited by this, you can use it for everything since it will have direct python Support and therefore all the packages from python without zero costs
Python isn't going away anytime soon. Just too many users.
Well mojo is meant mainly for machine learning. For most cases, python will be just fine and used by most people. Not everyone need the extra performance.
It is not taking python users. It is converting them.
@@coenfuse I also don't understand the "Python isn't going away" argument. People actually mean CPython (so what about PyPy...). Who cares about the internal structure of Python, you care about the result. So if the results of Mojo and CPython code are identical, why use CPython?
That's why Mojo developers embraced the python ecosystem!
C++ is faster and has more followers than Python
Based on the title of the video, I anticipate it will demonstrate running Python code with Mojo to evaluate its performance speed.
The key selling point of Mojo is running Python code as is and you get 3 times faster than python, no modifications required.
There are other things that already do that. Just compiling Python or Cython itself.
Why did the TH-cam title say "The End of Python?" This is not the title that appears next, namely "Choosing your language...". Sensational titles like the first one make me click "Do not recommend". I just thought I'd share this because your video is good.
It seems Mojo runs Python "as is" three times faster!
That's nice for the users and also nice for our planet. The increase in speed typically comes from more efficient usuage of the CPU which directly means less energy consumption. Next to that 3x faster execution also means that (when thinking big) we only need a third of the physical hardware to run our software!
I also like the ideas of borrowing and traits from Rust. This will probably make it easier to move towards Rust in the future and gain another 25x performance increase.
I love it. I want more Mojo. In particular their abstraction for torch / tensorflow / onnx - we all know how br Arjan loves abstractions!
I've been watching mojo for a while now, exciting to see that it's progressed so far
Nice video, but I think you overlooked the must-show feature that is the performance comparison.
My two cents - I really dislike type hinting, there is a massive peer pressure for using them everywhere but they are in the end pointless because you can't actually depend on them (e.g. you can't always trust that a function will get an argument of a correct type just because you have provide a type hint). They don't actually improve your code only help you improve it and make it more readable just like docstrings but unlike docstrings clutter the code directly (which of course is a matter of preference). Mojo being strongly typed fixes that perfectly, the types finally do actually improve the code itself.
I'm normally against yet another language but there's something here that i think is crucial. The barrier to entry is so much lower because of the prevalence and simplicity of python. As an embedded C++ guy at heart who now is using python, i couldn't imagine trying to teach a junior C++ engineer these days, but this mojo looks achievable. Particularly if it's the juniors first introduction to strict typing.
> Couldn’t imagine teaching C++ these days
Word. I can’t keep up, myself.
C++ is not only being taught today, it has evolved into a very nice language, with C++17 onwards and QT Creator it just feels faster to develop and better documented than Python.
I know because I just did a couple of university projects in both, C++ and Python.
@@NicolayGiraldo I am not saying it doesn't happen (I teach C++ myself, but not at work.) It's very different writing a C++ project for yourself and by yourself, vs in a team where, if you have a coding standards doc, there is constant argument about the readability vs benefit of qualifiers, for example. It's a very different environment in a workplace where everything has to be done yesterday; complexity and nuance is avoided because it takes too long to do in normal workflow, let along teach a young dev or apprentice, when compared to Python. Hope that makes a bit of sense!
Go is both simple, and performant though. Obviously it's not as fast as Mojo is, but why does it need to be?
@@justsomeguy8385 I think you replied in the wrong thread :)
why 'let' for constant types and not 'const'
yeah that is some major oversight from the Mojo team...I would reassign the keyword right away if I'm using Mojo.
We can reassign keywords in Mojo, correct? just like we can in Python.
after some thoughts, like Arjan mentioned in the video that Mojo draws inspiration from Rust.
in Rust the way we write mutable variable is by using 'let mut', and just 'let' for immutable variable.
i think that's why they went with let for constant / immutable.
I really wish there is some typedef or something like that. I'd rename 'let' to 'const' right away
@@pietraderdetective8953 yeah, makes sense
Rust influence
let keyword will be removed from Mojo ;)
Needs to be mentioned that "owned" doesn't necessary means that the caller transfers ownership, just that you're guaranteed to own what you receive. There is a difference here, a value can be passed to an owned argument without transferring ownership, in that case a copy is created.
Great video. I like how you can explicitly declare the ownership of arguments. Can't wait for version 1.0
Glad you enjoyed the video, Kevin!
This video is awesome! I have had so many questions about this without good answers so far. Thanks!
Glad the video was helpful! :)
As fas as I understood, the main issue of integrating Python with C (I don't know if it is the same with Rust) is debugging. Switching context makes debugging troublesome. Mojo, which is not subject to context switching, should solve the issue. It's extremely interesting, but I found it closer to C or Rust than to Python. The performance, however, seems astonishing.
Keeping track of reference counts, too. Though things like Cython and some others will let you do that automatically.
Mojo literaly looks like python with types and Rust have a baby. Really interesting
I use go. I think it's quite good combination Python + Go in microservices world.
Nice video, Cython also is Python superset and compiled, with C/C++ extensions
Does not work well with 3rd party modules like pywidget, etc.
Yeah, Python ecosystem is a complete and total mess with all these incompatible projects that fix things that Python can't fix. Glad finally someone will fix Python for good and finally replace it with something that can thread across cores. RIP Python.
For scientific problems, try Julia. It is very good.
I like this video! It would be really cool, if you would come back to Mojo in the future to recap what has changed. :)
Mojo has much more really cool features not mentioned here. Eg. whole metaprogramming at compile time (like Zig), where you could compute data during compilation. Another feature is related to having control over different optimizations like unrolling, passing directly via registers, passing by reference, inlining and much more ;)
Also I agree, that at this stage it is still beta. Much more in terms of stability and usability will come in the future 😊
I think this ownership feature would require additional explanatory video with a lot of examples because it's quite exceptional. I've seen some programming languages so far, but this ownership thing doesn't look similar to anything I've seen before, and therefore it might be as well confusing for people using only Python and not having too much experience with other languages.
Also, choosing "let" for constant values doesn't seem the best option. Why not explicitly call it "const"? That would be perfectly coherent with variables being initialized with "var" keyword: variables go with "var", constants with "const".
And why structs has to be decorated? It would make more sense if structs were by default value types instead of classes being reference types, as it is the case in e.g. C#. Unless the creators of Mojo want to keep class as pure Python object and structs as pure Mojo objects and there will be another decorator to make structs type-static reference types. Then it would make sense to me.
As for "DynamicVector", why not simply call it "List" with capital "L"? Mojo is building on top of Python, so this is similar situation as with C# and C++, and in C# there are C# versions of C++ objects, e.g. String vs string. Well, actually they are aliases, so there is no real difference, but the naming could be used as an example for new types in Mojo. If "DynamicVector" is supposed to be type-static version of Python lists, then naming it with that longer name is not the best decision. A good programming language has short but comprehensive names. If there's a need to make a distinction between dynamic and static collections, there is a list vs. array distinction. And actually they are both vectors, but "list" and "array" are shorter names than "vector" and I'd even say more common.
And why a struct needs to inherit from CollectionElement to be a collection element? What's the benefit of implicitly not inheriting that? Why a struct has to be made special first before we can put in a collection? Really, it's very easy to make a new programming language cluttered and verbose with types, keywords, the necessity of writing a ton of code to perform a simple task. But a real art is to make it short and comprehensible, and this the general direction all programming languages are evolving to right now. So, I cannot understand why Mojo is going to be imperfect from the very beginning. Maybe they really want to go Python way and create Mojo 3 at some point loosely compatible with Mojo 2...
Ownership is the superpower of Rust. It is not trivial to grasp, esp. in larger projects. I don't think it is a good fit for the existing Python community. It isn't Python's garbage collector which makes the language slow, not at all.
Thanks!
Thank you for the support, Rick!
Have a performance problem first, which cannot be solved within python. Most of the performance issues are language independent.
Until then the robustness and ecosystem of a mature language like python is superior.
Sweet! Thank you for the rundown and for sharing this superb language. I prefer type safety over how Python allows reassignment to a different type, which can lead to issues. Of course, I also like templates that process generic types, like in C++, but I enjoy writing less code to get something done more, so I've only spent a little time in C++ or learning the standard template library. It makes my head hurt. LOL! I must have missed your introduction to Mojo, but I will look at it now; thanks again!
if you like templates, you'll be happy to know that python 3.12 adds them!
have I overlooked something like "time mojo script.mojo" vs. "time python3 script.py"?
If PyTorch and TensorFlow is already mostly based on C (??) how does Mojo speed anything up?
So im simply thinking: Im a machine learning engineer with python, yet i also learnt a clean, performance oriented way of computation via c++ for the means of parallel programming and working with cuda.
I also know of the python library Numba, which seeks to increase performance by optimizing certain computations, where nowadays there is hardware available that python just does not take account of at the moment.
Mojo seems to promise both of the advantages: a) allow me to code close(r) to the hardware, using the principles of parallel programming whilst still b) allowing me to remain in python and using jit compiled code for my tutorials and playing with the code. Latter is very important to me, becuase that is basically how i do datascience.
Numba does jit, Mojo does not, it is plain LLVM. And then there is JAX, also using a jit and able to make use of CUDA etc. Numba and JAX have a high chance to actually outperform Mojo. JITs are awesome. Java often outperforms C because of its amazing JIT. Moreover, Numba supports true explicit multithreading from within Python.
@@falklumoWrong, Wrong and Wrong. Why should someone use thousand of tools to speedup code. That introduces a Lot of dependencies for a project. In Mojo you have every python package for free with better performance in EVERY case and not just in certain cases like Numba. You simply switch your file names to mojo and you are done. Why do you defend python so much, it literaly makes no sense in this case. Mojo is Python + Rust, best of both worlds.
@@ITSecNEO I don't defend Python, I actually think it was a historic mistake. However, this does not make me think that forging a GC language and a Borrowing language into one is a great idea either ;)
@@falklumo Name your reasons then. Simple Syntax from python and safety and speed guarantees from Rust.
@@ITSecNEO The Rust memory model requires discipline and experience. It is safe but adds a similar level of complexity to software projects as do pointers in C. I know Python programmers and most of them would not be capable to cope with it. Python projects most of the time are toy level projects only.
Serious projects can be written in Mojo (some day), right. But all appropriate programmers I know of actually hate the syntax of Python and idiosyncrasies like True + False etc. They want hierarchical type systems which support refactoring.
There is Rust which is great for systems programming. And there is Python which some day will become a grown up language with a GC, no GIL, a full type system, a true JIT and fast execution. But they won't merge. Their intersection aka Mojo is empty.
P.S. If you wonder. I believe the most grown up language today is Kotlin (although I don't use it that often actually).
Python is one of the out-of-the-box supported languages for AWS lambdas, so it's going to be there for a very long time
Mojo is here to make it so.
Which keyboard are you using?
it for sure is a Keychron, i am not sure which model though - they have dozens.
Mojo remains Rust, but simpler.
I can't wait for a version 1
Mojo got me very excited. I wanted to try it out but had too much trouble installing it on Windows and eventually gave up. Truth is, I haven't done anything so far that Python couldn't keep up with. Python is strong because it's accessible, versatile, quick to deploy, and has at least a couple of libraries to choose from for any particular task you need. I believe that's what Mojo is going for, but still has a long way to go.
"Wanted to try" xD Thats the problem, you didnt even try Mojo but you claim things about Mojo which are wrong. Mojo is a Python superset, search this term up and you will understand that every statement from you about python also holds for Mojo
@@ITSecNEO They want it to be a Python superset. But at least according to the docs things aren't that smooth yet. There's no guarantee that every Python library will work, for example. There are other things in progress that I read on their website but don't remember the details right now.
That's my experience. I spent a few hours trying to install it and eventually gave up. I'll just wait for further development because I've still got a ways to go with regular Python and will just focus on it right now.
If you've actually tried Mojo and want to share your experience you're more than welcome to do so.
@@luisgentil Have you tried to install it via WSL? There is no official windows support at the moment.
And yes, at the moment its not a superset, but it will be. Its not 1.0 yet, so we need to wait. For now, you should focus on python. With a strong understanding of python it will be very easy for you to learn Mojo once it reaches 1.0
@@ITSecNEO I've tried with WSL, but it was on my work computer, so probably ran into some proxy or firewall block of sorts that I couldn't get around. I could have tried installing it on my own computer or used Modular's Notebook if I just wanted to fiddle with it, but I wanted to create an automation project or feed it some heavy data to see what happened.
I don't get the hype about mojo
* its not ready
* its not opensource
I'd prefer rust over mojo or rust/c-origin-programming language ffi python over mojo.
The only selling point for mojo is to drag more ai/language model developer kind of people in a more performant environment (but there you already need to know, how safe programming and performance-stuff works ...and that goes around the selling-point itself). But hell ya, if this kinda works ...very skeptical, that its ecosystem/community can grow fast enough.
" its not ready" so?
"its not opensource" so?
"I'd prefer rust over mojo" rust is totally different than mojo. Dealing with borrow checker is hard and time-consuming. I think comparing mojo with rust, like ArjanCodes has done it, makes no sens. These langs have different purposes...
"python over mojo" you don't understand that Mojo isn't against Python, but against C++.
@@gracjanchudziak4755 You didn't get a part of my comment right:
(rust/c-origin-programming language ffi python) over mojo.
Maybe I get the purpose of rust, but I don't get the purpose of mojo to do something additional or something better than yet established programming languages.
@@gracjanchudziak4755 Just as an example: polars + python. Works great.
I feel the same as @michaelmueller9635
Aiming to be a Python superset is just a feature. The main goal of Mojo is to make it easy to compile code for non-CPU/GPU hardware. The selling point is that it will be very useful for building AI-related software to deploy in AI-custom hardware.
@ArjanCodes, could you do a similar video about PyPy ?
A variable has already mutability in the idea! Variable means it can change! If you don't want it to change, then call it a constant!
This is a disservice Rust has done to the world of logic and language design.
I see your point, but in fp those are called variables because their values are not compile time constants. But I also would prefer 'const' over 'let' ;)
"Is this MMO the WoW Killer?" vibes
Thanks, you are so good giving explanations!! continue!
Thank you! Will do!
Mojo for python is like typescript for javascript but difference is mojo has compiler while typescript has transpiler
If the goal is to make it look like Python's syntax...
... the it should also look like it.
E.g. these "fn" statements could easily be made into "def" statements!
I think it will be these "small things" that will make it a success or not.
Julia is also a wonderful language as well, though it doesn't have the OO element.
There is no need for Julia if Mojo gets to 1.0, you can use every Python Module in Mojo without any effort. The performance argument of julia is the only reason why Python devs would switch, which is no longer needed If Mojo arrives
@@ITSecNEO Very true. The only downside of python is its speed.
Interesting stuff. Not in your case at all, but usually when I hear things like “python has bad performance or is inefficient,” it’s 99.9% of the time coupled with poorly written code, or being said by people who have no idea what they’re talking about.
Not to say it isn’t true in some circumstances. The extra performance is there for the taking, but I hate that I feel the need to point out that simply using Mojo isn’t the same thing as writing faster core.
Thanks for this video Arjan, your up to date and bringing us the latest as ever.
Some folks that did a lot of python went for go a bit ago now and perhaps some of that trend remains so I was interested to see what happens with mojo, however it perhaps being I believe less open ? When it first started out you could only run in a proprietary virtual environment so I wasn't too interested to spend time on it. Its looking like its a step further to running in your own tin now - thanks for showing us this intriguing demo.
I still like go and can get a lot done with it so if I can't achieve performance I want in python and can get it done in go, its the path of least resistance for me so I tend to opt for that over rust as it has greater complexity and I know go now.
If and when mojo becomes more stable and its use is more widespread over time it could become a contender in my way of thinking, rivalling both Go and Rust
Oh I get it.
Chris Lattner: I want rust to look and feel like python
Which is a very good approach
@@ITSecNEOExactly
First of all, if we're not talking about high-load microservices, Python is still one of the best solutions in terms of performance, if not the best. Secondly, it's not just about performance, but also about community, support, future proofing, and so on. Mojo might disappear because there's a simpler Python, a faster Golang, and a more flexible C group. Unfortunately, those 'new wave' languages won't be able to grab enough of the market to justify learning them.
Can you run django and scipy in mojo?
@ArjanCodes, as always fantastic video with a nice clear way to follow along. It might have been nice to get some benchmarks about how much faster one can make a “complex” problem run, and maybe some ideas about interoperability
There is a real chance that python will be replaced by Mojo. There are so many projects which try to improve pyhton performance but nearly every project of those have a lot of limitations and are therefore often useless. Cython is the only useful way, but its a extra language to learn just to speed up the code. Mojo is the lang which every python programmer needs, barely new syntax but way better performance AND finally a real type system. It will be such a joy to use Mojo, hopefully it is 1.0 soon
So in that famous presentation, they benchmarked it against the hand-written python implementation of matrix multiplication. Nobody writes python like that in the real world. It's almost perfect glue language and you should use it as such - as bindings for battle-tested Fortran and C math libs.
Yet people still claims that python is slow and it comes down mostly to 2 things: being bad dev (aka bootcamp Andy / react dev) or skill issue. For 99.9% of use cases, python is fast enough. And for the rest (eg low-latency HFT, embedded devices or some other mission-critical military grade software) you either use C/Cpp (maybe even Rust these days) or VHDL/Verilog (if you're coding algos directly for FPGAs).
They are marketing it as a "Python++" or "Python superset", which implies that any/99.9% Python code (starting from a `main` function...) is a valid Mojo code. But, in the 1st page of the documentation you also lean that for `def` function, arguments are sent by copy instead or reference. It means that any Python code using that behaviour (any serious project, if not all...) will be broken and have to be rewritten. It's like if C++ choosed to only implement reference but not pointers, or class but not struct, while still proudly calling itself a C superset. It's just stup^d.
Wrapping all the scripts parts inside a `main` can be done quickly, but digging into all the logic of a program is much more complicate. Most project won't even try to switch.
So for me, it's a big no. They are not building a Python superset but a kind of Rust with Python syntax. I just hope that this new competitor will motivate the Python ecosystem to build a modern decent JIT, taking advantage of type hints and llvm.
looking like python or sounding like python is good enough? or all the python libraries are supported as well?
You’d have to use Python libraires in a try / catch.
When I'm using Python, I always think that if you were to build a modern language for computing, you wouldn't start from here.
Why does it need python ? It almost looks like its interpreting the python code still ?
With compiled you mean 'compiled to machinecode', I presume? Python is compiled too, but to bytecode (like Java).
Correct!
Earlier to learn a new language I needed to read a book. With your videos I don’t need it🙂 Keep it going. Looking forward to the video about coding in Apple Vision Pro
I didn't know that mojo was so much like rust!! Structs, traits, vectors...
But now I'm a bit confused. I thought that the goal of mojo was to write code that is almost python but with a type safety layer. But if you have to learn new concepts like ownership, use structs and traits, then you're not writing python code at all! So why not use rust? It's got great interoperability with python
Yes I'm confused and I don't really see the cases where mojo would make more sense than rust.
Mojo's main goal is to innovate on compiler technology (MLIR), particularly for AI-related hardware, not to be a type-safe superset of Python. They chose Python only because of its current dominance in machine learning.
Mojos selling point seems to be multiple features relating to the goal of 'make python _honestly_ parallel and concurrent for _massive_ speed gains'. Type checking and the psuedo borrow checker work towards that. Would love to have seen Arjan actually run the code, and maybe benchmark it Vs python and even Vs rust. Would likely need a more developed example to see the value though.
What about Julia, Nim or Zig?
Why doesn't mojo just implement a default try except structure at next lower lever if the programmer doesn't provide one?
The great problem with Mojo is that is not open source, there is too much risk in betting on a language that not guarantees something so basic.
If you need more performance, just write assembly 😏.....
"Rust" is named as a main reason for creating Mojo.
I personally think that it is the success of Julia...
What about Julia language?
Julia is pretty good but this one is an almost 100% compatible with Python code.
I’ve been using mojo for a few weeks now. It’s extremely underdeveloped. I personally don’t want to have to constantly revert back to python when mojo isn’t capable of things such as networking, sql, etc. the whole purpose of learning Mojo for me is to leave Python behind. Just as an example, you can’t perform terminal commands in mojo, you can’t even take in a user input without using Python. It’ll get there, but boy it’s just too underbaked at this point.
i don't think i ever worked in a python project that alowed me to be good to go just after installing python though, actually i find python to be even harder to setup than java.
11:59 yeah mojo would be too risky for my mission critical pet project
Why not use Julia?
EXACTLY my thought!
Mine too. This sounds like almost the exact same pitch for Julia. I did give that one a whirl, but I still use Python. I keep meaning to go back and see if it's matured enough for me to realistically make the switch. It needed more native packages for the performance improvements to be noticeable.
Looks like Mojo makes porting over from Python is almost just copy/paste which should speed up building a native ecosystem. If enough users adopt it, it could succeed where Julia seems to have stalled.
But then again, Julia is an open source language developed and supported by MIT. Mojo, on the other hand is a 'proprietary' language... likely with a price tag/licensing subscriptions we'll have to shell out big bucks for. That sort of thing doesn't lend itself well to open source ecosystem building. Why should I make a package for free to expand the ecosystem for a proprietary language that could make the core developers mountains of money? That whole spirit of cooperation really goes out the window once you start having to pay monthly subscription fees.
*Python will be replaced? That would be great news,* it would make the world a much better place. *Python has only one advantage: there are great libraries. But the language, syntax and many concepts are just embarrassing and if you point this out to the architects, they argue with decades-old ideology* and they don't even understand the ingenious solutions of other programming languages to adapt them for Python and make the syntax better and the programs safer / more robust. *The nightmare of typical Python problems are, for example, the handling of properties and the overloading of methods. C#, for example, has solved these aspects brilliantly,* while the Python "solutions" not only look and feel like tinkering, they actually are. It feels like programming with a programming language that is decades old, that is not maintained and that blocks modern and great concepts.
The problem isn't the programming language. You can easily learn a new language. The real problem are the existing libraries. If this is trying to solve Python performance issue why just not try to fix python instead of creating new languages. That language is just another JavaScript.
It looks like they're trying to forcefully pull Python into another programming language and add some Rust features on top.
Seems like they missed it big time on the elegance and readability features that make Python so popular. Speed alone is not enough.
If the first thing I need to do to use a new language is create an account somewhere I stop caring about how good the language is because I won't be using it anyway.
Pls, take into account, how 3rd party modules e.g. ui,numpy,etc. Are working with.
if you gonna learn a new programming language in 2023 it should be GO or RUST, period
Or just compile the computationally intensive parts using C or cython?
You can.
But why not have a faster language by default? ;-)
Interesting which will prevail - Nim or Mojo.
nim is, and has been, a legit language for years already, Mojo at the minute is just a cool idea
Why not Zig ?
What is about zig?
Mojo is going to be a super-set of Python. So, all the things that work in Python will work in Mojo as is at least that's the promise. So don't make any judgements right away.
If there's ever a book for Mojo, it should contain Powerpuff girls references, like Python does Monty Python.
Or Austin Powers'
@@MrBiTsTheReal Oh behave!
@@MrWorshipMe Groove, Babe!
Good to know this exist but wake me up when it passes production level test on one of major companies. For now it is one of many alternatives that you can learn and possibly end up never using it.
But Julia already exists
True
Mojo is open sourcing. Rust seems like a poor suggestion. If you are a "pythonista", then Mojo gives you a language which is a superset of Python, so you can be effective immediately. Trying to struggle learning rust, and fighting the borrow checker doesn't really gain you anything. I think Mojo is incredibly promising.
I'll keep using python for now. Mojo seems too immature, at least currently. We shall see how it goes in the future.
hmmm, i don't know, if i should like it. I do Python a lot, which i love and i do Rust, which i also love. Mojo seems kinda like an hybrid of those both. Mojo is based on borrowing and ownsership. And then there is Cython, which is fast as well. I think, i will stay away from Mojo.
There is something UI Tauri-Rust library similar for design interfaces with Mojo?
This would be awesome! But PyQt works very well for ui.
So basically blazing fast python that is also able to leverage ai hardware? a very ambitious project.
I do wonder why there isn’t a compiler for Python.
does it speed up tools like numpy and pandas , i can see some real advantages with the additional performance there :)
No because np and pd are already in C/C++ underneath with just a slim layer of Python. To speed up Pandas, you need to use one of the multicore derivatives or Polars.
@@incremental_failure Good point but i have seen rust outperform C/C++ for instance rust security scanners are much faster than their C/C++ parents
Sometimes, using the Numba JIT compiler @jit annotations within plain Python functions can outperform Numpy. Which is astonishing and makes you wonder what is the case for Mojo.
@@falklumo Numba can only support a few types. It's a great tool and I depend on it but it cannot be used widely.
@@falklumo Great point
When are they going to have a real version for Windows?
I think you are bit underestimating Mojo. It is far from a finished language for sure, but already in some benchmarks it is faster than C, Zig or Rust. It is also more memory efficient in the latest upgrade and seems to take almost no space on HDD. It's only gonna improve from there I'd suspect. Basically a perfect language for docker containers. We are talking here about like 50000x to 200000x speed increase over python, which is huge and they said they will support even GPUs over time (probably next update), so it's gonna get crazy. My theory is they want to slowly add and remove features till it will look just like a regular python code, but way faster, plus maybe add some unique features from Mojo superset syntax.
Seems like Mojo is to Python what Typescript is to Javascript
not at all. NOT at all. :)
So the Struct in Mojo is somewhat similar with Struct in Go?
You said rust is an open language. It isn’t really, you can’t take its source code and compile it, except with another rust compiler. I forget who it was, maybe Kernighan, who laid out an evil compiler scheme that would look for patterns in code and produce evil programs, in arbitrarily specific circumstances.
Anyway, good video.