They've also claimed both on the page and in the podcast that certain testing reveals a 68,000x speed up vs Python. That's probably true in a select case, but this is why you use libraries in Python - to make use of all the hard work that already exists in C/C++ in those libraries, with Python serving as a high level and far easier to write functional wrapper. Ie anyone serious about performance isn't going to be looking at that metric seriously, rather they're going to be asking what the real performance gains are vs standard practice. In that case the answer seems to be rather roughly a 1.5x speed up based on what's on the performance page of their site when comparing to PyTorch and CUDA, which is a more realistic scenario.
I am curious about how much work the compiler does to automatically identify available hardware and distribute the load on its own vs how much you need to specify as a developer.
All I know from the news is they have a marketing team that decided to jump on the AI hype bandwagon. Plus the aforementioned outlandish performance claims.
Unfortunately marketing like this tends to trigger an equal and opposite reaction in me.
Anyone with AI programming experience can comment on whether they have made any specific believable claims about performance?
>That's probably true in a select case, but this is why you use libraries in Python - to make use of all the hard work that already exists in C/C++ in those libraries, with Python serving as a high level and far easier to write functional wrapper.
Yes, but that's also the issue they address. That you cant just write plain Python for something not covered by libraries and have it be fast. You need to then mess with extending with C, Cython, and so on.
There's not a strong reason to use Mojo over cython right now, but if Mojo can deliver on their claims, I think there will be. A borrow checker, better IDE support, function overloading support, and better SIMD support are things that stick out to me in Mojos favor.
Aside from the rest of stuff they offer (and higher speed, if they're telling the truth) Mojo is also a standalone language you can use, whereas Cython is meant for dual-mode use alongside Python.
To make a conforming C compiler, someone has to buy the ISO C standard (208 CHF), which other folks will then spend development resources in creating C compilers that obey said standard.
The biggest open source compilers, clang and GCC, only keep being up to date with ISO C, because of the money from IBM, Red-Hat, Apple, ARM, Intel, Green-Hills,... place in assigning company resources to work on them.
What development resources is green hills contributing to GCC or clang? As far as I know, they don't actively develop either, aside from selling a completely unrelated compiler that used to be called "gcc" long before the Gnu compiler ever used that name. They also haven't meaningfully participated in the mailing lists under their company name.
In any case, it's my understanding that the C standards have largely been community driven efforts that formalized things already being done by major compilers like Gnu rather than driven by the technical needs of industry the way C++ has.
Interesting, how did you find that out and which product was it for (if you can say)? They recently (as in this year) assured me that the safety certified compiler was home-grown. I'm inclined to believe them given how broken the parser is and how many features it lacks.
1. The C language spec isn't code, open source is only concerned with the code.
2. Philosophically, I would say that if you can write and compile standards conforming c code on an open source compiler, and the standard is freely available then to all intents and purposes C is open.
It isn't as if GCC doesn't know what the standard is, it isn't as if they can't describe GCC as a c compiler.
It's like saying a bsd or Linux isn't unix, just because they haven't paid some fee.
The C standard really isn't all that relevant in practice though,
for instance the Microsoft C compiler had been trailing the standard by about 2 decades until quite recently but this didn't stop people from using it. Also most C code that's written to compile across gcc, clang and msvc most likely doesn't even build with -pedantic on gcc or clang.
(eg in practice C is more like a language family, with an attempt to standardize a common core feature set and syntax as an afterthought and call that a "standard" - it's good that it exists, but it's hardly relevant or even useful for real world projects)
The thing about Mojo is that the part they spend most of their time promoting in their online material (Python but faster and good for AI) doesn't seem to require a new language at all, but rather a new hardware-aware Python compiler and some extra library modules.
It sure looks like they only turned it into a new language because they wanted to add static typing and immutable references, which maybe you care about and maybe you don't.
In that light it's hard for me to appreciate the development direction they've gone in.
It feels like it’s a nice language and, building on LLVM makes it stand on a solid foundation, but, still, it feels like a series of PEPs, some of which I can easily get behind.
If they make mojo modules callable from Python code, it all becomes a whole lot more palatable.
This seems like a huge effort and a pretty well rounded language. Could even succeed Python in some spaces. I like the syntax being unobtrusive as well.
I’d love to see it being used to write modules usable from Python code. This could provide a smooth migration path to apps that benefit less from Python’s dynamic nature and more from C-like speeds.
Those new language constructs are exactly what's enabling the performance gains, by giving reliable information to the compiler. Projects like numba have clearly demonstrated the limitations of trying to compile pure Python.
Most bottlenecks are IO. "speed" is rarely as important as it's marketed to be. Also rust shared libraries are already there for pretty much every language that you actually need speed
A new closed source programming language sounds like such a losing strategy.
Looking at the Mojo examples it seems like some kind of a superset of Python with lower language features. So you get C like performances if you’re willing to manipulate C like concepts. Truly revolutionary.
Chris Lattner seems like a great guy in interviews and has obviously mad multiple incredbile contributions to the field of software.
But I don't get the play here - a company CEO/cofounder bragging about the performance of a proprietary language which nobody can use right now? Who wants this?
Make the language and make it public and open; get large companies on board with development, start some useful real-world projects, involve the open-source community, show that it's actually good for something instead of giving investor presentations.
It’s Open Source code, but closed to contributions.
That would solve a lot of their problems because it allows them to show it’s open source, but not take contributions until they feel like it’s ready to get contributions from 3rd parties.
> Why not develop Mojo in the open from the beginning?
> Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.).
Given Chris Latners previous achievements I think we can trust this call a bit more than we may with some companies.
There are two undeniable facts: 1) the Python ecosystem has gone exponential. Its only really comparable to javascript in ubiquity but arguably addresses a much bigger problem space: it represents the closest to democratization of information processing since spreadsheets but with enormously wider applicability. 2) the computing hardware landscape that will enable the next stage of widely distributed information processing is a complete mess. Very difficult to utilize fully, monumental lock-in, etc.
Modular put 1+2 together and came with a proposal. Whether the rest will be history depends not so much on their technical ability to deliver but how they position this versus the vast potential user community. So far they follow a carefully choreographed VC driven marketing playbook that is kinda distasteful. Its not clear if this is a case of the end goal justifying the means.
People crying loudly for "open source" are on the one hand an indication of the governance and incentives challenges lying ahead. On the other hand they don't seem to be volunteering the massive salary spend that is required to move this mountain.
Minimally, this project helps outline what "good looks like" in this domain. If they fail to change the world there is always other talented people to try to retrace the path without taking the wrong turns.
For one, Python's popularity isn't "soaring", it peaked years ago.
For two, Python was originally designed as a teaching language to replace BASIC for entry-level programming courses, so it would be surprising if it wasn't popular.
It has lost track of the original vision in a big way, and I would bet that a decade from now something else will replace it as BASIC 3.0.
t. programming in Python since it was version 1.3.
I wish this had [podcast] or [audio] tag, since it's not a "blog" like the domain would imply. Clicking on the Transcript link just shows the same blurb as does the blog page, so I guess it's waiting for someone to transcribe it. Anyway, for sure "reading" a podcast is not the same as reading a blog post
58 comments
[ 2.6 ms ] story [ 153 ms ] threadI am curious about how much work the compiler does to automatically identify available hardware and distribute the load on its own vs how much you need to specify as a developer.
Unfortunately marketing like this tends to trigger an equal and opposite reaction in me.
Anyone with AI programming experience can comment on whether they have made any specific believable claims about performance?
And that company… whatsitsname… X?
In C’s defense it was made before search engines.
As of today, I’d bet it is niche like Julia, R, etc.
Yes, but that's also the issue they address. That you cant just write plain Python for something not covered by libraries and have it be fast. You need to then mess with extending with C, Cython, and so on.
[1] https://numba.pydata.org/
To make a conforming C compiler, someone has to buy the ISO C standard (208 CHF), which other folks will then spend development resources in creating C compilers that obey said standard.
The biggest open source compilers, clang and GCC, only keep being up to date with ISO C, because of the money from IBM, Red-Hat, Apple, ARM, Intel, Green-Hills,... place in assigning company resources to work on them.
Questions about the standard/specification are a different matter:
1. Whether the language has one? (Many languages, both open source and proprietary don't! I believe mojo doesn't have one?)
2. Whether it's available for free (gratis)?
3. Whether it's under a free (libre) license that allows redistribution with modifications?
In any case, it's my understanding that the C standards have largely been community driven efforts that formalized things already being done by major compilers like Gnu rather than driven by the technical needs of industry the way C++ has.
I thought having read it somewhere on one of those embedded forums like embedded.com.
Upon further investigation they are still using their own stuff.
https://www.ghs.com/products/compiler.html
I would debate that.
1. The C language spec isn't code, open source is only concerned with the code.
2. Philosophically, I would say that if you can write and compile standards conforming c code on an open source compiler, and the standard is freely available then to all intents and purposes C is open. It isn't as if GCC doesn't know what the standard is, it isn't as if they can't describe GCC as a c compiler.
It's like saying a bsd or Linux isn't unix, just because they haven't paid some fee.
(eg in practice C is more like a language family, with an attempt to standardize a common core feature set and syntax as an afterthought and call that a "standard" - it's good that it exists, but it's hardly relevant or even useful for real world projects)
It sure looks like they only turned it into a new language because they wanted to add static typing and immutable references, which maybe you care about and maybe you don't.
In that light it's hard for me to appreciate the development direction they've gone in.
It feels like it’s a nice language and, building on LLVM makes it stand on a solid foundation, but, still, it feels like a series of PEPs, some of which I can easily get behind.
If they make mojo modules callable from Python code, it all becomes a whole lot more palatable.
I love the LLVM ecosystem, will touch Mojo only when they evolve it and build more bridges with the regular Python ecosystem.
I’d love to see it being used to write modules usable from Python code. This could provide a smooth migration path to apps that benefit less from Python’s dynamic nature and more from C-like speeds.
Also reasoning about the borrow checker while doing hard math is a non starter for most people in the field.
in "your world", which aint the same for other ppl.
For web apps perhaps. They're not in that domain. In other domains IO is not the problem, CPU is.
>Also rust shared libraries are already there for pretty much every language that you actually need speed
Given that the whole selling point of this is to not have to use two languages, that's kind of irrelevant to this.
Not even for web apps. You should see how much CPU time a python web app spends doing simple things like filling an html template.
While Modular/Mojo aims to be this in the future I strongly feel their blog posting about a proprietary system runs contrary to their audience!
Looking at the Mojo examples it seems like some kind of a superset of Python with lower language features. So you get C like performances if you’re willing to manipulate C like concepts. Truly revolutionary.
But I don't get the play here - a company CEO/cofounder bragging about the performance of a proprietary language which nobody can use right now? Who wants this?
Make the language and make it public and open; get large companies on board with development, start some useful real-world projects, involve the open-source community, show that it's actually good for something instead of giving investor presentations.
It’s Open Source code, but closed to contributions.
That would solve a lot of their problems because it allows them to show it’s open source, but not take contributions until they feel like it’s ready to get contributions from 3rd parties.
> Why not develop Mojo in the open from the beginning?
> Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.).
Given Chris Latners previous achievements I think we can trust this call a bit more than we may with some companies.
I wouldn't use it myself until open sourced.
Modular put 1+2 together and came with a proposal. Whether the rest will be history depends not so much on their technical ability to deliver but how they position this versus the vast potential user community. So far they follow a carefully choreographed VC driven marketing playbook that is kinda distasteful. Its not clear if this is a case of the end goal justifying the means.
People crying loudly for "open source" are on the one hand an indication of the governance and incentives challenges lying ahead. On the other hand they don't seem to be volunteering the massive salary spend that is required to move this mountain.
Minimally, this project helps outline what "good looks like" in this domain. If they fail to change the world there is always other talented people to try to retrace the path without taking the wrong turns.
Eg will Django/Flask/FastAPI run significantly fast on Mojo than Python as-is?
(Somehow packaging Python scripts is a nightmare that gets worse with each passing year.)
For two, Python was originally designed as a teaching language to replace BASIC for entry-level programming courses, so it would be surprising if it wasn't popular.
It has lost track of the original vision in a big way, and I would bet that a decade from now something else will replace it as BASIC 3.0.
t. programming in Python since it was version 1.3.