[edited] afaict:
1) Mojo isn't opensource (yet?)
2) I can't test mojo (yet?)
3) Mojo does bold claims like being a better python with performance close to C, like V did, yet no one seems to call them out (yet????)
Anyway, never gonna try it, unless I'm absolutely forced.
I hate their marketing strategy, it sounds too bad.
I chuckled a bit when I saw that they market themselves as "faster than C". Is it 2005 again? Do modern developers even have any notion of how fast C runs to use as a baseline?
It's really minor thing but a pet peeve of mine, I remember how twenty years ago every new language claimed to be as fast or faster than C, and every time the benchmark was some ultra-optimized non-idiomatic program in that new language against a naive C implementation, and the C version was usually still 20% faster and use 10% as much RAM with the right compile flags.
Are there even Mojo benchmark in the wild? The FAQ entry[1] just finds excuses for situations where it does not perform well...
The benchmarks they give here [1] show generic code on par with specialized libraries that are typically written in assembler. These are vastly faster than naive C implementations, so your pet peeve really does not apply here.
Lattner being behind Mojo always engendered some benefit of the doubt despite my initial gripes with the marketing claims, but his recent interview with Lex Fridman [1] further emboldened my stance that if Mojo can succeed, Lattner is one of the best-positioned engineers to see it through.
I know nothing about low-level optimizations, but I love playing with different methods and benchmarks. And did try Mojo through their playground. I found it a bit more complicated than anticipated (well, I did believe it's just like python but much faster...) but also very impressive speed.
It's impossible to say for sure, since you can't run the benchmark on your machine and god knows what's behind the playground. However, I compared my naive implementation to find min of a rolling mean using python with numba, pandas, polars, numpy and mojo version.
Mojo version was faster than polars and numpy, which in turn were faster than pandas and numba.
That's my N=1 of course, and not a reliable benchmark. But still, I find it very impressive.
It's worse than obnoxiousness; the posture they have taken engenders skepticism and distrust.
When making technical claims to a technical audience, and vs Lattner leveraging reputation,
the appropriate approach is clearly not this. It's to lead with conservatively stated claims, reproducible results, and all the rest of the apparatus that is collectively understood as how adults (from which I exclude bizdev) demonstrate a better mousetrap, into an environment within which the cost of switching mousetrap technology is very great indeed at every level.
For anyone interested on why a VC would fund a PL, modular attempts to build the new shovels for the AI revolution; meaning their own platform to develop models.
Sure, I should have been clearer, what I had in mind was more "do potential users of Mojo even know or care about how fast C is?"
In my experience the new generation of devs haven't touched C and treat it like some kind of weird arcane language, a bit like what Fortran and COBOL were when I started coding around 2000.
> ..."do potential users of Mojo even know or care about how fast C is?"
I doubt their potential users would care so much, as long as it's significantly faster than Python and they don't need C or C++, except as an option and not as a necessity. That's been the point of various other alternative languages.
The claim to fame of various newer compiled languages, is not just being as fast as C, but that they are better alternatives to use, for their audiences. Being easier to use, read, or/and learn. This is where some of the drama comes from, because some will make it about speed, and ignore the other elements of what is "attractive".
New generation here, I don't see why I would ever code in actual C99 when (at worst) I could just code in C-style C++ but have some of the nice things.
The only reason for coding directly in C without using any C++ features would be if you have to contribute to a code base that is restricted to C. The Linux kernel being the most prominent example, but also a lot of embedded devices.
Didn’t that team at Apple (with Lattner at the helm) also claim Swift was “faster than C”? I am yet to be convinced that in the general case, this is true, especially with the recent language bloat and lack of substantial compiler optimizations. But it wasn’t true back when Swift was released either.
I mean.. it does depend on what you mean by "faster than C" of course. Writing the straight forward naive solution in Mojo for some problems can produce code that can run on both CPUs and GPUs and be super fast. Can you get the same performance from C? Probably.. with lots on intrinsics and one code base for GPUs and one for CPUs, where the GPU codebase might even be multiple code bases for different vendors.
I would say "faster than C if you want to keep your sanity and don't have infinite time". It doesn't roll off the tongue though :P
I know you didn't mean exactly 20 year old languages but felt the itch to look it up - 2003 was a year of JVM languages[1]. Groovy and Scala are dated 2003. (Clojure came a bit later, in 2007)
Because the claim is not as outrageous as V did? V claimed to solve the memory management problem automatically without a VM, which no one knows how to solve... Mojo seems to have a strategy similar to Rust, which requires user annotation and we know that this is sufficient in the majority of cases, so I don't think this is something seemingly impossible. Of cause, whether or not this is as easy to use as Python is debatable...
For performance, if the compiler backend performs enough optimization, the code is run natively without any VM, the performance can be same or better than C (as some language features may provide more optimization opportunities). At the end of the day, C programs are compiled into some IR code and optimized by the backend as well, so the frontend language is more about balancing limitation for optimization and expressiveness.
I do feel a bit uncomfortable about their marketing strategy, which compares a simple implementation against one with SIMD and parallelization... I think the real win here is simpler SIMD/parallel programming comparing with C/C++, instead of the language itself being faster.
It looks like the Mojo work in parts grew out of MLIR and Lattner has repeatedly stated that he wants less compiler magic and more control in the hands of the programmer (indeed MLIR, which Clang might also move to [1], is directly exposed in Mojo).
"Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;)
> he wants less compiler magic and more control in the hands of the programmer
Indeed, I can see this from their emphasis on generic SIMD, which looks pretty nice. It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library or autovectorization which may not work.
> "Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;)
Seems so. I don't recall reading the claim about running arbitrary Python code, and I think requiring rewriting Python code is reasonable as normal Python code may utilize runtime reflection/dynamic type and they are hard to implement efficiently, and probably require a GC for memory management.
> It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library
If the language is flexible enough (in particular, it has to support operator overloading), I don’t see any disadvantages to implementing that in a library.
Although not as outrageous as V, I do find the Mojo claims a little misleading.
On the main page of the website, they claim it lets you "Write everything in one language" and "Unlock Python performance" – but what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.
Didn't Mojo just come out? What Mojo will become in regards to Python, remains to be seen. This will likely take them years. Passing judgment on the project so early, is obviously premature.
> Although not as outrageous as V...
Comes across as adding drama. Like arguing with one guy, then slapping another who wasn't involved, thinking it will be funny or because one might get away with it.
> V doesn't use garbage collection or reference counting. The compiler cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free.
Plus we are talking about a free open-source project, that's more of a grassroots effort, that didn't start as a corporate plan and creation. There are others contributing and writing documentation (and they aren't all English experts). Mistakes will happen and changes are allowed (many for the good). The language is not 1.0 yet, so should be allowed and will evolve/change over time (as other languages before it).
People are also free to join the project or directly make helpful suggestions. That's part of the point of open-source.
Yeah, this docs section was not synchronized with the landing page, and had bad wording. It says "work in progress", meaning that's something that's planned/being investigated.
This was later worded better. But I agree, the docs should have never had such wording.
It seems that this language is deeply integrated with CPython, so I doubt if it can be used as a low level language alone. If yes, they probably need to disable a bunch of things.
Also, it is still WIP so I am not sure how things like type works in this language, whether or not it support parameterized lifetime, reference counted objects, union type, closure, etc. Currently, they seems to be focusing on numerical applications, targeting the AI crowd, so it is uncertain how things will go later.
> Mojo seems to have a strategy similar to Rust, which requires user annotation
Except that it also claims to be a superset of Python. That is, you can use it to run any Python program without changes. So explain to me how it’s faster than C while also literally being Python. That’s more outrageous than V.
It’s a superset. You can run regular python, and that won’t be faster than C. But you can also write mojo functions (using “fn” instead of “def”) and those have stricter requirements and more user annotations but also more optimization potential. Mojo function could be faster than C, buts it’s not free.
> what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.
In my opinion, asking clever questions actually is quite important in an interviewer and Lex Fridman is no Joe Rogan in terms of letting the other person talk.
Yeah I've only seen a few clips of him but the questions he asks are so boring, and asking good questions is THE essential skill for a good interviewer.
He had John Carmack on his show which piqued my interest, but he was asking questions like "what's the best programming language" and "what's the best IDE." Such a blown opportunity to be asking useless first year CS student questions like that when interviewing a great mind like Carmack.
He once asked Jim Keller 'What is Love?'.
His interview with Grant Sanderson is cathartic in that Grant has very little patience for that kind of questioning, when Lex goes on about 'isn't e^iπ so pretty', Grant responds to the effect 'not if you actually understand it, it's math'.
I saw a quote on reddit that does a great job helping me understand my distaste for these kinds of questions: 'The man who loves everything and everyone, loves only himself.'
Those are solid examples, you’re right. The “isn’t this math thing beautiful?” and “don’t you love love?” digressions are banal, but I give him a pass because a) the guests are interesting people who say interesting things and b) in Lex’s world I guess it’s unusual to slow down and smell the roses.
It makes sense to get touchy-feely with Bert Kreischer, who’s basically an alcoholic gigantic third grader. Or with Michael Malice because they’re goofy best buds.
Still it’s nice when a serious guest kind of shrugs and sticks to the topic.
I can’t listen to Neil Degrasse Tyson talk because of that same kind of “the wonder of the poetry of the cosmic ballet” nonsense.
Not being able to ask clever questions is the problem though, because once you've heard one of his guests speak elsewhere, you're getting a basic repeat through Lex.
His podcast is alright for people who aren't in any of the domains and therefore just want overviews. Anything else, and it's about as useful as listening to an actor repeat the summary for the movie they're promoting for the millionth time.
He claims to not have any bias whatsoever and be an absolute centrist, which leads to him being a pawn on whatever his guests want to promote while also asking the most awful, bland questions he can possible think of
It's pretty clear he's playing up some kind of "rainman autistic AI savant" persona, and also, he exaggerates his credentials. On his website he describes himself as:
>AI researcher working on autonomous vehicles, human-robot interaction, and machine learning at MIT and beyond
Which could lead one to erroneously assume that he attended MIT, or even has a degree from MIT, when neither of which are true.
If someone says they're "working at <institution>", I don't assume some counterposition to their statements, like that they're really trying to say that it's their alma mater. I interpret it to mean that they're working there.
So for your wish of someone else instead of Lex to be granted... (1) the hypothetical "more intelligent interviewer" you'd prefer has to ask CL to be interviewed -- and -- (2) in turn, CL has to say "yes" to the interviewer.
So far, Lex got (1) and (2) to happen. (Three times.) So here we are. Any suggestions on who else should interview CL and would CL grant the interview?
It’s a long interview, you can skip through if you want. I’m impartial to Lex Friedman, I just enjoy long interviews and a lot of his guests give me a lot to digest.
Lex Friedman[0][1][2] (with an “E”) would probably prefer not being confused with Lex Fridman[3][4][5] (without an “E”), the host of the interview linked above.
Thanks for posting the Kelley talk. It was interesting but I think also incomplete. Change occurs because nothing is forever. The foundation approach seems better than many, but I think that Kelley has an overly rosy view of foundations and excessively negative view of for-profits. There doesn't seem to be a documented method of voting for new board members, etc. It looks to me like a limited partnership set up as a nonprofit to enable donations. Not a problem, except it still has the same problems that Kelley describes SQLite as having.
Open-sourcing is a double-edged sword. Young ideas are fragile and if they open source the project now, they'll have to deal with entitled people and trolls instead of investing their time developing the project. They have said, though, they are going to open-source the project eventually like Swift.
Also the team behind the project includes very smart people with a history of delivering other great projects (LLVM, Clang, MLIR and Swift).
I don't see how discouraging other people for trying to innovate is helpful. In the end this project could benefit all of us.
> I don't see how discouraging other people for trying to innovate is helpful.
That's debatably where the trolling, misinformation, and other underhanded tactics come in. Maintaining the status quo and protecting one's interests, even to the detrimental of the whole, fairness, or the greater good.
You can try it in the form of a jupyter notebook. I'd much prefer just to use it like a regular language.
I think their strategy makes quite a bit of sense. Superficially Python like, can use Python libraries, fast and safe like Rust, automatically determines where algorithms should run (to some extent).
One thing that comes to mind however, is library performance. I'm assuming it will be ~3X faster than Python (like basic Python code) but if you are coming from Rust or C, this could be an issue.
Swift wasn't initially open-source either. I remember this because I was like, nope fuck that shit until it's open source so I never touched Swift until Swift 2.0 when they open sourced it.
(Actually IIRC I started learning it when they promised to open source it later that same year. So the actual moment of open-sourcing might have been slightly later.)
I signed up to try it this weekend and they gave me my own jupyterlab instance with a getting started notebook in ~5 minutes.
I thought it was odd at first that they weren't letting me run it locally too, but if they control the compute environment then they can force push interpreter(?)/compiler updates and eliminate a lot of bug reports from folks that are just using an out of date build. Seems pretty reasonable to me for something that's so early in development.
> 3) Mojo does bold claims like being a better python with performance close to C, like V did, yet no one seems to call them out (yet????)
There appears to be confusion here. Mojo is trying to align itself with and be a kind of superset of Python, like C++ was to C. It's also an alternative for Python users, to use it, instead of reaching for C++ or C when they need speed or going lower level. From their website, that's not what V devs ever claimed nor is it their angle for users. V is a different programming language (and compiled), which provides benefits such as greater speed, type safety, etc... in comparison to Python. It would be a switch over, not a superset.
V is more of an alternative to Go and then C (in terms of ease of use and greater safety). Mojo and V are mostly in different lanes, where they appeal to different audiences, and how they are marketing themselves has nothing to do with the other.
> Anyway, never gonna try it, unless I'm absolutely forced. I hate their marketing strategy, it sounds too bad
This comes across as weird, to claim one will never use or gives the impression to never have used the programming languages they are talking down on. If not using Mojo or V, why be so preoccupied? Just skip over to what one does like and not be worried.
> ...hate their marketing strategy
Just about all programming languages attempt to sell themselves to the public. If they don't, people don't hear about them, and they die in obscurity.
And a lot of times, people are allowing themselves to be brainwashed by what big corporations have to sell, because they have big budgets for marketing. People often like, what big companies told them to, because of their infomercials and marketing campaigns. Sometimes, it can be good or at least fair to give alternatives a shot.
On the front page of their website, they claim to have full compatibility with python code, an ownership model and a borrow checker, and being as fast or faster than C++. These are just some of the first things I noticed!
Apparently one of the people involved with the creation of this language have some credibility which is pretty confusing. They are the CEO of the company behind "mojo" as well.
I think this is going to be another V-lang situation personally, despite the credibility of Lattner. I think this is just someone seeing an opportunity to cash in on the "AI hype" situation that exists currently.
Even reputable people can be influenced to do shady things when lots of money is involved!
This is of course just my opinion and I wouldn't mind being proven wrong, but I'm definitely very skeptical right now!
> I think this is going to be another V-lang situation personally, despite the credibility of Lattner. I think this is just someone seeing an opportunity to cash in on the "AI hype" situation that exists currently.
Mojo is not only directed at AI, but at Python users as an alternative and superset. The use of it for AI, is partially based on the use case of Python. Insinuating that Mojo is trying to "cash in" on "AI hype", is odd in the context of all the others who clearly do so, but where is the "cash in" at? Mojo and Vlang are free.
Vlang (V-lang) has made no such marketing claims in regards to AI, so pairing the languages together comes across as odd. If the argument is about "cashing in", that looks even weirder. The users of both languages can get it for free. As with any programming language, there can be donations and sponsors. Why would it be a problem for Mojo or Vlang to have sponsors, but somehow not so for other competing languages, in regards to their claims? This comes across as at least one is fine with their favorite language getting sponsors or donations, but not others. Or maybe hoping to cut the funding sources of new languages, so there will be less competition.
> Even reputable people can be influenced to do shady things when lots of money is involved!
The accusation or insinuation is being made that Lattner is "shady" for money, while a backhand is being thrown at Vlang too. Outside of throwing smears, there is no proof of them being in it for hustling money or doing anything that different from what competing programming language creators have and are doing. And that's without talking about the corporate created languages, where obviously money and market share are major driving forces for them.
They're also using Discord for official comms, which kills it for me. Even if they release their source properly, I doubt you'll ever get them off Discord, and I would never go there for help.
Didn't learn much from article why Mojo supposed to be better than Swift from a grass root user perspective:
1) Will Mojo provide seamless interop with C like objective-c?
2) Will Mojo provide seamless interop with C++ like objective-c? All I have to do is changing file extension from '.m' to '.mm' and can use all C++ features
3) Will Mojo be available to be compiled for iOS and Android?
Swift doesn't have good interop with C but at least have decent interop with Objective-C (works most of the time but if you have some more complex code with Swift using Obj-C and Obj-C using Swift things can be nasty to figure out why it suddenly doesn't automagically work.
In upcomming iOS 17 Swift have some interop with C++ but haven't tested the details yet how smooth it is.
I would happily use Mojo if:
1) Can be compiled for iOS/Android
2) Has seamless interop with C/C++/Objective-C and maybe even Rust
That would be enough killer features for me
Dealbreaker for me with Python is not really good support for mobile apps even if you just want to use it for prototyping instead of production code. Most native pip modules are not supporting mobile architectures out of the box and don't have many wheels.
And of course it's not really "seamless inter with C", because Objective-C just is C, or more specifically a superset of C. It's sort of "interop with yourself". Of course, most Objective-C programmers do treat C as a distinct language, and one that they won't touch. Which is interesting.
And you are right, the article wasn't really about whether it is a better language overall, particularly not from the grass root user perspective.
It was about the specific aspect of being an "Objective-C without the C".
Which, of course, is just Smalltalk when taken literally. But if you just use Smalltalk, you lose Objective-C's capability of going really fast as well (and the interop).
Of course using Python instead of Smalltalk as the base is sad, but it is understandable given the market that they're going for.
Some pointer aritmetic in Swift i found it painful to do when calling some C library - it was much easier to create some wrapper in ObjC and do low lever pointer manipulation there. This is what I call it seamless - if I have to do some low level image/texture preprocessing it's still easier to do it in ObjC
It is Python with the ability to write high performance code within specified functions, eliminating the need to link in C code. However the interop with C will be the same as Python, which is already very good, Mojo is just going beyond that.
It compiles to llvm. This means the python environment headaches will disappear.
> It is Python with the ability to write high performance code within specified functions
It might become that (personally I doubt it, but that's the stated goal). It isn't now. Not really close even. No kwargs, no python classes for example.
> It compiles to llvm. This means the python environment headaches will disappear.
Weeeeell. Not if you want to use any Python library. Because then it just calls into CPython. And that's a huge part of why Mojo is interesting in the first place. So I would say no.
Yes, in the benchmarks it’s competitive and compiled programs stay tiny unlike Python which packages the interpreter. According to the story being told, it could end up a sort of one-language-to-rule-them-all. Python was chosen by Chris Lattner specifically for his wide spread adoption and Mojo is sometimes called Python++.
I don’t understand the essential claims of this, which I think are
“Mojo […] 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).”
What does “largely deprecating objects” mean, and why would it imply “using the component language as the base”?
and
“it turns out that the connection language is actually the more general one, the component language is a specialisation of the connection language.”
I don’t understand that at all. You have a “blue collar” layer where bytes and bits get shuffled around and hands get dirty and a “white collar” layer where programmers pretend the world is made of legos and there’s no need to get your hands dirty to write programs.
A language can decide to only support the white collar layer, but if so, you still need a blue collar one in your interpreter/compiler/runtime (or, potentially, hardware)
You can, however, decide to only support the blue collar layer. C without the standard library does that, for example.
It's just a description of how the languages were designed.
With Objective-C, they started with the "blue collar" language (C) as the base language, and added in "white collar" language features (Smalltalk), to achieve a language where you could switch between blue collar and white collar programming without switching languages.
Mojo starts with the white collar language (Python) and adds blue collar language features to it (the Mojo additions that allow you to control the memory layout and execution at a lower level).
But IMO Swift started white-collar, too, with its reference-counting, abort-on-integer-overflow, copy-on-write collections, characters whose size in bytes isn’t fixed, no (or limited, being GCD-only? I don’t remember exactly) multithreading, etc.
Yes, it was presented as being a systems language, too, but that convinced very few (and still doesn’t convince many, I think. The language is moving there, but it will be a while before it gets there, if ever)
So, why claim Swift more than repeated “Objective-C's mistake of using the component language as the base”?
I was confused by these things as well and here’s what I came up with:
RE objects, I guess they are referring to Smalltalk-style objects. Objective-C has them while Swift has a somewhat different flavor of objects. This author seems to consider that a regression of sorts.
RE the connection and component languages — your “white collar” and “blue collar” languages (BTW, I like your terminology, so I’ll use it), I think they are making the point that Objective-C started with a blue collar language, C, and extended it with while collar language features (derived from smalltalk), while Mojo started with a white collar language, Python, and are extending it with blue collar features. The author likes the Mojo approach, though doesn’t really explain that. I think they are claiming Swift is somehow more aligned with the blue collar side than Objective-C and feel that’s bad, but it’s too vague to really mean anything.
(I think the idea with Swift and some other newer languages is that you can have a single language that is good at both white collar and blue collar things and “native” to both. I don’t think Swift has quite pulled it off, but it’s still evolving, so we’ll see.)
Swift was always subject to a tug of war between the design purists - Chris and his ilk- and the product purists, i.e.Apple employees using Swift and with influence on Swift's design)
The latter has silently won the war and any use of Swift as a systems programming lang/env is left as a "isn't it nice than you can" rather than a P1 design goal for the language (or even P2 for that matter)
After 10 years and exposure to dozens of languages, I find Swift to be utterly delightful to write anything with, and wish that it did have the drive behind it to become a more generalized and cross platform. language, but I'm under no illusions that it will while pre-WWDC and pre-product-unveiling narratives are driving the direction of the language from the back seat of the car.
> You have a “blue collar” layer where bytes and bits get shuffled around and hands get dirty and a “white collar” layer where programmers pretend the world is made of legos and there’s no need to get your hands dirty to write programs.
Nope.
The analogy you came up with is interesting, but although there is some overlap, it doesn't really capture the distinction and is the reason why you're not understanding the bit I wrote about connection languages and component languages.
You can have a component language that is just as "white collar" as the connection language. And you can (probably) have a connection language that is quite blue collar, although that might be a bit harder.
The reason I find your analogy interesting is that despite actually not capturing what is there, it does seem to capture how many people (erroneously) view and use the distinction between connection and component languages.
Objective-C added Smalltalk as a connection language, a language for plugging together the Software ICs you would write in C. See, for example https://blog.metaobject.com/2019/01/swifter-sieving-of-prime... It did not add Smalltalk as a "white collar" language that didn't need to get its hands dirty, and it didn't have the facilities to do that. Over time, people discovered that the connection language was in many ways more convenient to use, and so did what you describe, use it as a "higher level", more "white collar" language. But once again, that was an abuse of the language, it wasn't made for that and, due to not being made for it, it wasn't very good at it. Even after they added some facilities to make that use-case more possible.
This is an interesting application of the blue/white collar terminology. I would have expected it to be used the other way around, white collar requiring more education, and blue collar being more pragmatic.
Why would you think white collar work requires more education?
IMO, top-end blue collar educations such as engineering or medical degrees certainly don’t take less time than white-collar ones such as law school or an MBA.
That depends on what the "has" means in "has types". If you want to multiply two words, you need to decide whether they're integers or floats -- those are types!
If C isn't blue collar enough for you, nothing is, beyond assembly.
I'm confused about the comparison here. I've never heard of Mojo before, but reading this and all the discussion of the main languages on Apple's platform, you'd think that Mojo was somehow an alternative for development on iOS or macOS, replacing Objective-C and Swift, like the post is making a case that it is better than Objective-C. But it appears to have nothing to do with this, so the juxtaposition feels odd. There are a great many two-language-problem situations in the wild (Clojure/Java, Elm/JS, etc) and each features a solution that is somewhat tailored for the specific use-case or platform. Seems odd to compare one of these use-cases with another when the situations so widely vary.
Ah, that could be it. I did not know the history, nothing in the article makes that point, not that it would need to I guess for people who already understand the history of the language.
Yeah, I'm confused as well. Objective-C without C is Smalltalk. This looks like Python with types. Objective-C took a static language and made it dynamic with messages and objects. This takes a dynamic language and makes it more or less "static". So, if anything, it is exactly the opposite of Objective-C.
To be clear, I didn't spend too much time examining this, so I might be way off. Grafting types onto a language doesn't interest me.
From what I've read about Mojo it sounds really interesting, but as opposed to the main languages and libraries currently used for machine learning it seems to be proprietary, or am I mistaken?
At least, clicking on "Get started with Mojo" on their website seems to lead to a form to fill out instead of to an easy download. I haven't filled it out so I don't know if you need to wait for approval or what.
But, given how little I've seen about it in terms of availability and source availability, I guess I'm having a hard time understanding why people seem to be so hyped about it. No matter how nice it is, unless it gives some major advantages over Python and some system like PyTorch or Jax, I wouldn't port my entire machine learning pipeline over to a propriety language for which only one implementation exists that I can't even download without filling out a form.
You can't download it even if you fill the form out. It does make sense to wait until it's open source before betting the farm on it; the intention is that it will be open source.
I see. I guess I've never seen an open source project announced and "released" this way, as just an online demo and some blog posts. Indeed, I'll come back to it when it's ready.
When Lattner talks about what Modular is doing, it sounds like they are planning to be almost like an operating system for AI systems, and Mojo is the language you have to use.
So it makes sense that it's not open, and you can only use it via their notebook. It probably doesn't work on normal hardware + Linux. That's the monetization strategy. You have to run their system and pay for it.
I was listening to the Chris Lattner interview by Lex Fridman the other day, very interesting stuff.
I use Python for application programming, scripting and basic ML, so I think many of the Mojo features are not for me...
On the other hand, I love types and I think they're one of Python's weakest points. I use mypy and native typing but they feel like a weak scaffold compared to a strongly-typed language or even something like TypeScript.
Do you guys think there will be a case for Mojo as a general-purpose programming language "for the rest of us"?
Structs and strict type enforcement for a subset of the code, I really like. Also, a more seamless pipeline from "experimental python" to "reliable production ready python" makes a lot of sense to me.
At the end of the day, mojo is very very early, not even open source yet.
Furthermore, mojos success will be largely bound to modulars success, which is a VC backed company. A decent looking one but still that means it's more likely to fail fast than succeed slowly.
Chris Lattner replied to a similar question about Mojo as a general purpose language here:
> Mojo is a general purpose language and can be used to replace C use cases like Rust does etc, but that isn't where we're focusing initial development. That doesn't mean we're excluding it, just that the libraries etc aren't the focus for us to build. We hope the community will be interested in filling that in and building out the use cases in time though.
I tried, first the signup page doesn't show the form on 3 separate browsers.
Paused my adblockers, nah no luck.
I don't remember what I did exactly using dev tools but, noticed the form was there, but just not being rendered. Somehow made it work, and signed up. Never got access, even after a month.
Mojo is all talk for now.
They could've just paused the marketing until it was atleast in open-beta. Why the hype without allowing access.
It's marketing in action, though Chris Lattner's reputation from LLVM and Swift has a lot to do with why it quickly gained a high profile in these circles.
Maybe it's true, maybe it isn't. But who do you think has a vested interest in that meme being repeated? Mojo is a commercial, closed source language implementation backed by $30M of investor cash looking to turn a profit.
I wish them luck and watch with interest. Like a lot of people I've had "write a very fast Python and ??? and profit" on my todo list for a while (it remains below "job to pay the bills" though) because there's been obvious user interest for some years, although it's not clear if that translates to much commercial demand. I think if they are successful and if they remain closed source, an open source clone will appear soon after, and within a year or two will match or outperform them on reported performance, but they will still have a business for the same sorts of reasons Red Hat remains profitable.
It is interesting, I don't think a company based on a language can work. They need to open source the language and make money on something else. The best "something else" would be cloud services that find optimal ways to run the Mojo code (finding the right combinations of C/G/TPUs in some way). A closed source language with a licensing fee is never going to work.
I don't buy the criticism of Swift. Swift is not "Objective-C without the C". It's a new language with Objective-C runtime bits grafted on because they're necessary for the Apple ecosystem to transition to it. It's incorrect to think it's in any way intended to be a better version of Objective-C.
I feel like Mojo’s interoperability story is going to inevitably stumble on the Python dependency ecosystem, mostly because even Python stumbles on the Python dependency ecosystem.
Same thoughts here. Overall there's no real exploration or discussion of the particulars that make Mojo a scalable language either which makes it a rather empty article.
Still I do like the idea of "scalable" languages. Nim accomplishes this largely by making programming the "low level" mostly as simple as programming in the large. To be fair Nim doesn't offer too much special for "component programming" like Obj-C's aside from basic objects. Though one could argue making good DSL's is certainly a superpower and benefits component programming.
I dont think its possible to make intelligent comments about mojo without going first not just through the influencer hyped no3 lex interview but also the earlier no2 interview that precedes the mojo launch by a few years.
The main point is that computing in the age of LLM and gpu/tpus and the semi-dead Moore's law is hitting a wall.
Climbing over that wall will take bold vision and skillful execution. There may be alternative ways to get to that next phase. The modular/mojo team is basically throwing down the gauntlet.
This article does nothing to support the headline, and in fact contains almost no actual information. Just a bunch of assertions without examples to back them up.
Lots of snark here, but from following the development vaguely, and looking beyond the marketing speak:
Mojo is aiming to be a state of the art systems language that has Python embedded seemlessly. It's exactly the other way around from numba/Cython which embedd compiled C in performance silos inside Python.
I used to do heavy numba work and this has no relationship to that. Just look at what the devs are actually targeting/implementing right now: Better lifetime/ownership semantics and ergonomics.
This is not in the same universe as numba (or even Julia).
I think it's far too early to tell whether it will be good, but I haven't seen any other approach that resembles it.
Cython at least from my use of it, is very difficult to debug. It's a language inside a language and you easily get lost between all the pyx pyd files. it's not very developer friendly. Mojo/Julia promise a good developer experience
You fill out this form and they send you a link to make an account in a few minutes. I did it this weekend and it was pretty painless and I haven't gotten any marketing emails from them... yet.
That being said, I wouldn't describe it as 'open' at the moment. It's more just that you can verify any claims they make.
i think the idea is, that with objective-c, the substrate was always c with the objects (connection language) being the objective (smalltalkish) part
if you took the c out of objective-c you basically have smalltalk but you still might need c-ish level expressions to get better performance
the expectation from swift then, was that you'd start out with that high-level paradigm and then provide lower level constructs only when needed for performance or other reasons, but the reality is you start off closer to a really well-designed and clean c++ (structs, classes, enums, generics) that adds higher level features (actors, async, etc) when you need it than something that starts off high-level as smalltalk or python from the get-go
the reason the author likes mojo more in that respect then is because it starts with the high-level constructs (python) as the substrate and allows for tuning where needed... the presupposition i think is that will lead to higher productivity and simpler code in the long run (this is my interpretation)
Much as I would have preferred Swift to have been "Objective-C the good parts", my reasons for wanting that are totally unrelated to the idea pushed in the blog post.
Python isn't any more expressive than a language like C# once you remove the Java-inspired cruft. C# lets you go all the way down to the metal with pointers and what not if need be and supports fully dynamic types with "dynamic" and the underlying "Dynamic Language Runtime", but at no point does it feel like two separate languages glued together the same way Objective-C did, or now Mojo. People have written a Nintendo Switch emulator in C# ffs.
Python's higher productivity is entirely thanks to its libraries (including the standard library). The dynamism isn't really key to it, heck, @dataclasses expect you to annotate the field types even though they aren't used because of a syntax quirk!
Mojo is based around Python to piggyback on Python's ecosystem the same way Objective-C and C++ piggybacked on C. It has nothing to do with a "scripting" language vs a "component" language.
Lua has a much nicer interface for scripting C than Python does, not requiring manual reference counting for one, to the point the original Torch (before it became PyTorch) used it. It didn't matter in the face of Python's ecosystem.
I wish them all the luck. I'd like a language that delivers on all these promises.
But by the time you add all these features, don't they already exist in other languages? What is this one doing that will be enough of a leap to justify 30m investment?
Anyway, never gonna try it, unless I'm absolutely forced. I hate their marketing strategy, it sounds too bad.