Doesn’t mojo run only on a proprietary platform? You can’t run it on your machine for now, you don’t have access to the source code and you need to create an account just to try it out?
In this sense, it doesn’t matter how good Mojo his, golden cuffs are still cuffs.
I don’t understand why this comment continues to be repeated on every story involving a soon-to-be open sourced project. The FAQ answers your first question:
Will Mojo be open-sourced?
Yes, we expect that Mojo will be open-sourced. However, Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out. We don’t have an established plan for open-sourcing yet.
Many projects go this route because “open sourcing” can entail a lot, especially when you’ve been developing in private for a long time. First impressions are, sadly, one of the most important things you need to get correct. Go, Rust, Kotlin, and many other languages were private before going public. This is a good strategy because the development teams can iron out key user-facing issues (installation, OS support, documentation, community guidelines, etc.) after creating the initial prototype.
It is proprietary for now, and I would place a substantial bet on Mojo being open sourced before Jai lol.
A lot of projects that promised to open source never open sourced, or perhaps open sourced with too many strings attached.
Pointing out that it’s proprietary right now is valuable to many people, as they may want to hold off on evaluating it until the promised open sourcing happens.
If you want to keep your new whizzbang close to the vest, then DO THAT and don’t announce it to the world until I can put my hands on it and kick the tires.
That’s my subjective opinion anyway. WAY too much vapor in the world, and way too many amazing languages died on the vine because they had barriers to adoption that killed them (REBOL anyone?)
But that has nothing to do with its virtues as a language. You’re confusing the business practices of an implementor with the design of the language, or at least going off on a tangent.
It does, though, because languages are about doing things, not just debating syntax and semantics in a void. Interlisp was great because it had the Interlisp environment, a whole system with a structural editor and a nice GUI and good documentation, but that’s also what makes it more of a curiosity than a practical language these days. The environment only lives in an emulator, disconnected from the outside world. It’s a ship in a bottle. It would have to be reinvented entirely to become useful again.
Mojo is similarly constrained, even if its effective “bottle” is bigger, and just as at risk of being left behind.
I get where you’re coming from, but I think you’d need a more finely tuned phrase than “virtues of the language” because, as others have cited, ecosystem and availability are most DEFINITELY virtues.
Look at Perl, an ugly duckling for many, and yet there are MILLIONS of lines of it squirming around in production systems worldwide.
Why? Because it’s EVERYWHERE, runs on EVERYTHING, and has a VAST library of plug and play software in the form of CPAN.
These things matter.
Now, if you’re talking about the virtue’s of a language’s design STRICTLY on the syntax level, I could buy that maybe…
That was for the launch, I just watched this long interview and Lattner said they’re working on a release that you can download and run on your machine:
That would go a long way towards me seeing it as a real thing.
Open sourcing is important, but being able to actually kick the tires is moreso in my book at last in terms of evaluation.
Longer term, if it’s not open sourced, UNLESS it has a super duper compelling niche that makes it orders of magnitude better than the free solution, it will die.
In that sense, using that rubric, yeah, it’s something to ignore. However, the implementation choices and design are still interesting, so in that sense, it’s a compelling read.
The bit about the two language problem is interesting. On the one hand, I think it’s never actually going to be possible to just use one language. On the other hand, it’s interesting to figure out how one language can extend to more domains with smooth interop.
Yes, there is a conflict there. On the one hand, the case for having two languages is very strong, both in theory and in practice. On the other hand, the drive towards a unified language is also very strong, also both in theory and in practice.
The “obvious” solution seems to be commonality and variability analysis (see Parnas) and a metasystem that can capture both commonality and variability…which to me makes OO an obvious candidate (for the metasystem, not necessarily for the language itself)
It turns out that software architectural abstractions (components + connectors) are a good vocabulary for a connection language (components and connectors…). And it also turns out that a typical component language is a specialisation of a software-architectural language, as it is constructed from a specific set of connectors and components.
So problem solved: you make a software architectural connection language, and this will include the component language as a subset.
I think the relationship between Mojo and Python is interesting, but can you clarify what you think it is? There are no examples in the post, and the language isn’t generally available to try.
You are defining:
high level, dynamic module interconnection languages – Python, dynamic dispatch in objective C
fast, compiled component languages – C, Swift
And you are saying that Python is the “base” in Mojo, but C is the “base” in Objective C.
What is the ’base” language ? How do you know which one is the “base” ?
What is Objective S? It has a “smalltalk component language”, and then what else?
I just watched this GREAT interview with Lattner on Mojo, and he clarifies it. But the language is very nascent and changing.
What I gathered is that the static Mojo language embeds Python, and Python is also the comptime language Mojo. And maybe static Mojo is also the comptime language for Mojo.
You can do auto-tuning to discover good parameters for your functions with respect to running on a particular GPU (tiles, data and instruction widths, etc.)
Mojo/Python is AOT-compiled, JIT-compiled, and interpreted. It’s a syntax for MLIR. It’s big and complex.
Right now the relationship appears to be changing:
Python is def and class, and x = 42
Static Mojo is fn and struct, and var/let x = 42. It has static types and lifetimes like Rust. It can be compiled to a small piece of code that runs on GPUs. (avoiding malloc() on GPUs is one good reason for the Rust-like features.)
The Mojo runtime embeds the Python interpreter and lets you call methods on Python objects using the Python/C API
Mojo can also compile a small subset of Python now, and it’s intended to be a superset of Python in the future. This static subset is the source of the 35,000x speedup claim, which I get, but is “cheating” a bit. (Everybody already knows it’s easy to speed up a language with Python syntax that’s not Python.)
Overall my impression is that Mojo is Python + Julia + Rust + Zig, i.e. extremely ambitious.
Python for obvious reasons
Julia because the numeric types (int8, float64, etc.) are defined in Mojo, not in the compiler, just as Julia defines them in Julia. And also because it’s BOTH dynamically typed and statically typed – the exact relationship was not clear to me. It will probably change I’m sure. Julia has the notion of “type stability” to determine when compilation results in fast code.
Rust because of the lifetimes – and Mojo basically covers the whole space of C++, plus some more. async/await in Mojo uses Python syntax, but more efficient like Rust. He repeats in the interview that he has done enough C++ coding for one lifetime, and wants to stop. :)
Zig because of the arbitrary comptime – you don’t have a separate compile-time language like Rust; you just use Mojo/Python. (reminds me of the recent Rust keynote controversy)
Zig gets a very brief mention in the podcast – he calls out C++‘s template metaprogramming design as something to avoid. Rust gets a few mentions. And Julia too – he says he didn’t quite realize that Julia was reaching for this problem space, but also that “Julia is not Python”, and Python is the language of machine learning.
Part of the article that interests me is thinking about the two language problem, ie Unix is C plus Bash. The two language problem is a subset of the static vs dynamic problem. Static is faster and harder. Dynamic is slower and easier. And the problem recurs on multiple levels, ie unikernels vs normal OSes, static linking vs dynamic linking, static types vs dynamic types, compiled apps vs plug-in systems or interpreters, native apps vs Electron apps, etc etc.
My problem with Python today is that if I just want to run some scripts, Bash has less boilerplate. And if I need speed, Go is faster. So Python is getting squeezed out of the middle of a two language system for me. But TFA seems to posit that Python can grow out to cover more static ends of the spectrum. It’s an intriguing idea.
Yup it’s definitely an interesting problem. BTW I think the Julia language coined “the two language problem”, and they specifically “complained about” Python and C in scientific computing.
I think they did a great job in that domain, but Julia’s not a general purpose language.
I don’t think Mojo is either – Lattner says it’s machine learning first. (that implies a lot of exotic features like auto-tuning, auto-differentiation, GPU deployment, etc.)
Graydon wrote about “Ousterhout’s Dichotomy” several years ago – Ousterhout being the author of Tcl which was designed to integrate with C:
I agree that using bash + Python + Go is more annoying than just 2 languages. 3 is worse than 2 ! Oils is trying to fold some of those use cases in, but it’s hard :)
I never used Objective C, but it does seem like a good mix of Smalltalk/Python + C, with an unfamiliar syntax. It never seemed to make it outside Apple’s ecosystem though.
But also Apple did not use it for “shell scripting”; it was more for gluing objects together I suppose.
People at my office seem to think that they’re going to be able to “switch to Mojo” and just keep on writing Python code, and somehow get amazing speed ups. That sounded too good to be true to me (especially as we’re mostly using pandas, numpy etc which are already using C or whatever under the hood).
Seems like the faster-than-Python part of Mojo is the stuff that’s in the “superset” (ie not vanilla Python). Is that about right?
After watching the podcast, I think Mojo is very cool though. It makes a lot of sense in a lot of ways. The team is extremely accomplished and knows way more than me about languages. And they already did some impressive stuff integrating CPython.
They are working on a downloadable version, so I’ll definitely check it out then. I really wonder what all the caveats will be when you type “import pandas” – is it going to crash? Or it will fall back to CPython? And you copy from CPython to Mojo, or sometimes you can manipulate the dynamic Python objects from static Mojo code?
Or do you have to type “py import pandas” from Mojo, etc. ?
That is the part that was unclear to me, and the podcast sorta addressed that, but not fully. But he also said Mojo is something like 7 months old. So yes the “sell” made people think it was a lot further along than it is.
It sounds like you will definitely be able to write a Rust-ish language in Python syntax, and it will be fast, and deployable to a GPU. But that’s a totally different thing than “import pandas”.
“Objective-C solved the two language problem by just jamming the two languages into one: Smalltalk for the scripting/integration and C for the component language.”
Not as used in NeXTStep or anywhere else I’ve ever seen.
“Except it doesn’t repeat Objective-C’s mistake of using the component language as the base (which, inexplicably, Swift didn’t just repeat, but actually doubled down on by largely deprecating objects).”
Functional programming is the current hotness just as OOP was the current hotness in the 80s.
Swift deprecating objects is explicable given that.
ObjC: Smalltalk for the integration, C for components
Not as used in NeXTStep or anywhere else I’ve ever seen.
We had every language under the sun integrated with Objective-C using the runtime, almost exactly as envisioned by Brad Cox. We had WebScript. And up to ~3.3, the libs were also built that way.
But yes, people started using it more as a unitary language, something it wasn’t really particularly good at. This was partly pushed by NeXT (and later Apple) with Foundation and by people who thought of ObjC as a poor Java. Which again, it is, if you make the mistake of treating it as a Java.
And Foundation definitely was an improvement in many ways, so it’s an interesting case study for how local improvements can lead to globally worse outcomes.
And of course “you’re just holding it wrong” is not a satisfactory explanation, even if it’s correct. If pretty much everybody ends up holding it wrong, there’s something deeper going on.
One reason is that Smalltalk dynamic OO is still not a good enough integration language. It’s significantly better than most things out there, but still not good enough, as most integration problems are not essentially procedural, and late-binding only helps you so far. You need to be able to express dataflow, state-based integration (REST), implicit invocation, dataflow constraints, etc. (Express, not just implement). In addition to dynamic OO. In other words: you need to be able to program in different architectural styles. Meaning you need to be able to program with (and define) different architectural connectors.
Another reason people hold it wrong is that the computational models are too close, which is problematic if you’re going to just shove these languages into each other. Particularly when the integration language is also more convenient, people will start to program the components with it, and then you get mission creep. Most iOS devs. would not touch the “C” parts of Objective-C. In fact, it was routinely regarded as a different language entirely.
Of course, you can also use the closeness to your advantage, because it turns out that the procedural/functional component implementation language can be a specialisation of the dynamic OO part of the (architectural) connection language.
Swift deprecating objects [due to FP being the new hotness]
The inexplicable part is not using FP as the new hotness, it is the mistake of doubling down on focusing on the component language, because FP is suitable as a component language, not as a connection language (for example, Functional Core, Imperative Shell ).
Doesn’t mojo run only on a proprietary platform? You can’t run it on your machine for now, you don’t have access to the source code and you need to create an account just to try it out?
In this sense, it doesn’t matter how good Mojo his, golden cuffs are still cuffs.
I don’t understand why this comment continues to be repeated on every story involving a soon-to-be open sourced project. The FAQ answers your first question:
Many projects go this route because “open sourcing” can entail a lot, especially when you’ve been developing in private for a long time. First impressions are, sadly, one of the most important things you need to get correct. Go, Rust, Kotlin, and many other languages were private before going public. This is a good strategy because the development teams can iron out key user-facing issues (installation, OS support, documentation, community guidelines, etc.) after creating the initial prototype.
It is proprietary for now, and I would place a substantial bet on Mojo being open sourced before Jai lol.
A lot of projects that promised to open source never open sourced, or perhaps open sourced with too many strings attached.
Pointing out that it’s proprietary right now is valuable to many people, as they may want to hold off on evaluating it until the promised open sourcing happens.
That sounds like an aspiration. It doesn’t sound “soon-to-be open sourced” for any definition of “soon” that I like.
I do, for exactly the reasons others have cited.
If you want to keep your new whizzbang close to the vest, then DO THAT and don’t announce it to the world until I can put my hands on it and kick the tires.
That’s my subjective opinion anyway. WAY too much vapor in the world, and way too many amazing languages died on the vine because they had barriers to adoption that killed them (REBOL anyone?)
But that has nothing to do with its virtues as a language. You’re confusing the business practices of an implementor with the design of the language, or at least going off on a tangent.
Why does the discussion need to be limited to the virtues of the language?
Language and ecosystem are intimately intertwined.
If someone claims “X is a better Y than Z” then of course all the factors concerned with actually using it must be considered.
Making broad claims means taking into account broad concerns. Want to limit these considerations? Limit the claim being made.
It does, though, because languages are about doing things, not just debating syntax and semantics in a void. Interlisp was great because it had the Interlisp environment, a whole system with a structural editor and a nice GUI and good documentation, but that’s also what makes it more of a curiosity than a practical language these days. The environment only lives in an emulator, disconnected from the outside world. It’s a ship in a bottle. It would have to be reinvented entirely to become useful again.
Mojo is similarly constrained, even if its effective “bottle” is bigger, and just as at risk of being left behind.
I get where you’re coming from, but I think you’d need a more finely tuned phrase than “virtues of the language” because, as others have cited, ecosystem and availability are most DEFINITELY virtues.
Look at Perl, an ugly duckling for many, and yet there are MILLIONS of lines of it squirming around in production systems worldwide.
Why? Because it’s EVERYWHERE, runs on EVERYTHING, and has a VAST library of plug and play software in the form of CPAN.
These things matter.
Now, if you’re talking about the virtue’s of a language’s design STRICTLY on the syntax level, I could buy that maybe…
That was for the launch, I just watched this long interview and Lattner said they’re working on a release that you can download and run on your machine:
https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=142s
I don’t know if it will be open sourced at the same time.
That would go a long way towards me seeing it as a real thing.
Open sourcing is important, but being able to actually kick the tires is moreso in my book at last in terms of evaluation.
Longer term, if it’s not open sourced, UNLESS it has a super duper compelling niche that makes it orders of magnitude better than the free solution, it will die.
In that sense, using that rubric, yeah, it’s something to ignore. However, the implementation choices and design are still interesting, so in that sense, it’s a compelling read.
The bit about the two language problem is interesting. On the one hand, I think it’s never actually going to be possible to just use one language. On the other hand, it’s interesting to figure out how one language can extend to more domains with smooth interop.
Yes, there is a conflict there. On the one hand, the case for having two languages is very strong, both in theory and in practice. On the other hand, the drive towards a unified language is also very strong, also both in theory and in practice.
The “obvious” solution seems to be commonality and variability analysis (see Parnas) and a metasystem that can capture both commonality and variability…which to me makes OO an obvious candidate (for the metasystem, not necessarily for the language itself)
It turns out that software architectural abstractions (components + connectors) are a good vocabulary for a connection language (components and connectors…). And it also turns out that a typical component language is a specialisation of a software-architectural language, as it is constructed from a specific set of connectors and components.
So problem solved: you make a software architectural connection language, and this will include the component language as a subset.
I think the relationship between Mojo and Python is interesting, but can you clarify what you think it is? There are no examples in the post, and the language isn’t generally available to try.
You are defining:
And you are saying that Python is the “base” in Mojo, but C is the “base” in Objective C.
What is the ’base” language ? How do you know which one is the “base” ?
What is Objective S? It has a “smalltalk component language”, and then what else?
I just watched this GREAT interview with Lattner on Mojo, and he clarifies it. But the language is very nascent and changing.
https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=142s
What I gathered is that the static Mojo language embeds Python, and Python is also the comptime language Mojo. And maybe static Mojo is also the comptime language for Mojo.
You can do auto-tuning to discover good parameters for your functions with respect to running on a particular GPU (tiles, data and instruction widths, etc.)
Mojo/Python is AOT-compiled, JIT-compiled, and interpreted. It’s a syntax for MLIR. It’s big and complex.
Right now the relationship appears to be changing:
x = 42var/let x = 42. It has static types and lifetimes like Rust. It can be compiled to a small piece of code that runs on GPUs. (avoiding malloc() on GPUs is one good reason for the Rust-like features.)Overall my impression is that Mojo is Python + Julia + Rust + Zig, i.e. extremely ambitious.
Zig gets a very brief mention in the podcast – he calls out C++‘s template metaprogramming design as something to avoid. Rust gets a few mentions. And Julia too – he says he didn’t quite realize that Julia was reaching for this problem space, but also that “Julia is not Python”, and Python is the language of machine learning.
Part of the article that interests me is thinking about the two language problem, ie Unix is C plus Bash. The two language problem is a subset of the static vs dynamic problem. Static is faster and harder. Dynamic is slower and easier. And the problem recurs on multiple levels, ie unikernels vs normal OSes, static linking vs dynamic linking, static types vs dynamic types, compiled apps vs plug-in systems or interpreters, native apps vs Electron apps, etc etc.
My problem with Python today is that if I just want to run some scripts, Bash has less boilerplate. And if I need speed, Go is faster. So Python is getting squeezed out of the middle of a two language system for me. But TFA seems to posit that Python can grow out to cover more static ends of the spectrum. It’s an intriguing idea.
Yup it’s definitely an interesting problem. BTW I think the Julia language coined “the two language problem”, and they specifically “complained about” Python and C in scientific computing.
I think they did a great job in that domain, but Julia’s not a general purpose language.
I don’t think Mojo is either – Lattner says it’s machine learning first. (that implies a lot of exotic features like auto-tuning, auto-differentiation, GPU deployment, etc.)
Graydon wrote about “Ousterhout’s Dichotomy” several years ago – Ousterhout being the author of Tcl which was designed to integrate with C:
https://graydon2.dreamwidth.org/3186.html
https://graydon2.dreamwidth.org/189377.html
I agree that using bash + Python + Go is more annoying than just 2 languages. 3 is worse than 2 ! Oils is trying to fold some of those use cases in, but it’s hard :)
I never used Objective C, but it does seem like a good mix of Smalltalk/Python + C, with an unfamiliar syntax. It never seemed to make it outside Apple’s ecosystem though.
But also Apple did not use it for “shell scripting”; it was more for gluing objects together I suppose.
People at my office seem to think that they’re going to be able to “switch to Mojo” and just keep on writing Python code, and somehow get amazing speed ups. That sounded too good to be true to me (especially as we’re mostly using pandas, numpy etc which are already using C or whatever under the hood).
Seems like the faster-than-Python part of Mojo is the stuff that’s in the “superset” (ie not vanilla Python). Is that about right?
Yeah I can’t tell what will happen, but it won’t be that simple, at least not soon.
Here is my speculative 4-level hierarchy of implementing Python-like languages, with running NumPy and Pandas dead last - https://lobste.rs/s/qbcjsl/mojo_future_ai_programming#c_a5vgqv
After watching the podcast, I think Mojo is very cool though. It makes a lot of sense in a lot of ways. The team is extremely accomplished and knows way more than me about languages. And they already did some impressive stuff integrating CPython.
They are working on a downloadable version, so I’ll definitely check it out then. I really wonder what all the caveats will be when you type “import pandas” – is it going to crash? Or it will fall back to CPython? And you copy from CPython to Mojo, or sometimes you can manipulate the dynamic Python objects from static Mojo code?
Or do you have to type “py import pandas” from Mojo, etc. ?
That is the part that was unclear to me, and the podcast sorta addressed that, but not fully. But he also said Mojo is something like 7 months old. So yes the “sell” made people think it was a lot further along than it is.
It sounds like you will definitely be able to write a Rust-ish language in Python syntax, and it will be fast, and deployable to a GPU. But that’s a totally different thing than “import pandas”.
This seems too profound for me.
Ahh…sorry. And thanks: fixed!
Isn’t this just a matter of evolution since Lattner is the same person who created Swift and has now created Mojo?
I think “just” is doing a lot of work in that sentence :-)
And I also think you’ve nailed it.
People tell me that first thing a lot.
[Comment removed by author]
I’m still waiting on this becoming free software.
“Objective-C solved the two language problem by just jamming the two languages into one: Smalltalk for the scripting/integration and C for the component language.”
Not as used in NeXTStep or anywhere else I’ve ever seen.
“Except it doesn’t repeat Objective-C’s mistake of using the component language as the base (which, inexplicably, Swift didn’t just repeat, but actually doubled down on by largely deprecating objects).”
Functional programming is the current hotness just as OOP was the current hotness in the 80s.
Swift deprecating objects is explicable given that.
We had every language under the sun integrated with Objective-C using the runtime, almost exactly as envisioned by Brad Cox. We had WebScript. And up to ~3.3, the libs were also built that way.
But yes, people started using it more as a unitary language, something it wasn’t really particularly good at. This was partly pushed by NeXT (and later Apple) with Foundation and by people who thought of ObjC as a poor Java. Which again, it is, if you make the mistake of treating it as a Java.
And Foundation definitely was an improvement in many ways, so it’s an interesting case study for how local improvements can lead to globally worse outcomes.
And of course “you’re just holding it wrong” is not a satisfactory explanation, even if it’s correct. If pretty much everybody ends up holding it wrong, there’s something deeper going on.
One reason is that Smalltalk dynamic OO is still not a good enough integration language. It’s significantly better than most things out there, but still not good enough, as most integration problems are not essentially procedural, and late-binding only helps you so far. You need to be able to express dataflow, state-based integration (REST), implicit invocation, dataflow constraints, etc. (Express, not just implement). In addition to dynamic OO. In other words: you need to be able to program in different architectural styles. Meaning you need to be able to program with (and define) different architectural connectors.
Another reason people hold it wrong is that the computational models are too close, which is problematic if you’re going to just shove these languages into each other. Particularly when the integration language is also more convenient, people will start to program the components with it, and then you get mission creep. Most iOS devs. would not touch the “C” parts of Objective-C. In fact, it was routinely regarded as a different language entirely.
Of course, you can also use the closeness to your advantage, because it turns out that the procedural/functional component implementation language can be a specialisation of the dynamic OO part of the (architectural) connection language.
The inexplicable part is not using FP as the new hotness, it is the mistake of doubling down on focusing on the component language, because FP is suitable as a component language, not as a connection language (for example, Functional Core, Imperative Shell ).
Hype train is real. No one (less than X people) saw this language, so who cares.