I don’t know: Python programmers will not have to learn a new language to use Mojo? Looks like two different animals to me…
8 Likes
A lot of claims are made about Mojo, but we are (yet) not in a position to verify them, and many of them are conflicting or speculative. Calling these “information” is very charitable.
But of course the lack of specifics (as in “runs your code and you can benchmark it on your desktop” specifics) allows a lot of people to project their dreams and desires into Mojo. This, of course, happens to a certain extent with all new languages.
Color me old-fashioned, but I would have waited for an initial, but usable beta before starting the hype tour. I understand that this is of course not ideal for getting funding.
10 Likes
The Lattner’s short video excerpt is interesting: “Python is a scripting language”, “Python is for glue code”, “Python is easy for beginners”,
Types are a prominent concept in Julia. I need types to reason about my programs. I feel miserable using languages without strong emphasis on type system-> I feel miserable using Python (and I can’t always avoid to do so).
I hope that mojo will provide a strong type system (otherwise I will not even consider it).
Julia is here and I am a super happy and productive Julia user for about 4 years now. I have seen numerous posts on discourse where people complain about the language… It is normal to discuss about late trains, but I can’t help wondering why I feel so happy with Julia while some other people seems to suffer so much with it…
I come from large scale Python/C++ projects and It was so painful to deal with the social and technical issues related to the two-language problem. For me Julia provide a 10x SpeedUp in programming leaving so much more space to focus on scientific concerns. Julia is so versatile allowing us to write applications in very different domains (wave simulation, mathematical Optimization, ray-tracing, fluid simulation, transport,…), using CPU and GPUs, with super-charged post-treament capabilities (Makie, DataFrames,…).
So my personal conclusion there is two options:
- Mojo will be very different from Python and superior to Julia (for me) and I may adopt it (and be back into the two-language problems…)
- Mojo will be close to Python (feel natural for average Python programmers) and I will not be the target.
P.S. Just to be clear : I am super happy with Julia but I love to see improvements (my #1 wish would be an easy way to generate .dll/.so callable from my client’s C++ applications).
20 Likes
It has already been mentioned on the thread, but after hearing Lattner on that clip, I think is interesting to see the disconnect between:
- Julia being a new language is an obstacle for adoption.
- but adding concepts like borrow checking is not an impediment.
I really don’t get it. Who is this hypothetical programmer crippled by slightly unfamiliar syntax but empowered by advanced techniques for memory management?
I feel like we are beating a dead horse with this thread, though 
Not sure anything new can be said about this at this point in time.
17 Likes
Do you mind sharing the book title?
Naive question: There are numerous attemps to make python “fast”: pypy, pyston, pydjion, numba, taichi (I am missing something? Maybe I can add to the list cython amd pythran). All of them with somewhat limited success. How is mojo different from any of them? Is it because it is a superset, instead of a subset of Python?
3 Likes
I keep thinking of Cython as the main precedent for Mojo. Like Cython, Mojo is actually a new language. It looks like Python, but it is not Python.
I think a new language is actually what is needed. That should not be a surprise. We’re discussing this on the Julia forum.
The other thing it is doing is offering a potentially gradual migration path from CPython. That’s really important because that is where the ecosystem exists.
3 Likes
Imagine if Julia had adopted Python syntax!
1 Like
What then? Wouldn’t it, at best, have been Mojo then? It would certainly have ruined Julia as a language for me.
16 Likes
15 Likes
Ruined? How so?
Is def + colon and 0-indexing so much worse than function + end and 1-indexing?
It would have been epic trolling. Imagine multi-threading and doing ML with “native python”.
That’s the most important question, and I don’t think we have a real answer to it. I’ve been listening to Chris Lattner since the Mojo announcement to figure out what secret sauce they are using to solve the problems that every other make-Python-fast initiative encounters. So far I haven’t seen anything.
I suspect what we’ll end up with will be a bit like Numba but more tailored to the machine-learning use case. Which is to say, Mojo will mostly just execute Python code in the usual way with the CPython interpreter, but with the additional capability of accelerating certain functions that are doing heavily numeric work.
If that turns out to be the case, Mojo may very well come to play an important role in the Python ML ecosystem. But it wouldn’t really be similar to Julia at all.
2 Likes
This would be really bad:
In [1]: x = [1,2]
In [2]: y = [3,4]
In [3]: x + y
Out[3]: [1, 2, 3, 4]
So a good depart from python syntax would be required to support natively array operations with mathematical sense.
(and I think this is the greatest Mojo challenge: can the python syntax be maintained and still the language feel natural for scientific computing? Because if everything boils down to calling libraries with any other syntax, like numpy or Jax, that’s not really different from the alternatives, in terms of compatibility).
26 Likes
There’s a trillion differences, first of all no structs, no type parameters. No module, obj.method() calling, etc etc.
And, worst of all, no end-delimiters, but whitespace instead🥶
The features and syntax are closely connected.
4 Likes
well, Julia has some whitespace too 
No a departure from Python semantics would be required. But you could use the syntax to mean vector addition without changing the syntax. Since the original post was imagining trolling python that’s what they meant I think.
3 Likes
Correct!
Just like Mojo has its own non-python stuff. A core argument from Mojo against Julia seems to be, “Oh, but people don’t want to learn new syntax.”
1 Like
I think having the same syntax but different semantics would just be needlessly confusing. You’d always expect it to behave like python, when in fact it does not - having different syntax serves as a VERY good reminder that julia just isn’t python (and thinking of julia or mojo as a “just faster python” is not going to work out well).
17 Likes
In the sense that using all the features Julia offers in a reasonably compact way requires dedicated syntax to most of them, you are right.
But given the semantics of Julia, a practically infinite range of syntactic variation could map to the exact same language under the hood.
Syntax is something that most people pick up the fastest when learning a new programming language. So changing Julia’s syntax would not make it appreciably easier for newcomers, but at the same time it would impose a huge cost on existing users for no good reason. That’s why it is never going to happen.
Personally I mildly dislike the whitespace-based syntax of Python, but if Python was a great language, it is something I could easily live with, just like I accept the (very few, not necessarily syntactic) quirks of Julia because the great features outweigh them.
Conversely, Python users who imagine that whitespace-based blocks are a key feature of Python are not doing justice to the language. The strengths of Python go much deeper than that.
16 Likes
I haven’t seen any representative of Mojo make any statement like this. Chris Lattner has had only good things to say about Julia, the community, and their response to Mojo (so he’s seen this sort of chatter). The closest thing he has said to this is that he wants a language that doesn’t require people to relearn syntax, and he wants something for Python programmers. And Mojo indeed is intended to fully allow Python syntax. However, the Mojo docs also introduce new syntax that are critical for performance and technical designs, like borrow-checking and eliding GC. Just different goals and approaches from Julia.
I’m surprised that anybody took this conversation as a “there can be only one” thing, AFAIK people just got heated earlier because people came in belittling opinions and ongoing work on the language. Other than that it was just comparisons and speculation.
3 Likes