Did Modular just reinvent Julia?

Offtopic
186

so Julia is the bad shoes roofer (you) wears and you would never want to wear it…? Are you forced to wear it then? maybe it’s time to change job.

exactly, according to Lattner. Don’t get me wrong, he’s great and played leading role in many developments. But in the end of the day, he’s just one person, AND in this case he has monetary conflict of interests (literally, as mojo is not open source and has got seed round of venture capital money!) So I wouldn’t just buy everything the company itself say… (even on technical ground, Microsoft tried the “make python compatible but faster” and it kinda didn’t go anywehre, it’s hard to imagine they lack money or engineering resource somehow Lattner as 1 person can conjure)

I wish they succeed because that would be amazing, but again, I wouldn’t just belive literally every word a startup with VC money say at the hyping/marketing stage (they need more VC money) …

19 Likes
187

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.

I don’t think we can all admit that. I am sure Chris Lattner was similarly talented, funded and motivated when he decided that the right choice for technical computing was Swift. As for Mojo, we have an unrealistic benchmark and tons of marketing material. I don’t think is a given that they will find success and strongly dislike this “mythmaking” attitude towards certain people in the industry.

And obviously, the people that choose Julia don’t believe that Python is a suitable foundation for this, so of course there is a lot of skepticism in something like Mojo.

As a sidenote, I find the tone of your message extremely aggressive and not really conductive to any constructive discussion.

24 Likes
188

Here is my 2 cents.

I cannot think of a single instance where I’d pick Julia over Python (or derivative, obviously) for a real-world task.

Highly accurate and performant satellite simulators. Unless you want to write everything in C++ and make an interface with Python…

Julia is allowing me to develop the C++ code for a satellite attitude control subsystem using one single simulator for all the project phases that can hardly be reproduced in any other environment.

Can Mojo fix everything? Nobody knows until we have access to an open-source version.

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.

Everything here is circumstantial. It is much more related to the IDE than to the language itself. At the end of the day, just do not use UTF-8. From my point of view, I am glad Julia supports UTF-8.

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.

Your understanding of how a language/ecosystem is selected to solve a problem seems narrow. From this perspective, MATLAB should not even exist, given that Python reached the current state and it is open-source.

For example, if Mojo solves everything you mentioned, I would still use Julia because Python does not have an ecosystem to solve differential equations with the features in DifferentialEquations.jl. I tried, DifferentialEquations.jl just happens to be the best tool available for my needs. I can live with a language without Traits and some “correctness” problems when you try to extend it, but it would be tough to adapt everything to use another differential equation solver.

21 Likes
189

Alright everyone, this is heating back up here. Let’s please try to keep this civil and productive. To that point, some guidelines for continuing participation:

  • Do not criticize others’ tone. That only derails things.
  • Conversely, I need everyone to refrain from escalating tensions here. For example, do not insinuate that anyone here is a troll or insane. I’ve held a light touch on flags to this point, but things are going to be more aggressively moderated from here on out.
  • Please consider whether your voice is needed here; let’s avoid dogpiles.
  • And, as always, follow our guidelines and community standards
51 Likes
190

I would just close this thread. Betteridge’s law of headlines applies here. The answer to the question posed in the title is “No”. From what little that we know, there are are some fundamental differences between Mojo and Julia. However, we also do not know much as the language is not open source or otherwise executable on our own computers. That said a compilable language with Pythonic syntax is not particularly novel in and of itself either. There are many iterations. That said I look forward to seeing what innovations and solutions may come from Mojo.

Beyond this, I think everything else about the potential of Mojo or any specific Mojo versus Julia comparisons are sheer speculation. It’s just way too early to make an fundamental statements about what Mojo is or is not or what it may or may not do.

There are some Julia gripes and wishlist items here, but I think they would be better served in new topics with titles germane to those specific items.

I move to close this topic. The answer is no. Modular did not just reinvent Julia. Mojo is different from Julia.

20 Likes
191

These are all really good points. I apologize for contributing to derailing the discussion/making things less civil and also to @haydenjones in particular.

I’ll keep all of these in mind for future discussions.

7 Likes
192

I think there’s value to be had in the community engaging with critical thought on both alternatives (which is really what this thread has become) as well as the critics themselves. I’d very much to keep this thread open for as long as it remains non-toxic.

8 Likes
193

I also think it’s just better to say “no” to question posed and move on, if needed to continue in future ask more specific questions when Mojo team releases further work. We need something to draw comparison with I think. :sweat_smile:

1 Like
194

Just to comment on the technical issues, some of what you find missing is indeed “work not yet done” but in other cases the bigger question is “do we really want this?” An example might illustrate. There are efforts underway to develop “interfaces,” and I think there’s a reasonable chance that they will land at some point, but practical experience has shown that the precise definition of an interface can be contentious. An interface generally establishes hard boundaries that may in practice be soft: in practice it seems where you want a whole family of methods to support things that support a portion of an interface but not all of it. You can establish an endless variety of traits, but it’s very hard to have a trait that, say, encodes the fact that “X satisfies 58.6% of the indexing interface and 84.3% of the iteration interface, so it’s fine to run this method on it.” That observation has presumably led to some reluctance to push hard on developing interface—will it really be better than duck-typing?

As an alternative to interfaces, I think many of us think that a good answer to “what do I have to implement for my specific application?” should eventually be spit back at you by JET.jl or a JET-based tool. That doesn’t have the problems of establishing hard boundaries and can give you exactly what you need for your intended application. It should also resolve issues of what’s needed for static compilation, etc. But while JET is already amazing, it’s still under active development and not yet ready to serve as the answer to all problems.

In other words, part of why Julia isn’t “there” (for you) is because it’s not so clear that just implementing things you find in other languages is the best approach. But all these things are under investigation, and possibly closer to fruition than you may realize.

50 Likes
195

Although I agree with the rest of your argument, it does seem to me that there is quite a lot of information about Mojo available. Chris goes also into some (yet) undocumented features in the recent podcast with Lex Fridman (Spotify).

By heart: in the podcast he mentions that Mojo will run Python via the CPython interpreter, they will make their own package management solution, and it’s probably gonna take months to a year for Mojo to be released to the public. Not sure about that last thing though. He also said that they are working hard on something that people can run locally.

1 Like
196

I started the thread. At this point I agree with some others who are saying we really need more info on Mojo before we can draw more conclusions. I’d be amenable to putting the thread on pause until some future point when that kind of info is more readily available.

When I first posed the question my intent was to ask if Mojo was essentially a solution to the same set of problems that Julia is targeted towards. Certainly there can be more languages and they can even substantially overlap.

I think so far my summary is that Modular probably created Mojo because:

  • They want to target the existing, substantial Python userbase. Lattner’s experience with Swift for Tensorflow (it’s lack of adoption) probably played into this. Python is a safe choice. If the strategy works they tap into an existing huge base of developers. The downside, of course, is that they’ve got to be compatible down to the bugs.

  • They probably wanted more control than they would’ve had if they decided to invest in/adopt Julia.

  • They’re baking MLIR in from the start which would seem to have some advantages for optimization and backend targets.

As for the last item there’s nothing keeping Julia from adopting an MLIR layer in the future (other than development resources).

13 Likes
197

I’d further add that the way they do that is by just adding Python interop, which already exists both in Julia and Swift. I’m not sure what, if anything, is supposed to make Mojo different from S4TF in this regard.

2 Likes
198

I’d call it curiosity, a more charitable interpretation. The Julia language has come with some interesting ideas - even though I am a C# person, I can find it interesting.

In the case of Lisp people, it’s probably because too many of them are engaged in a civil war, likely over something which is quite irrelevant. I really like Lisp - I’m not so keen about the community.

I can write code in Python too. But I would not describe myself as a Python programmer. I know enough Python to be officially classified as dangerous. I suspect that the local community college is producing more Python ‘programmers’ like myself.

I bought a book on advanced Python. Comparing that book’s code with mine is night and day. Their code is object orientated, mine is procedural. What does the college teach?

In many ways, Julia’s lunch was eaten a long time ago.

Yes, that’s been said about many languages that are supposed to have been replaced by Python. Yet, languages like C# and Java are still with us. Heck, there are some unusual languages like Prolog and COBOL which are going strong. COBOL has 800 billion lines of code out there, running the banks and financial institutions. Some perspective, please.

And then there’s that.

2 Likes
199

Hi all,
The following are personal opinions.
I think that every human language has a reason to exist. The same happens with computer languages. I have earned my living in science for many years thanks to Fortran and now with Julia and a bit of Python. (Fortran is still very alive, please see LFortran and the fpm).
Even if there is only a few people in the world being able to earn their salary by using a language, then that language has a reason to exist and its worth it. Besides, the world of computer languages has so many dimensions and aspects, that saying that one of them is better than another one, comparing in a unidimensional way, gives no benefit to neither of both languages. I think comparisons are a consequence of the competitive world we are living in, that in some sense is taking the world to a bad place (climate change, poverty, diseases, animal and plant extinctions, decrease of empathy in the society, increase of entropy, etc).
Best.

11 Likes
200

As a model citizen I try to combat the problem of entropy increase by doing absolutely nothing at work, but sadly only a few of my colleagues are following my good example.

20 Likes
201

I would say that by working you decrease entropy. In some way, hopefully by working in science for example, the knowledge you introduce to the Universe decreases the entropy while the energy consumption of your computer increases it (the former should be larger than the latter in order to have a net entropy decrease). Does it make sense?

2 Likes
202

You should see my desk.

30 Likes
203

There’s another possibility, quite speculative. Considering the genesis of Mojo and the heavy marketing operation for a startup, I suspect (= it’s an opinion) that they want to target cloud computing for AI and thus have to develop a language.

In a sense, it’s more like Modular is a competitor of Julia Computing. But there’s a big difference (to me) regarding the causal order of development. For Julia, it’s been: 1) language dev, then 2) targeting a business to sustain the development. While for Mojo it looks like (again, opinion here) 1) targeting a business and 2) developing the ad hoc language.

The supporting facts are that 1) it’s currently cloud-only (and it may or may not become open-source later), and 2) the (too?) big fuss around it.

Of course, I may be totally wrong, but I’m suspicious about that … and only future will tell :slight_smile:

2 Likes
204

@tim.holy I had a go at dealing with your “implements 58.6% of the interface” problem in Interfaces.jl, using mandatory and optional components.

It seems to work well enough for both tests and traits, you can pretty easily query combinations of trait components implemented for an object.

I think Jacob Quinn also did in his version using an optional macro.

6 Likes
205

Part of this podcast where Chris Lattner talks about Julia and Mojo is available here: https://www.youtube.com/watch?v=6oxs9Wm1OEI

3 Likes