I think this is where Mojo comes into play
Its not there yet BUT its a fully compiled superset of Python
The point is: it’s not there. And it will cost also time until it’s there. And even then: the needed ecosystem has to be builded up. Not everything of Python will be included in the compiler. So it will be also complex for the ecosystem. Can be a good alternative for production. When it is ready. But now: it is not, has no infrastructure und is missing lots of functionality.
YET
Their team IS several of the guys that made LLVM with Chris Lattner so I expect it will get there
Mojo IS a proper superset of Python
If its in Python its IN Mojo
Thats IS the entire point for Mojo - they dont want you to have to do “something special if you use Mojo because its NOT python”
If it works in Python it will work in Mojo
At least that is their stated goal
And, given the teams behind it, I expect they’ll be successful
But there is no public releases - YET
What they have now is not the entire python cause it can’t import all libs and so on
Thanks, Barry. Very impressive.
As I said earlier, it is also reassuring that you take your roadmap seriously and actually execute on it.
I think in the v10 or v11 time frame when you have your C# integration in place and I expect to have some free time, I will definitely take a closer look.
Why I said “its not there YET”
its a work in progress
its not very old at all
They just became public 10 days ago after working in silence for 16 months
Heres the PUBLIC launch video https://www.youtube.com/watch?v=-3Kf2ZZU-dg
The demo is particularly interesting because its NOT your usual made for the launch demo
Anyhow it will be ready one day. As far as I am awaiting it will be a good alternative. A few things I am not aware of for example thread Management in Java isbnow inside the jvm and I can say it is blazing Performant. Ython but also c,c++,c# and many more have no thread Management like that. It makes it really nice when opening many threads in the same time while java then optimizes them all. Something like that I hope they also will integrate into a compiler solution.
The needed ecosystem for mobile and web and desktop has to be builded up but … Hey Python is a neat language. It has the potential to bring programming closer to people. And within that also it can help citizen programmers to write good and reliable software cause python language is fast to learn and has a simple syntax.
If it will be the block buster and beam all others away I do not believe while python needs after having the compiler for example the missed optimization for databases and so on. But okay also here we speak about Xojo or similar as the example system and python is even now faster with db access than Xojo even with mbs connectors.
And not everybody needs the full performance. It is something coming up in future.
Mojo has ambitious goals - no doubt
A read of their docs and watching the various videos they have is quite interesting
Its far too early to say for sure they will make all those plans come to pass but they have a good team which inspires a certain level of confidence
Time will tell
Yes. But it is not now the time to place mojo as alternative to python itself. It will following to the developers not be a complete Python replacement. And Mojo isn’t a Python Compiler but a programming language using Python syntax and language Elements. That also means:it behaves different.
Also: not in all cases it will be as fast as C++. many questions and no answers. The time will tell. And so I am at the point of the beginning of the mojo discussion: it is - today and in the foreseeable future - not and will not be a replacement for C++, Java and C.
Also it will not have in a short time a usable Desktop ecosystem. It has not now and not in foreseeable future. That makes it probably to a neat server language. Or for Command Line Services. But not für Desktop Applications or mobile Applications.
And yes, I am aware of the possible combination with JavaScript for the UI. but I am also aware that it is and will always be: a not secure and not performant Desktop or Mobile UI solution. So we will have to wait.
Will it be a python replacement ?
Perhaps eventually - but not today
Replacement for C, C++ Java ?
That remains to be seen - its far too early in Mojo’s life to tell
Like trying to tell ig the baby that was just born will be Jesus or Hitler
Hard to tell
As for desktop - lord knows if it will have any sort of UI bindings
Pythons uhmmm … suck ?
At this point Mojo is interesting but cant say a lot more than that as its way too early to tell
My reading of their material and my takeaway from the video is that it works with all the existing Python ecosystem and libraries. It’s a superset, not subset.
What they are not saying is once you start using the superset features, there would, I’d think, HAVE to be ways in which SOME existing libs MIGHT stop working because for instance they would all inherently depend on the global interpreter lock (or at least be untested apart from it) and once you start doing true multithreading they might not be thread safe or may break.
Of course if Mojo sets the world on fire, all those lib authors would have a fire lit under them to bring things up to snuff for Mojo. And most are open source I suppose, so users could do their own fixes as well.
It will never be the replacement. Simply python itself is not . We are speaking about so many not available parts now. At the end it will find it’s niche. Not more not less.

It will never be the replacement.
“Never” is a long time. You don’t know if it will or won’t be a drop-in Python replacement, and neither do I, but it’s the stated goal and they are already a long way toward that goal, with a credible, crack team working it.
Yes we all know it’s not over until they release v1, so no one is saying it’s a solution TODAY.
Farewell it was Aldo with dotnet. It never replaced java. I had that discussion. And python will also not. Cause the truths is: it isn’t fast as c++ and c and it will not because it can’t. Like Xojo can’t. It would have to replace on all MCU c++. The cyclus would be a really long way. We can sleep well. It is not the language for it and spoiler. The sentence is faster than c isn’t true. After optimizing the c code with the same benchmark they used to show c was more than 8 times faster.
It will not replace.

Farewell it was Aldo with dotnet. It never replaced java. I had that discussion. And python will also not. Cause the truths is: it isn’t fast as c++ and c and it will not because it can’t. Like Xojo can’t. It would have to replace on all MCU c++. The cyclus would be a really long way. We can sleep well. It is not the language for it and spoiler. The sentence is faster than c isn’t true. After optimizing the c code with the same benchmark they used to show c was more than 8 times faster.
It will not replace.
.NET was not conceived as a replacement for Java. C# was Microsoft’s answer to Java. It competes with Java, it does not replace it. It has certainly taken some market share from Java, as competitors often do.
Mojo is a compatible superset of Python and is a few orders of magnitude faster than Python in many cases. I share your skepticism that it would be as fast as C, but it doesn’t have to be in order to succeed at the true goal, which is to speed up the execution of ML applications, which are largely written in Python, and to speed up the development of ML applications by allowing them to be acceptably fast in pure Python which is way more accessible than writing speed-critical portions in C or C++.
I doubt that Mojo will literally replace Python but just as C# doesn’t need to replace Java, Mojo will have its own success and find its own place, likely. Of course C# wasn’t designed from the ground up to be a “superset” of Java or to work with existing Java libs, as Mojo claims to work with existing Python libs – so the comparison isn’t really apropos anyway.

so no one is saying it’s a solution TODAY.
Why I’ve said not YET

Will it be a python replacement ?
Perhaps eventually - but not today
One day ? who knows
If they pull off the superset thing without too many “gotchas” it would certainly revolutionize Python development and it would spur me (and probably a lot of other people) to take a second look at it (in the form of Mojo) as a general-purpose language. I have always liked Python syntax but its glacial slowness and lack of penetration outside the scripting realm has always held me back. If Mojo even half lives up to its promise I’d think a lot of people would go to work on frameworks for desktop and mobile for instance.

Mojo is a compatible superset of Python and is a few orders of magnitude faster than Python in many cases. I share your skepticism that it would be as fast as C, but it doesn’t have to be in order to succeed at the true goal, which is to speed up the execution of ML applications, which are largely written in Python, and to speed up the development of ML applications by allowing them to be acceptably fast in pure Python which is way more accessible than writing speed-critical portions in C or C++.
I doubt that Mojo will literally replace Python but just as C# doesn’t need to replace Java, Mojo will have its own success and find its own place, likely. Of course C# wasn’t designed from the ground up to be a “superset” of Java or to work with existing Java libs, as Mojo claims to work with existing Python libs – so the comparison isn’t really apropos anyway.
Balmer declared in a discussion exactly that in that time but…never mind.
That Mojo is faster than Python: no question. Would be interesting if it would be with GPIO what is now not the case: it is not working. And yes, ML applications would be faster. GOAL.
C++ is for me as accessible like python. But: I have learned C++ before long, long time, Python much later. So it is - I am sure - an individual feeling.
And yes, Mojo is in a wide range compatible. But for sure not in all ways.

C++ is for me as accessible like python. But: I have learned C++ before long, long time, Python much later. So it is - I am sure - an individual feeling.
I know enough C to be dangerous and both C and C++ strike me as languages where I would not want to wade into someone else’s codebase as they could use macros, etc to make code behave in unexpected / undocumented ways no matter how experienced you are with the language. C# is also starting to edge in this direction in the latest version with the new alias feature. There’s a tradeoff between making the language malleable enough to do what you want it to do, and make it malleable enough to do what it shouldn’t do or to be fully comprehensible only to the original developer.
This is the basis of Linus Torvald’s well-known aversion to C++; he feels that it fosters bad practices and also once you start using the standard library and get your code married to it, it’s very hard to divorce yourself from it if you need to go your own way for, say, performance reasons. I don’t fully agree with him, but I think he does have a point, particularly for his systems programming world.
Linus Torwald is sitting on a kernel written in C++ migrating to Rust. Hahaha. Far away from hating C++ I would say.