Three thoughts. 1. Mojo looks like it will be simpler to learn than Rust. Rust is quite straight forward until you get into some of the funky memory objects like Box, Rc, and RefCell when it becomes quite difficult. 2. Mojo looks like it will become a lot more performant than Rust. 3. For people do machine learning, Mojo may become what they use when they need performance. Data scientists are used to Python, so a Python superset looks like an easy transition.
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 🔥
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++.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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.
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.
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.
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!
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).
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.
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.
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.
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 😊
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.
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 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.
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!
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' ;)
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.
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.
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.
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
@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
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.
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).
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.
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.
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
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
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.
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.
If you are looking for type safety and performance wouldn't it be better to use a complied well established language like GoLang? Much of what you were demonstrating in Mojo looked so much like code in GoLang.
What is the objective ? Managing, Manipulating and Retrieving data or something else ? If that is the objective I think we are undervaluing the ability to manipulate databases like a Ninja. If we could use the defaultdict and Benedict libraries in python to inforce assigned indexes to any and all args and variables within a code block I think you could have infinite Syntactic Sugar with minimal redundancy. Just thinking out loud. Would love to hear any challenges to this brain dump exposure of thought.
What's going on? When I finished learning Java, I was encouraged to learn Python. Now that I spent a lot of time learning Python, you are telling us that Python might die. Well, luckily, I'm a guru in C++ and C#, and they keep me busy.
i dont see the benefits of mojo over numba. especially since numba is already stable. i admit its not all that well documented but once you figure it out its epic.
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.
💡 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.
Three thoughts.
1. Mojo looks like it will be simpler to learn than Rust. Rust is quite straight forward until you get into some of the funky memory objects like Box, Rc, and RefCell when it becomes quite difficult.
2. Mojo looks like it will become a lot more performant than Rust.
3. For people do machine learning, Mojo may become what they use when they need performance. Data scientists are used to Python, so a Python superset looks like an easy transition.
9:20 That's the best selling point for me, being able to selectively speed up code from within the mojo interpreter/JIT
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.
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 🤣
Could you make a video comparing Cython and Mojo?
Thanks.
Exactly what I wanted to ask !
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 ;)
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.
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.
Thanks!
Thank you for the support, Rick!
If PyTorch and TensorFlow is already mostly based on C (??) how does Mojo speed anything up?
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.
Eager to see this mature. Static typing and speed is all I want from Python.
Why doesn't mojo just implement a default try except structure at next lower lever if the programmer doesn't provide one?
have I overlooked something like "time mojo script.mojo" vs. "time python3 script.py"?
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.
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.
Can you run django and scipy in mojo?
What about Julia, Nim or Zig?
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.
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
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
Why does it need python ? It almost looks like its interpreting the python code still ?
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
This video is awesome! I have had so many questions about this without good answers so far. Thanks!
Glad the video was helpful! :)
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.
Which keyboard are you using?
it for sure is a Keychron, i am not sure which model though - they have dozens.
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.
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.
With compiled you mean 'compiled to machinecode', I presume? Python is compiled too, but to bytecode (like Java).
Correct!
What about Julia language?
Julia is pretty good but this one is an almost 100% compatible with Python code.
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.
Thanks, you are so good giving explanations!! continue!
Thank you! Will do!
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 :)
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).
@ArjanCodes, could you do a similar video about PyPy ?
Or just compile the computationally intensive parts using C or cython?
You can.
But why not have a faster language by default? ;-)
What is about zig?
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
I use go. I think it's quite good combination Python + Go in microservices world.
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!
I've been watching mojo for a while now, exciting to see that it's progressed so far
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.
For scientific problems, try Julia. It is very good.
There is something UI Tauri-Rust library similar for design interfaces with Mojo?
This would be awesome! But PyQt works very well for ui.
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.
Why not Zig ?
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 😊
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.
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.
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.
I do wonder why there isn’t a compiler for Python.
I'm not a fan of using the colon to declare types in functions when they are required, seems redundant.
Didn't realise it was keeping compatibility with Python when I wrote this
Pls, take into account, how 3rd party modules e.g. ui,numpy,etc. Are working with.
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!
I love it. I want more Mojo. In particular their abstraction for torch / tensorflow / onnx - we all know how br Arjan loves abstractions!
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' ;)
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.
"Is this MMO the WoW Killer?" vibes
When are they going to have a real version for Windows?
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.
Mojo remains Rust, but simpler.
So the Struct in Mojo is somewhat similar with Struct in Go?
where is the source code?
Why do I feel like the syntax is harder than Python?
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.
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.
@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
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.
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.
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).
Mojo for python is like typescript for javascript but difference is mojo has compiler while typescript has transpiler
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.
Oh I get it.
Chris Lattner: I want rust to look and feel like python
Which is a very good approach
@@ITSecNEOExactly
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
I can't wait for a version 1
Years ago, I was so excited about pypy. Now they are sort of struggling. I wish mojo good luck.
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.
11:59 yeah mojo would be too risky for my mission critical pet project
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.
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
But Julia already exists
True
No just has basic not even list comprehensions classes etc I have been looking at it since last year, not even close python
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
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.
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.
If you need more performance, just write assembly 😏.....
If you are looking for type safety and performance wouldn't it be better to use a complied well established language like GoLang? Much of what you were demonstrating in Mojo looked so much like code in GoLang.
Can you import pytorch in Go?
@@mk-ck8or that's interesting, but I guess using mojo for your app will have only little benefit if pytorch is not "compatible" with mojo.
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!
What is the objective ? Managing, Manipulating and Retrieving data or something else ? If that is the objective I think we are undervaluing the ability to manipulate databases like a Ninja. If we could use the defaultdict and Benedict libraries in python to inforce assigned indexes to any and all args and variables within a code block I think you could have infinite Syntactic Sugar with minimal redundancy.
Just thinking out loud.
Would love to hear any challenges to this brain dump exposure of thought.
What's going on? When I finished learning Java, I was encouraged to learn Python. Now that I spent a lot of time learning Python, you are telling us that Python might die. Well, luckily, I'm a guru in C++ and C#, and they keep me busy.
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.
i dont see the benefits of mojo over numba. especially since numba is already stable. i admit its not all that well documented but once you figure it out its epic.
I thought the only difference with python is that mojo is compiled but there are syntax differences. Better learn V.
"Rust" is named as a main reason for creating Mojo.
I personally think that it is the success of Julia...
So basically blazing fast python that is also able to leverage ai hardware? a very ambitious project.
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.