At least for Modular and Mojo, you could say that’s 100% on purpose. A lot of their team worked on what’s talked about in that video before founding/joining the company. That’s likely also how they managed to get their product up and running so quickly: most of the backend work was done at different companies over the past 3-4 years.
3 Likes
It seems they are trying to reinvent Taichi too. It’s odd they don’t even mention Taichi anywhere but it was the closest thing that came to my mind when I saw their announcement.
22 Likes
Mojo avoids mistakes of C++, but does it avoid Rust’s “billion dollar mistake”? See below.
Not to me (and I see I’m not the only one opposing). Isn’t it static, i.e. like the Julia subset where you type all your functions? And since that’s not needed in Julia, then Julia is a superset of Mojo capabilities? Except Julia has GC (by default), and Mojo has a borrow checker (could such be added as an option-in for Julia?). The safety of Rust is that the borrow checker isn’t opt-in (important for concurrency), but since Mojo is like two languages in one, it’s opt-in there (only on for new Mojo code, not the legacy Python code).
However, Julia is as safe as Python; as safe as Rust actually for single-threaded code(?), with out the mental overhead of Rust.
See here on Rust’s mistake, and Rust’s glidesort:
I don’t believe Mojo reinvented Julia, i.e. Julia is still better, at least in most ways. Julia solved the two-language problem, while Mojo didn’t yet, it’s only on its roadmap. It only solved it with CPython making legacy Python code work, and PythonCall.jl also does that, with same semantics (only the syntax is different for the legacy (Python) code).
1 Like
In all fairness, it has become impossible to keep track of all the attempts that will, finally, fix Python.[1]
this time for sure, you can bet on it, it will do infinite loops in finite time, on the GPU, in parallel, using the latest compiler technology, while being fully compatible with existing Python, 2.x and 3.x simultaneously, etc etc. now give us funding. ↩︎
20 Likes
I just hope it wasn’t a geopolitical decision 
I heard that Taichi is picking up in China right now.
1 Like
It looks awesome. So weird I haven’t heard of it at all until now. Thanks for the reference. 
2 Likes
I started a thread a while ago Thoughts on the Taichi programming language - sparse computing and differentiable programming and it didn’t get many comments. Since then I think Taichi received $50 million dollar of funding and really improved things. I heard they are doing a lot of video tutorials on Bilibili (the Chinese version of YouTube) these days in Chinese only. But they also have decent English material.
12 Likes
In fact, I’m still quite surprised at how little python code is type annotated. I saw a paper a few months ago from some researchers who were collecting code from github for the purposes of training probabilistic typeguessers. They found about 5-10x more TypeScript annotated code than python typed code, if I recall correctly. But then again, TypeScript’s type system is quite a bit more advanced than mypy and friends.
what is the right approach for scientific programming?
My opinion is that multiple dispatch and composition are a better approach than OOP.
13 Likes
I did not read all the comments above. Any one knows if Mojo still have the design issue of white space is an important character in the code problem that plagues Python?
If so, I will not touch it even if it was one million times faster than C.
2 Likes
Julia does have KernelAbstractions
1 Like
It’s interesting seeing so many Julia programmers show an attitude of what could be uncharitably described as indignance about this, that Mojo is “reinventing” Julia. It’s a long tradition of programming languages to give the good ideas to their successors. Julia would never have existed without Lisp/Scheme/Fortran, but you don’t see any of those baseline communities whining about Julia’s massive success in its niche of HPC and technical/scientific computing.
For starters, Chris Lattner has been instrumental in the most important part of the project that makes Julia possible in the first place, which is LLVM. We should be so lucky that Mojo will someday be another OSS tool that he spent thousands of hours working on just for other people to use for free. I’d have loved to have seen the Julia founders trying to cobble something together with the absolute dumpster fire of gcc, but that’s an incendiary remark for another day.
I think the Julia team has done an amazing job at two things:
- Honing Julia’s edges to be an excellent weapon for technical problems, to be tackled by technically-minded programmers once and not relied on by a large group of people or perhaps ever looked at again
- Completely insulating it against being even remotely useful for general-purpose programming with gusto
Whether that goes widely recognized doesn’t really matter at this point, as noted by many commenters. There exists Codon, Taichi, Triton, Pypy, soon Mojo, and if I had to take a wild guess I would imagine there are some pretty cool things hiding in the labs at Microsoft, but that’s just my own personal speculation. I’ve probably missed some as well, but that just further solidifies the point.
In the half-decade since 1.0, Julia has made exactly zero progress toward traits, it’s still incredibly cumbersome and unwieldy for small scripts due to a lack of a small core or MiniJulia facility, and there’s an enormous dearth of resources for non-technical beginner resources compared to communities like Python or even JS. Those are the first 3 that I thought of, but binary size, the extremely unintuitive aspect of multiple dispatch when dealing with general-purpose software, and library availability issues come to mind as well. Julia especially has a problem with there being lots of interesting code with NO documentation, and lots of somewhat decent code with very little documentation, but even I can’t pin that on the Julia zeitgeist itself. Students never write good docs. Most people learn Julia when they’re students. Whatcha gonna do?
In particular, and I’m not trying to flame anybody or anything, I genuinely believe that Julia has overestimated how useful multiple dispatch is in terms of writing successfully-engineered, properly maintained, easily shared programs. I know full well that it maps tightly to a lot of the math that a lot of Julia users spend a lot of time doing, that all makes perfect sense to cling to. Mulitple dispatch makes a lot of sense when you are turning a notation into a representation for a computer, but the Julia language makes few affordances for when I just want to write computer-minded code for the computer to run. I can try and fight against multiple-dispatch, but there’s no traits to help me wrangle the type system into place, so you constantly bash your skull against the fifty-foot wall of type-instability. On top of that, even once I do manage to achieve stability, I still need to ship MBs worth of bs methods that I didn’t want to have to ever consider in the first place for every godforsaken variant of a Matrix that there is. At the end of the day, it just reminds me of Fortran and how most of its lunch was eaten by C programmers, with much derision from people who were too good to deal with its warts. Would anybody say Fortran truly lives today? Sure it’s technically around, but I ain’t seeing a lot of experience on candidate resumes either…
In contrast, there are thousands of Python courses. I live in the rural midwest and there are no fewer than 4 courses at my local community college that teach Python in some regard. If I interview 50 people, I’d bet my next 10y salary that 40 of them could whiteboard in Python if asked to do so.
In many ways, Julia’s lunch was eaten a long time ago. No matter how many times someone types “Yeah, but {some obnoxious macro nobody but they knew about} fixes this!” the Julia language has giant holes in it, and the design team has not seemed willing to take general-purpose programming seriously. I mean, there’s already a half-dozen people writing unicode/matmuls in this very thread, as though that somehow is going to make it easier to dig through 5000 lines of unicode vomit to find the p they thought was a ρ. Great for Junior doing his matmul homework, but not so great when John Doe’s bad code review causes a DB migration to shit the bed halfway through.
All the while, the Python people have diligently, fervently, obsessively ask themselves “What would make Python nicer to use?” Better performance? Take your pick, there’s a half dozen options. Libraries? One for each day of the week no matter what you’re doing. Packaging? Getting better all the time, even though you could just pipenv and /activate this entire time anyways. Typing? Go for it, or don’t, everything will work just fine with literally any type-annotation because they’re just metadata.
In conclusion, I think the time to fix Julia was a long time ago, and this overtaking of Python into the space of ultra-performance, ultra-ergonomic, ultra-learnable language was inevitable. There’s no reason to think Lattner and his team of killer coders won’t knock this out of the park and I’m sure they’ll get all the funding and help they want, gift-wrapped and gold-plated to boot.
2-3y from now, as inconceivably large and successful as Python has been, I believe it will be even more so and all the people who somehow find Python less joyful to write/read will have the Julia team to thank, since otherwise, Mojo would not have needed to be done.
18 Likes
(post deleted by author)
1 Like
You’d think with all of this they’d have come up with a decent package and environment manager by now.
With all due respect I feel like you could have tried a little harder.
I feel Julia does what I want and if Mojo takes what makes Julia great and puts it into Python then more power to Mr Lattner. If Julia doesn’t work for you then that’s fine, but it works for me and all of my cool academic buddies who comprise the majority of the community.
22 Likes
It’s interesting seeing so many Julia programmers show an attitude of what could be uncharitably described as indignance about this, that Mojo is “reinventing” Julia
I think that’s a pretty reductionist take on the opinions that have been shared here and characterising them as “whining” could also be considered “uncharitable”.
In particular, and I’m not trying to flame anybody or anything
Really? How are are supposed to interpret this, then?
as though that somehow is going to make it easier to dig through 5000 lines of unicode vomit to find the p they thought was a ρ. Great for Junior doing his matmul homework, but not so great when John Doe’s bad code review causes a DB migration to shit the bed halfway through.
I was going to address the rest of your post, but to be completely honest I am not sure what point you are trying to make. You list a bunch of addressable technical problems (some that is very debatable that are critically important, like traits) and then make a point about having a much smaller community than Python.
You are of course free to have your own personal preferences and it’s completely alright not agree with Julia’s design choices or direction. But reading this I think you must just be trolling:
All the while, the Python people have diligently, fervently, obsessively ask themselves “What would make Python nicer to use?” Better performance? Take your pick, there’s a half dozen options. Libraries? One for each day of the week no matter what you’re doing. Packaging? Getting better all the time, even though you could just pipenv and /activate this entire time anyways
8 Likes
Strange thing to say. I do it all the time. Julia is excellent for that kind of thing, whether it’s quick data analysis, off the cuff image processing, or general scripting.
9 Likes
I’m sorry you’ve had such miserable experience using Julia. You may have a few points with value: Julia does have flaws and it’s urgent that we keep working to fix them. (You presumably won’t have noticed if you don’t use Julia much anymore, but we are making progress on several but not all of the negatives you pointed out.)
However, any value is undermined by your choice of how to present your arguments: emotive words like “whining” imagined to apply to large numbers of people in one community and not one person in any other community (since when are large collections of people homogeneous?), idolizing some individuals to godlike status, and the expectation of perfect success in some of Julia’s alternatives (those alternatives are awesome but also have well-known problems) encourage suspicions of bias, raise hackles, and make it hard even for readers who don’t feel threatened by your tone to take your points seriously. Please remember that this is a deliberately Julia-centric discussion group and try to keep things civil.
66 Likes
Thanks for the post haydenjones. I think it is a well written, not too long or short and I enjoyed reading it (even the parts with more imagery). At the least, it shows caring for Julia language and its promise, and I would love to hear more of your comments in person in JuliaCon (at MIT) this year.
In fact, I think a 1000-word “essay” about “Julia FTW” (for-the-win) could be a nice final session at the conference, where we would choose a couple of submitted such pieces to be perhaps read aloud. It would give many the opportunity to show the literary skills of Julians (which might exceed coding skills in some cases) and give ideas about the next steps in the path for Julia world domination.
3 Likes
Threatened by my tone? I haven’t punched anybody, Tim. I find a remark like that to be much more dramatic and reductive than anything I wrote, but hey. I’m just a user, right? You’d just as soon characterize me as generalizing the entire community as homogenous because I made note of this very thread’s comments. I actually read every single instance of the word Mojo on this forum before I began this post, and I’ve done my homework.
I can nearly sympathize with your position, that emotive language is unsuited for technical matters if it weren’t for the fact that these tools are used by real people in the real world. A roofer wears his shoes all day long on a hot roof, working hard. At the end of the day he has a strong conviction that he’s either wearing decent shoes, or pieces of junk. Would you ask him to refrain from emotive language as his feet ached after hauling 50 shingle packs up a ladder? Without romanticizing the development process too much, I just want to assert that it matters gravely to me and many others whether or not the tools are of quality for their work. If I have to stare at something for 5-6+hrs/day, by God it better not be a piece of junk.
Let it not be mistaken, I am 100% biased. I cannot think of a single instance where I’d pick Julia over Python (or derivative, obviously) for a real-world task. This is an offtopic thread about Mojo, which I think we can all admit at this point is the culmination of a bunch of extremely talented and highly funded individuals looking at Julia and deciding that the AI/ML space needed a better tool. If that’s not relevant for this community, then one of us has gone insane.
You yourself came up with Holy traits way back when. Has that been solved? Have interfaces? If I want to implement some functionality, Julia doesn’t allow me to ask what methods I need to define directly. If there’s low/poor documentation for something, the language won’t just tell me x,y,z methods in interface ABC are not implemented. Are there any tools that will warn me about using rho when I mean p, or such typographical obstacles? I do suppose it would be impossible to measure how much time it saves vs how much time it has wasted with such frivolities, but it seems like an obviously bad tradeoff to me, giving up the possibility of chasing down single-character lookalike bugs just to get pretty formulas in the code. I’m not opposed to Unicode characters in source code, but it can just be relegated to comments and not identifiers.
Mojo (according to Lattner et al) will solve all of these issues and more by allowing for a programmable compiler. Julia claims to have advanced metaprogramming capabilities a la lisp, but how could I ask the Julia compiler not to compile type-unstable functions? There’s no such facility, as far as I’m aware, besides writing my own macro to mangle my way through it, and attaching it at every definition site. The way I understand it, at some point in the future that same functionality would be as simple as an import statement in Mojo. The only other language that I’ve personally heard of attaching an interpreter into their compiler is Julia, with femtolisp. I’ve never actually used that, so maybe I’m completely wrong and this could all just be a couple hundred lines of femtolisp in 2.0 or something. If so, I’ll own my error.
If not, then it’s just like I said already, I think 8m+ python->mojo hackers will completely gobble up the entire Julia project in a few years’ time.
4 Likes