I love seeing better numpy support. Would be even nicer to have native numpy to Mojo Array conversion initializers to operate with pure Mojo instead of a python mixture.
First, THANK YOU for this presentation, and most of all, THE HARD WORK & DEDICATION of CHRIS LATTNER and the MOJO Team for developing this language! QUESTION: Can MOJO code be used within existing Python frameworks such as 1) DJANGO, and 2) FASTAPI? If so, would using MOJO in those frameworks, speed up the performance, and memory-efficiency of websites built with MOJO + Existing Frameworks?
The long-term goal is for Mojo to be a superset of Python. This involves supporting raw Python, but I don't think they are focussing on solving the "packaging problem" (a quite difficult one), so I imagine it would be quite some time until that occurs. Most web and dispatching frameworks are quite efficient, so it's more likely that Mojo could help with small jobs as apart of the projects if that makes sense. For instance, I run a Flask backend, and Mojo could absolutely help in the raw Python data analysis and analytics that occurs in the backend.
While Python web frameworks are generally "fast enough" for most web applications (they are bound by IO internet speed, not by computational requirements), there are scenarios where the choice of language and framework can be a bottleneck. Real-time applications, high-frequency trading platforms, or apps with complex data processing requirements might benefit from the speed advantages offered by compiled languages. Like @jackhales6179 said, in these cases you can still call compiled mojo code from an existing python framework, but depending on how seamless the interoperability is, you might just be better off selecting a mojo specific web framework than trying to mash two systems together.
Example code on the website sometimes have timings for how fast things get done. But this is less meaningful when the hardware is unspecified. Such and such milliseconds on what platform--CPU, clock speed, RAM speed, etc. Eventually, you should have integrated into the timing functions something that does a platforming ID of what hardware is running. How you might do this should be up to someone working with the bare metal to know how to ID such things.
Hi, everyone, excellent presentation. If I may digress for a moment(to talk about "Hardware"), when do you anticipate having a framework/compiler available for single-board computers, such as Raspberry Pi, or microcontrollers? Presently, platforms like Arduino utilize C++, and even MicroPython is built on C libraries.
Chris mentioned how mojo is different from CPP, but all this problem are already being solved by RUST, only difference I can see they RUST don't have Access SMID instructions, if that is true then why again a new Lang. They already mentioned the it is for AI, Does it going remove all the dependency of cuda, Does allow to write parallel programmes for general purpose GPU ??? . If not then why a new Lang ?? If yes then rust can also do it, Another point even though it is handshaking with python, we all know if Mojo became popular, then most existing python ml/ai library will be rewritten in mojo ???
I just hope Mojo will have all of the most innovative modern features that it can have, like the futuristic package manager cargo from Rust, where you only write packages you want in VSCode and it will auto install or auto remove them. Much better than always doing pip install or pnpm install imo. And ideally, it should be even more futuristic, it should have an AI model inside that would be able to tell which package you are likely missing or needing and it would recommend you / maybe auto install + auto import the libraries. Now that I think about it, maybe I want too much lol. Speeding up all the python libraries will be more than enough.
