I think the benchmarks are useful for signaling: This language is up to speed, you don’t need to worry about dropping performance by using it.
3 Likes
I didn’t saw anyone mention possibility of deploying Mojo code on most relatively new devices with very small binary sizes as it is main selling point for me if they open source it ofc 
and They have big VC backing which can be both good and bad we’ll see in few months/year
2 Likes
I love Julia for it’s elegance and speed, but for me, speed often trumps elegance.
The soon to be released Mojo language promises to be backward compatible with Python with great acceleration, use of loops, etc. Furthermore one can use tools such as Copilot to greatly accelerate development speed. I can’t wait for better AI-enabled code helpers for Julia that reliably help coders and taking the latest iterations of the language into account.
Having said that, the worst language feature of Oython for me is the inability to overload functions.
I want it open sourced. Until this my time is to short to be interested.
4 Likes
Can we think of a way to harness some of the energy that’s currently devoted to talking about ChatGPT and Mojo.
and divert it to issues and PRs for Julia and Julia packages? 
(just kidding - carry on!)
30 Likes
Guys, just request the access for the Mojo playground. Inspect this Mojo-code and close the question for yourself.
Julia solved 2-language problem. Actually solved. In reality around us (not fantasies or dreams or plans or aims). Even v0.001 early-pre-alpha Mojo-code feels much more like Rust than like Python. v0.001 pre-alpha. I.e. very feature-poor dialect of Mojo (e.g. there is no tuples yet). When it will approach its goals in terms of features, lang complexity will strive to the north very fast, there is no way around. => idiomatic Mojo will differ from idiomatic Python a lot => effectively killing the strongest declared feature of Mojo (which is also main competetive advantage over Julia) - being (m.p. aiming to become) a superset of Python.
7 Likes
Unlike Python, Mojo actually offers method overloading according to the docs.
1 Like
Mojo seems almost diametrically opposed to Julia to me. Julia has been very much in the magic compiler camp: “Why ask the programmer to annotate when the compiler can deduce or make a reasonable guess? Let it fail at runtime!” is the mantra. Chris Lattner instead talks about Mojo giving control to the programmer.
Talking to people involved in CS and language design, the main focus of languages in recent years has been how to design languages that allow you to build something highly complex that is also correct and fast. The experience that people have with Rust goes much beyond memory management: if it compiles then idiomatic code is often also correct. Refactor/Parallelism without fear. Etc… In contrast, Julia pretty much uses the C approach to correctness: Get good and don’t write buggy code.
I have no insights into why the repeated hopes that some company would bet big on Julia and invest resources never came through, but this might be related. If you hire 10.000 programmers to work on something you need a way to manage complexity in a context where most people working on the codebase are not intimately familiar with most of the codebase. Julia just smells entirely different to what has been done elsewhere in that respect (i.e. Swift at Apple, Rust at Mozilla, Carbon at Google).
If you read the modular programming manual the first half is pretty much the playing field that Julia has excelled in. And then come a list of familiar topics that are just not a thing in Julia, many of which (though not all!) are related to not accidentally doing Bad Things:
- Strict functions
- Argument passing conventions
- Ownership and Lifetimes
- value semantics, move vs copy information at the type level.
- Type Traits
I believe Julia gets a lot right. Half of my current research couldn’t have been done without Julia existing. I want it to succeed. But I see Mojo as an existential threat because this will appeal to the C++ crowd. This will appeal to the people that have been engineering the 2 language solutions that make Python work, while Julia by and large has failed to do so. I can absolutely see a world where this “bolt a more ergonomic Rust 2 onto Python” approach will take off and will render much of the rational of Julia moot. Why learn/use Julia when you can use a language that gets used in industry after, that allows you to use the libraries developed at Google/Facebook/Apple, etc… and that is now also composable, extensible and has a lot of power gradually accessible when you need it?
15 Likes
I don’t think that is accurate. Arguably, Julia’s compiler is much simpler than e.g. PyPy or Numba or LuaJIT. It doesn’t need to “guess” (or “trace” at runtime) because the Julia semantics provide much more information to the compiler than Python semantics. (See also the FAQ: Why don’t you compile Matlab/Python/R/… code to Julia?.)
I think it’s hard to evaluate Mojo in its current embryonic state. Will it speed up large nontrivial Python codebases without much modification? (Matrix-multiplication is too simple to be very revealing.) Will it be essentially a different language that happens to share some surface syntax with Python? Will it be Cython redux? Numba/Pythran redux? Will high-performance code and types be composable? Will you be able to write type-generic/polymorphic code that is fast for new user-defined types, higher-order functions, etcetera?
I wish them luck, and hope that they introduce new innovations that raise the bar for everyone.
39 Likes
But since when does exact syntax matter (bar outrageous examples)? Python’s syntax is pretty nice imho, so keeping large parts of it is not a bad decision. Although I don’t agree with the goal to develop a superset of Python. In order to achieve that, Mojo has to replicate all of Python’s sharp edges and subtle design mistakes (GitHub - satwikkansal/wtfpython: What the f*ck Python? 😱). Or Mojo deliberately ignores some problems, but then good luck running any moderately sized Python project on Mojo.
Julia OTOH has a wide open gap in programmer support and correctness checks (if it compiles it runs!). If they make a strong showing for themselves in that area, Mojo may be interesting to me.
3 Likes
I think this is somewhat overrated. The memory safety of rust if probably its greater appeal. The syntax checker is less important, syntax errors can be much more efficiently resolved with a linter, and most of them one does not even have to look to the error message when one gets used with the language. Refactor, parallelism, requires the correctness of the algorithms, and that cannot be guaranteed by the syntax, only by unit tests. I more and more value the tooling around the language, when advocating it to others - Revise, linters, doc tests, testitem, and the high-level interface and the repl are all extremely useful to test the correctness of the code.
6 Likes
I’ve seen this feeling repeated in a couple of places now that if only Julia would get the money being “poured into Mojo”, it would come out ahead.
As far as I can tell from crunchbase, JuliaComputing/JuliaHub and Modular got nearly the same investment of 30M$. This does not include research grants for improving the various packages in the ecosystem (except for one small NSF grant, apparently).
So, it seems both companies are in the same ballpark w.r.t. funding?
https://www.crunchbase.com/organization/modular-ai
https://www.crunchbase.com/organization/julia-computing
5 Likes
Good metaprogramming is not something that’s a trivial add-on. If it wasn’t/isn’t a key objective for them, there’s no reason to expect “they’ll have it because we do.” I know little about Swift, but my understanding is that its metaprogramming capabilities are way behind Julia’s. After lots of years and lots of resources. Conversely, Jeff made sure Julia targeted metaprogramming from day 1.
21 Likes
It’s important here to distinguish between different species of metaprogramming. They don’t have AST level metaprogramming like we have with our macros, but they are aggressively targeting a form of compiler metaprogramming at the MLIR level, so something more like Cassette.jl or a hypothetical julia compiler plugin system.
11 Likes
I feel this, but one view you could take (not that you should, but you could) is that this is further fragmentation of the “Python” ecosystem, which is bad for Python and good for Julia. You have Jax, Numba, PyTorch, TF, now Mojo, all kind of solving similar things at some level, and on the other hand you have the single, universal, and powerful Julia, which is not a bad position to be in.
31 Likes
I’ve had a reasonably small Julia and Rust project in production and Rust static types make me sleep way better at night. In Julia, for example, I’ve once got an exception in production that was some object that was of an unexpected type. I’ve had to trace four layers back to figure out where the object came from. And sure, you can statically type all your signatures, but that still doesn’t feel as rock-solid as Rust (I use “feel” here, unfortunately, because I can’t exactly pinpoint where the difference lies.) Also, static binaries are amazing in production. Memory usage went from 300 MB to 30 MB for a simple web server.
Having said that, I still think Julia is amazing for data science and research.
EDIT: Here is a nice blog post which describes nicely the difference that more strict types can make: Writing Python like it’s Rust | Kobzol’s blog.
22 Likes
Not to say I agree with the takes complaining about money being poured into Mojo, but I don’t really see how your point is a counterargument.
You just pointed out that they have an investment that is roughly comparable to what has been put into JuliaHub. So the arugment people are making is that if that money was just magically put into JuliaHub instead, it’d double their resources, which sounds pretty nice.
Of course, that’s not actually how funding works yadda yadda.
3 Likes
My take is somewhat positive really. I think that the two language problem is a huge problem. Julia has had many ideas, but isn’t perfect. If Julia and Mojo riff off each other in a nice competitive atmosphere, I think that will only help Julia come up with new ideas and directions to solve the two language problem. If this is done well, I think Julia and Mojo would leave behind all other languages. If the two play off each other and have enough fresh ideas to solve any of the current shortcomings, then I don’t see who would use R, C, or Fortran. We’re not there yet, but pulling some of these ideas of how no GC mode can work would get us pretty close, and it will be interesting to see what else they come up with.
In the end, I think there’s many reasons for Mojo to dead end that I’ve described before (i.e. that most of the performance improvements come not from slapping a JIT compiler on a dynamic language, but from the aspects of language design itself making JIT compilation ergonomic enough to truly work in the full language). If Mojo is going to be bug-for-bug compatible with Python, it won’t be able to optimize except for a small subset which does not look very Pythonic at all (which is what they demoed), and if it’s not bug-for-bug compatible with Python it will have adoption issues because codes won’t just automatically translate over. However, that doesn’t mean that they don’t have good ideas. There’s already some cool ideas that Julia should incorporate, and these things will only make Julia better.
43 Likes
Though I have to quote someone from Reddit who said precisely what was on my mind when I saw the announcement:
Mojo is for Python programmers who don’t want to learn a new syntax yet have no problems learning static typing and manual memory management?
45 Likes
I thought something along those lines as well.
So far it seems like Mojo has done at least something right: generate excitement. They have a slick website, with a lot of effort put into marketing the language. They have Chris Lattner, whose accomplishments have garnered a lot of trust. And they have the promise of keeping the good parts of the Python ecosystem while improving the bad ones.
But, and possibly I just lack the knowledge to envision it, I just don’t see how. I don’t think Python is easy, I think it obscures some fundamental aspects of computation and programming. And if you “fix” those aspects, I think you are esentially programming in something else.
I don’t know how Mojo will be different to the myriad of alternatives that fix some of Python fundamental issues. But even if it did, I am not sure that would fix the humongous ecosystem of libraries ducktaped together with some underying C++ libraries.
PS: I saw you answered me on HN about Python dependency management. Thanks for the tip. I wasted a lot of time today with my local Python environment, and I decided I will just get rid of the Python libs if I can help it haha.
6 Likes