Creating a new language in the age of AI seems kind of pointless. I don't write code by hand anymore, I only review it and I prefer it to be in a language which I already know since investing time in learning another language doesn't make sense at this point.
And Mojo will die because nvidia is not interested in maintaining any semblance of backwards compatibility when it comes to CUDA. It's going to be a perpetual race forwards, and whenever nvidia upgrades CUDA, you're going to be stuck there twiddling your thumbs and waiting for Mojo to become compatible.
Additionally, anyone who has seen how Swift evolved should be wary of Lattner saying "the language is mostly stable", or even "the language is released".
It's not true that Nvidia doesn't care about CUDA backwards compatibility. The invention of TileIR was motivated entirely by that problem. GPU architectures are supported by the full tool suites for at least 10 years by CUDA (that's longer than they are for graphics).
Nvidia is also a major contributor to MLIR, which they use for TileIR and ClangIR, so should a compatibility break occur it wouldn't be entirely up to Mojo to fix it.
> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.
> Weird to release 1.0 without it. What are they waiting for?
Hmm, I've been under the impression that at one point they said it'd be 100% FOSS by the time 1.0 hits, but maybe I misunderstand/misremember the details. But I remember they'd said it'd be FOSS in connection with 1.0, seems weird to do it this way instead of waiting until it's all FOSS then cut 1.0.
I think they are waiting for a wild success in adoption, and if that doesn't happen they can use the IP to pivot to something else without giving the core away to anyone for free/as open-source.
A lot of people beg to differ. And it's their decision, not yours on when to open source. They have their reasons even if they aren't explaining them to you.
From listening to Chris Lattner in interviews my guess it’s learning from when Swift became open source. The beta versions of Swift had massive language changes in how value types worked like with Array. Mojo is trying to get this language design locked down first, which is easier to do behind closed doors.
A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).
That doesn't really make sense, as being open source really has nothing to do with whether the language has an open evolution process. And if they've already declared 1.0, then they've already decided they're stable, so the original point doesn't apply any more.
I feel like they're going to remain closed until Qualcomm is convinced they can't make any money from it being so.
Massive language changes
are easier to do without users. Whether the source code is visible to external people or not is completely irrelevant. I have a few programming language implementations on my GitHub and let me tell you, making manor breaking cha he's to those are easy as pie when I'm the only user.
If Mojo's goal was to make evolution easier, they would have a limited closed beta like what Jai does. But they're not doing that; they make the toolchain available to everyone, they just did this marketing push around releasing version 1.0 of their language. They're making it harder to make breaking changes by seeking users among the general public.
I have no idea why you started talking about outside contributors though, nobody's arguing that they should accept outside contributions. You do t have to do that. It's a completely orthogonal issue to what we're talking about, which is releasing the code under a FOSS license.
C and C++ were closed source for quite some time, they still are in places like commercial embedded OSes and console dev kits, even when they happen to be GCC and clang forks nowadays.
Clang actually has replaced most GCC forks exactly because vendors can keep the fork closed source.
Sure but at those times C and C++ had no immediate replacement, and if you were doing embedded C/C++ was your only option.
The same cannot be said for Mojo.
The C compiler source came with the AT&T UNIX tape ... it wasn't open source because FOSS didn't exist at the time and it was under a proprietary license, but it was not "closed source". Parts of MOJO, OTOH, are closed source because the source has not been released (yet ... it apparently will be later this month).
And then you drag the goalposts out of the country ...
As I said, C was not "closed source", it was distributed with source under a proprietary license. And "all the UNIX clone vendors" didn't exist for years after the UNIX tape was first released. And they weren't "clones", they were enhanced supported versions of the AT&T system. I worked for nearly a decade for the first of those commercial UNIX vendors, ISC ... the other prominent ones were SCO and Wollongong. (Sun came along later, based on BSD UNIX, developed for the VAX and of course derived from AT&T UNIX ... none of these were "clones" ... the first of those was Minix, and then GNU/Linux). We all distributed UNIX with the AT&T C compiler. Eventually ISC wrote their own C compiler for IBM's AIX project because IBM always had special requirements ... I don't know whether we distributed the source or not.
But the point is that this was nothing like the situation with Mojo, which currently has not released the compiler source ... which is nothing like what people on this page are writing, because it will be open source SOON, probably coincident with the conference later this month.
For once. A former colleague once quipped: The only way to make decent money in the business of language runtimes is to get a job at a big company that depends on it.
That’s insane, for a language that seems to be Temu-Python.
OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.
As someone who writes GPU kernels in Julia, yes it is. But Mojo is one of the few alternatives based on technical merit alone. Each language is better in different metrics, and it could be argued either way.
License-wise, Mojo reminds me of paid Borland compilers that were in vogue before I was born. Even if it's open-sourced, what incentive does Qualcomm have to maintain a happy path for Metal deployment? Mojo might actually be the best way to program Apple GPUs (on a technical level) and it would still lose due to politics.
Julia is actually quite nice for this. If you prefer a python-like approach consider Triton from openai, numba (https://numba.pydata.org/) or CuTe DSL from Nvidia.
It almost feels like they were paying more in the hopes of owning the next LLVM or Swift based on the name on the tin rather than basing the price on the product itself.
Pydantic is mainly about making Python strongly typed.
Mojo addresses the actual need to write code in other languages, such as C++ or CUDA, for low level and hardware specific work.
But I wonder if it has already missed the AI hype cycle, when a lot of low level code is being written. I'm not sure how the developer ecosystem will react now.
It's JIT only, and it needs to be in a particular shape to be effectively compiled. It's mostly for numeric code, but there are many other cases where native code would be better.
The premise of Mojo used to be that it was a superset of Python so in theory LLMs would benefit from that but I'm not sure how much divergence there's been
Wouldn't that cause an awful lot of confusion in practice? Instead of having one being a superset of the other, you now have two almost identical syntaxes, but probably not quite.
LLMs have enough problems distinguishing between major versions between packages, e.g. where all the imports were moved around and renamed.
> They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
The fact that they release 1.0 without doing this, I think says a lot. I personally haven't even started looking into Mojo because of the closed source stuff, but usually you can tell what's going on by looking for what's obviously missing.
Aren’t they already separated? Max is an inference runtime, written in Mojolang, which uses the MLIR compiler chain to target diverse accelerator hardware.
They kind of did. It has a separate website now [1] . All the docs, announcements, roadmap, some comparisons as you asked are there. So they do seem to be working towards separation.
LLVM has such a cool tutorial, eventhough I haven't written a programming language myself, it was excitung to go through it to see how static programming languages are lowered to SSA form.
Mojo should have something showing how to write a super fast matmul and especially what's interesting for me is a fast linear attention kernel, as that's where PyTorch is getting much harder to use.
They’ve had this branding for some years, at least since 2023. I doubt at that time it was fully AI generated, although I have no proof of it. I always looked at it as being heavily AI inspired.
I know right? Would be better to have a banner with the language logo than some totally out of place aislop image, almost makes you think this is a random person's blog and not the official Mojo site
I believe Mojo has been primarily using AI-generated imagery of its mascot for several years now, which politically aligns with its pivot to being a language for AI development.
Oh, gotcha. I thought I recalled reading early material that emphasized the flexibility of Mojo emitting MLIR for many tasks, but it's possible that that was either pre-launch, or that I got confused when reading about MLIR itself.
Almost? That's exactly what it did! At first I thought this was some bozo's toylang mysteriously on the front page of HN garnished with a wall of LLM technobabble.
These AI illustrations are the nee "corporate Memphis." Images of flat, minimalist people in bold colors used to be the sign that whatever text accompanied them was low-value drivel. Nowadays, I associate the same with AI generated imagery. I'm not sure why the folks doing the writing (if, indeed, any of the writing was done by a human) don't seem to clock this when the audience seems to be able to catch on almost immediately.
Finding some unit of the thing one can actually understand and using it to issue a shallow dismissal is canonically the most Hacker News possible comment. And the rest of the commenters generally love it.
Not to worry though, if there’s nothing webshit accessible in the content there’s surely something wrong with the CSS to complain about!
Well, not really; people have long ignored overly corporate or low-effort news releases because. The presence of certain language or stock images is a signal (and I would argue a valid one) that the rest of the content is equally low-effort and not worthy of attention. AI images are just the newest version of that signal. I think it behooves the writers of these blog posts/news releases/community updates/etc. to reflect on why they continue to include these signals that their content is low-effort or low-value if they actually want their audience to read it.
Unless the idea is that, in 2026, you assume your audience is an LLM that is ingesting and summarizing your content for the end user and that no human will actually read what you wrote so you don't actually need to care about signals of quality or trustworthiness. The AI generated illustration seems kind of superfluous if that's the case, though.
Isn't Mojo expressly for building AI frameworks? It isn't really needed or special as a language by-itself. It's main purpose is to make it easier to program these high end graphics cards for AI.
> Lastest OpenCV 5 release notes also had a lot of LLMisms.
Yeah, that really made me triple-check if I visited a fake SEO spam website instead of the official OpenCV one. The fact that their blog looks exactly the same every single low-effort AI content farm doesn't help either.
A lot of software engineers don't have a good feel for this kind of aesthetics or social outcomes. They're playing with their new toy (which is very exciting, let's not ignore that), they're happy it does stuff, but ignore that it can be perceived as ugly and cheap by others. As well as totally bland - every other cheap company is using it too.
Yeah, I just assumed that it was some sort of image generation crap >_< It's funny how this affects me tbh, I think it has almost the same effect as if there would be a boner-pills ad there or something. Or a 'subscribe to read' popups.
It's all just spam, filler content and I did not ask for that.
> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.
Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
Ladybird is Open Source and doesn't accept outside contributions any more same with sqlite and many other projects. Lots of Google's oss projects also are not very open to contribution.
At this point I find it deeply troubling that it isn't open source. I respect Chris I know folks who have worked with him and but at the end of the day I feel too weird about this entire closed source programming language thing.
If we complain to Nvidia about there weird closed source limitations, I think Mojo is just as bad. You don't even know what your compiler might be doing, and if it does something wrong you can't fix it, you now have to file a bug and wait until the gods from above come to your rescue.
I have had similar issues with drivers, I have faced soo many driver bugs in my work and the answer is always write more code that works around it somehow, this warp level is bad, this feature doesn't work with these values, etc. etc. Why can't I fix them, I have often on Linux just pinged the Mesa team about driver bugs with a rough draft of a patch and gotten it fixed, I can even patch and run it myself when I am in a hurry.
I feel like atleast making stuff, source available like Unreal should be the baseline for any "core" software where a bug could possibly be a major blocking issue for a developer. Windows and Mac are very bad with this.
Mac's CoreML has had soo many bugs over the last couple years I have had to email someone I know at the company to get them fixed or try to get into contact with someone.
Intel's drivers have had bugs too but I have had more contacts there which is a wash. AMD well it's AMD...
Either way closed software sucks I don't want to use fully closed stuff unless I don't have a choice people can make what they want of it. I don't really care.
My guess is that the compiler will be opened next week at Modcon. Honestly? I'm surprised Mojo 1.0 is being released now; I had thought it would be released at Modcon along with the compiler source code, but oh well, 18th August isn't far now.
Who said anything about 4 months? Your "logic" seems to be that they are releasing it in 2026 and there are 4 more months in 2026 so they will be releasing it in 4 months. That's obviously flawed thinking. They will probably be releasing it coincident with their August 18 conference.
I don't know why you're responding to me ... I simply pointed out how ludicrous was the statement that it will be 4 months before it is released.
And intelligent imaginative people can make quite a bit of sense out of announcing 1.0 prior to the conference. Open sourcing it may require efforts that simply didn't coincide with that announcement. I see this sort of pronouncement in the chat for the chess.com daily puzzle all the time -- "the solution makes no sense!" ... and yet it always does.
P.S.
> "They will probably be releasing it coincident with their August 18 conference."
Yes, I know I wrote that, genius.
And no, I didn't ask a question, and that's not a rational explanation of why you responded. And I don't owe anyone an explanation of my attitude or tone. If you don't like it then don't interact with me.
I feel like this language would really benefit from some sort of 1-pager overview.
I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python alternative that might get interesting.
I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python.
I do see this one overtaking Nim over time, which kind of saddens me, because I like Nim for what it is, but Mojo trying to be a superset of Python is a no-brainer for most Python developers. Reminds me of how a lot of Go devs were former Python devs not C++.
> their overall goal is to be a fully native superset of Python
Not any more. That was the initial announcement, but I think then somebody actually looked at Python and realised what a complex language it is - so they refocused on being a Python-like language. Python has a reputation for being a simple language, but in reality it isn’t at all.
Honestly that doesn't really feel like a glowing endorsement of the language. "They announced a crazy goal, then rolled it back because they grossly underestimated how hard it was" doesn't give me confidence in either the long-term design or the people making it, and I feel like "a Python-like language" is both a lot less interesting and a lot more subjective. If the discussions in this thread around significant whitespace aren't already an indication, which parts of Python people think are good and which aren't will vary by person, so without saying more it's hard to tell whether it's a a language someone will love or hate.
To preempt all of the inevitable responses: yes, I'm aware that this was started by the same guy who started LLVM and Swift. That doesn't automatically mean anything he comes up with will be great, especially when it's specifically trying to be "like" a language that doesn't really have much on common with either of those; there are plenty of instances of very smart people having an overabundance of confidence when jumping into something they assume they'll excel at and getting humbled. I'd also argue both Swift and LLVM have some common criticisms that very much are in line with the same concern I've expressed here (i.e. long term design suffering due to expanded or pivoted scope; even the name LLVM alludes to some of that history of having a somewhat different goal originally). His name is enough that I'll probably always click to take a first look at anything he comes up with, but I'm not going to ignore things that seem like issues because of that either. Smart people don't need to held to a lower standard because their work should be able to speak for itself.
That is a mistake. Being fully compatible with Python was a big selling point. Now they are just another knock off that wont get enough traction to make a dent. Unless this GPU programming thing is so amazing it takes over the industry with one small niche feature, guess that is the hope.
Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.
Part of that is because there isn’t yet a package format and a central repository. I have a few libraries I would like to contribute or merge with similar projects.
For sure, those things would go a distance towards making it a more competitive language.
Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
Andreas is simultaneously brilliant and myopic to needs outside of his own (compiler dev).
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
I mean, it feels like "Python, but aiming at a completely different vertical that values native compilation and a borrow checker"? Which is not quite the same thing
I like significant invitation, but I still wouldn’t choose it if I was designing a language today.
Functional-style programming has become much more popular since Python was designed in the 1990s, and there doesn’t seem to be a good way to have Python-like significant indentation and also support true anonymous functions.
Haskell's significant indentation is, in my experience, much worse than Python's at fading into the background by matching what you would have done anyway.
As I understand it, Mojo’s goal is to be able to match state of the art performance for parallel algorithms and be able to use the exotic GPU hardware. A functional style is not necessarily productive in that context.
Like with array base indexes, there are plenty of languages that start with something other than zero, and many that use indentation, including a few well known in hacker circles, Python isn't alone.
Every python developer I know uses an auto formatter today, and never needs to think about it (ruff, black). It's not ambiguous and is immediately visible if something has the wrong indent.
(On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)
You missed the point. I’m well aware python has formatters, I use them and implemented my own. The point was that when generating/manipulating python code you cannot just generate in whatever format then run a formatter. you need to carefully keep track of the exact indentation at place where the code in written
Fair. That is a very slight friction on what is quite a small niche, though (compared to the wider ecosystem of developers). And most that need similar will use AST or runtime construction.
The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?
If I were doing this, and the code generator was itself in Python, I'd probably use ast and/or tokenize to avoid having to manipulate literal whitespace.
Python's significant indentation does have real costs, but they mostly don't affect experienced programmers working on real codebases in real editors or IDEs. Rather, they are things like, it makes the REPL more cumbersome, and newbies sometimes find that code they copy-paste from the Web mysteriously fails to work.
Have you never tried to paste python code from the internet into an editor? At least half the time the indentation is screwed up and I have to go in and figure out manually where to put the spaces in. Indentation gets screwed up by pasting in other languages too, but with those I can generally tell the editor to reindent and it can because the information is included in the source code.
Whenever people stop creating new language with significant indentation. I don't complain about it in Python but I hate when this bad idea is introduced in more places.
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc.
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
> LLVM is still involved, but they are using it differently than say, Rust or Zig.
Chris Lattner said in a Developer Voices podcast interview:
"Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig.
Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.
Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.
Mojo compiles with O2 by default, it is similar to Go here. Release build is the default, debug is something you opt into. It is still very fast nonetheless
I think they had a good dive here
https://www.youtube.com/watch?v=SEwTjZvy8vw
The gist is that MLIR (unlike LLVM) was designed to be multithreaded so the whole stack above LLVM IR is parallel, and then LLVM is used as a per-function codegen tool in parallel, so although LLVM itself is single threaded there are multiple seperate contexts of it. also I think they wrote their own linker.
Well, LLVM itself is still single-threaded; they just designed Mojo's compiler in such a way that the code generation part can be parallelised, which is something you can do if you understand LLVM from top to bottom. As far as I can see, no other production-grade LLVM consumer has been able to make it parallel; the single-threaded nature remains a major performance bottleneck.
> Modular found ways to parralize LLVM code generation by introducing novel techniques
> The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
You said they parallelized LLVM with novel techniques, but then claimed the novelty is the very act of parallelizing it. That's circular, you still haven't explained what are the novel techniques?
Here is a presentation talking about the parallelization techniques, I skipped to the relevant part but the entire presentation is helpful in understanding how Mojo's compiler works: https://youtu.be/yuSBEXkjfEA?t=813&si=MlB7IsBDsj3o-PTX
I felt the same way, even after browsing around on the website, and somehow I got to https://mojolang.org/docs/manual/quickstart/, which brings you to mojolang.org instead, which is the real website of the language it seems, instead of "Modular" which I guess is the business.
https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.
I was on both. I honestly don't think mojo.lang.org is much clearer - the front page says "GPU kernels + Python + metaprogramming", and the last of those is something Python already has out of the box. The QuickStart doesn't seem to introduce any novel features of the language either.
Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
Whoever behind the company communication have done an incredibly terrible job. They start with an extremely unnecessary polished Steve-Jobs-alike debut video when they have zero stuff to offer, while the founder name is already immensely trustworthy. Then follow with a very ugly AI-image-heavy website and blog posts, only to be reverted back to plain website later.
I'd love the language and platform be succesful, nevertheless.
Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agents wasn't great timing.
> "Qualcomm to Acquire Modular"
That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive.
The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc.
I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.
The Python tie in was always a sales pitch. The technical pitch was "a language built around MLIR taking all the lessons learned by Rust and Swift on board, with an eye towards Python interop". There were MLIR intrinsics and extensive discussions of the ownership model from the start, but never even an attempt to have classes.
And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on.
Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
I am already using agentic orchestration tools where the language is irrelevant, e.g. Opal, Workato, Boomi.
The evolution of iPaaS low coding tools.
Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that.
COBOL is already laughing at the efforts to write so much English text to keep AI on track.
I think they wrote an internal memo and by mistake they share with the public. I read because one person I know works there, now I don't know what my friend does there either. Sounds like another VC eating company.
For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).
To be fair, a good bit of the apps/programs/projects posted on hacker news could use a good '1-pager overview'. Like has nobody every explained the 'elevator pitch'. A little marketing doesn't mean you are selling out. Obfuscating your product doesn't make you hip.
Is Mojo being a superset of Python still part of its projected feature set?
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
> I feel like that "full superset of Python" part was part of the appeal of Mojo.
It absolutely was, but IMO was never going to happen. Python has a reputation as a simple language, but it really isn’t. It’s a very complex language hiding behind friendly syntax.
I think once the Mojo team realised that, they had to adjust their expectations.
Nothing but respect for Chris, and I understand why founders take these deals. But an acquihire usually means the product is the part that gets left behind, and that's the part I cared about.
Well, there was $300M+ in VC money and after burning through some percentage of it those investors wanted an exit. I don’t think this is so much about founders taking a deal as it is investors demanding that exit.
TFA says "we will open source the Mojo compiler and toolchain in 2026" and "we’ll share more on our plans for Mojo, MAX, and open source at ModCon on August 18th" which makes it seem they're not open sourcing it next week, but some time between next week and 1/1/27.
I wish Modular/Qualcomm good luck with this. We would be well served with a good alternative to Cuda. I will be looking at Modcon to see how serious they are with Mojo's ecosystem. (Hopefully it won't be yet another SYCL).
From Mojo Wikipedia article:
```
The intention behind Mojo is to bridge the gap between Python’s ease of use and the fast performance required for cutting-edge AI applications.
```
The design and intellectual heritage of Julia and Mojo couldn't be more different though. Mojo is a Swift/Rust style language from industry veterans, Julia is a Lisp built to make academics write faster code.
Completely true, but Mojo approaches the problem from a different angle. Where Julia aims to blend fast and slow code seamlessly, Mojo's solution is to have a set of opt-in semantics that ensure fast code.
This probably has a simple answer, and is something I can easily google. But it's always been in the back of my mind, what optimizations would be possible if you took actual python code and forced 100% type annotation. Could you meaningfully speed that up at the interpreter or with some pre-processing or compilation?
What in the world would posses the modular team to attach those horrendous AI generated thumbnails to each blog post? It makes it feel cheap, even though I know the project has some really serious technical expertise behind it.
"AI slop image below the headline" is an unmistakable mark of low-quality content written by a sophomoric AI evangelist. Let them keep watermarking their own content.
melodyogonna | a day ago
alberth | 23 hours ago
Am I understanding the current state of things correct?
mono442 | 23 hours ago
tfrancisl | 23 hours ago
winding | 22 hours ago
ainch | 21 hours ago
catoc | 22 hours ago
(And now in the age of LLMs, the barriers to get started with a new programming language are lower than ever)
pjmlp | 9 hours ago
nylonstrung | 22 hours ago
well_ackshually | 22 hours ago
Additionally, anyone who has seen how Swift evolved should be wary of Lattner saying "the language is mostly stable", or even "the language is released".
Conscat | 21 hours ago
Nvidia is also a major contributor to MLIR, which they use for TileIR and ClangIR, so should a compatibility break occur it wouldn't be entirely up to Mojo to fix it.
mathisfun123 | 10 hours ago
jhatemyjob | 21 hours ago
redlewel | 22 hours ago
Much better options out there. Python already has libraries like Pydantic that offload performance to functions written in Rust under the hood.
my123 | 22 hours ago
mort96 | 22 hours ago
fluidcruft | 22 hours ago
embedding-shape | 22 hours ago
Hmm, I've been under the impression that at one point they said it'd be 100% FOSS by the time 1.0 hits, but maybe I misunderstand/misremember the details. But I remember they'd said it'd be FOSS in connection with 1.0, seems weird to do it this way instead of waiting until it's all FOSS then cut 1.0.
e4m2 | 22 hours ago
Make of that what you will.
boxed | 8 hours ago
redlewel | 22 hours ago
usef- | 19 hours ago
TylerE | 14 hours ago
bourbonproof | 22 hours ago
ktm5j | 19 hours ago
burntcaramel | 14 hours ago
A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).
jshier | 13 hours ago
I feel like they're going to remain closed until Qualcomm is convinced they can't make any money from it being so.
mort96 | 10 hours ago
If Mojo's goal was to make evolution easier, they would have a limited closed beta like what Jai does. But they're not doing that; they make the toolchain available to everyone, they just did this marketing push around releasing version 1.0 of their language. They're making it harder to make breaking changes by seeking users among the general public.
I have no idea why you started talking about outside contributors though, nobody's arguing that they should accept outside contributions. You do t have to do that. It's a completely orthogonal issue to what we're talking about, which is releasing the code under a FOSS license.
ekianjo | 12 hours ago
fluidcruft | 22 hours ago
pjmlp | 22 hours ago
Clang actually has replaced most GCC forks exactly because vendors can keep the fork closed source.
redlewel | 22 hours ago
pjmlp | 22 hours ago
AMD/NVIDIA/Intel now having first class support for Python DSLs or GPU JITs for their APIs, and Julia as well.
mike_hearn | 21 hours ago
It was just a different culture. There was no expectation that everything should be free.
jibal | 22 hours ago
pjmlp | 20 hours ago
In fact, GCC was largely ignored until Sun decided to split SunOS into two SKUs.
jibal | 18 hours ago
As I said, C was not "closed source", it was distributed with source under a proprietary license. And "all the UNIX clone vendors" didn't exist for years after the UNIX tape was first released. And they weren't "clones", they were enhanced supported versions of the AT&T system. I worked for nearly a decade for the first of those commercial UNIX vendors, ISC ... the other prominent ones were SCO and Wollongong. (Sun came along later, based on BSD UNIX, developed for the VAX and of course derived from AT&T UNIX ... none of these were "clones" ... the first of those was Minix, and then GNU/Linux). We all distributed UNIX with the AT&T C compiler. Eventually ISC wrote their own C compiler for IBM's AIX project because IBM always had special requirements ... I don't know whether we distributed the source or not.
But the point is that this was nothing like the situation with Mojo, which currently has not released the compiler source ... which is nothing like what people on this page are writing, because it will be open source SOON, probably coincident with the conference later this month.
I won't respond further about this.
nylonstrung | 22 hours ago
The alternatives would be stuff like CUDA
woadwarrior01 | 22 hours ago
sgt | 21 hours ago
woadwarrior01 | 20 hours ago
saghm | 15 hours ago
woadwarrior01 | 8 hours ago
saghm | 2 hours ago
mohamedkoubaa | 19 hours ago
pansa2 | 18 hours ago
OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.
jmalicki | 17 hours ago
This doesn't compete with Python.
Like if someone wrote a competitor to VHDL that looked like TEMU Python... Python would not be its competitor, VHDL would.
adgjlsfhk1 | 17 hours ago
IshKebab | 16 hours ago
postflopclarity | 15 hours ago
Archit3ch | 3 hours ago
License-wise, Mojo reminds me of paid Borland compilers that were in vogue before I was born. Even if it's open-sourced, what incentive does Qualcomm have to maintain a happy path for Metal deployment? Mojo might actually be the best way to program Apple GPUs (on a technical level) and it would still lose due to politics.
pjmlp | 9 hours ago
https://developer.nvidia.com/blog/cutile-jl-brings-nvidia-cu...
pjmlp | 9 hours ago
Alexander-Barth | 6 hours ago
saghm | 15 hours ago
ashu1461 | 17 hours ago
Mojo addresses the actual need to write code in other languages, such as C++ or CUDA, for low level and hardware specific work.
But I wonder if it has already missed the AI hype cycle, when a lot of low level code is being written. I'm not sure how the developer ecosystem will react now.
zer0zzz | 14 hours ago
charlieyu1 | 22 hours ago
seanw444 | 22 hours ago
mathverse | 22 hours ago
SJMG | 14 hours ago
raytopia | 20 hours ago
maleldil | 16 hours ago
beanjuiceII | 22 hours ago
perarneng | 22 hours ago
But I hope they succeed, it's a very interesting approach. Then I will jump on it later on. S
oceansky | 22 hours ago
nylonstrung | 22 hours ago
refactor_master | 14 hours ago
LLMs have enough problems distinguishing between major versions between packages, e.g. where all the imports were moved around and renamed.
384028345 | 17 hours ago
https://github.com/modular/skills
xiphias2 | 22 hours ago
They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
embedding-shape | 22 hours ago
The fact that they release 1.0 without doing this, I think says a lot. I personally haven't even started looking into Mojo because of the closed source stuff, but usually you can tell what's going on by looking for what's obviously missing.
pbronez | 21 hours ago
geodel | 21 hours ago
1. https://mojolang.org/
xiphias2 | 9 hours ago
LLVM has such a cool tutorial, eventhough I haven't written a programming language myself, it was excitung to go through it to see how static programming languages are lowered to SSA form.
Mojo should have something showing how to write a super fast matmul and especially what's interesting for me is a fast linear attention kernel, as that's where PyTorch is getting much harder to use.
oceansky | 22 hours ago
Lastest OpenCV 5 release notes also had a lot of LLMisms.
I guess that's the new normal. Still, I am very hopeful for Mojo.
bourbonproof | 22 hours ago
winding | 22 hours ago
BeetleB | 20 hours ago
Hard to decide if the blog post is wild, or people's visceral reactions to it.
I've said it before: I believe the obsession in trying to figure out if something is AI generated will soon be classified as a mental disorder.
wiseowise | 10 hours ago
BeetleB | 3 hours ago
boesboes | 7 hours ago
I think AI use will soon be classified as a health risk worse then smoking, drug and gambling.
redlewel | 22 hours ago
fwip | 22 hours ago
Forgeties79 | 21 hours ago
ainch | 21 hours ago
fwip | 3 hours ago
sph | 21 hours ago
fwip | 18 hours ago
ryukoposting | 3 hours ago
galonk | 22 hours ago
Did they think that image would make them look fun or interesting? Because it's exactly the opposite.
brendoelfrendo | an hour ago
jibal | 22 hours ago
Yes, so basing confidence on it is totally bogus. Such comments are cheap and add nothing to the discussion of Mojo reaching 1.0 status.
phoghed | 19 hours ago
Not to worry though, if there’s nothing webshit accessible in the content there’s surely something wrong with the CSS to complain about!
brendoelfrendo | an hour ago
Unless the idea is that, in 2026, you assume your audience is an LLM that is ingesting and summarizing your content for the end user and that no human will actually read what you wrote so you don't actually need to care about signals of quality or trustworthiness. The AI generated illustration seems kind of superfluous if that's the case, though.
FrustratedMonky | 22 hours ago
So maybe an AI image isn't the worst.
andy99 | 22 hours ago
flexagoon | 20 hours ago
Yeah, that really made me triple-check if I visited a fake SEO spam website instead of the official OpenCV one. The fact that their blog looks exactly the same every single low-effort AI content farm doesn't help either.
pnt12 | 9 hours ago
boesboes | 7 hours ago
It's all just spam, filler content and I did not ask for that.
minraws | 22 hours ago
Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
rirze | 22 hours ago
That's the favorable interpretation, atleast.
akshitgaur2005 | 21 hours ago
minraws | 20 hours ago
At this point I find it deeply troubling that it isn't open source. I respect Chris I know folks who have worked with him and but at the end of the day I feel too weird about this entire closed source programming language thing.
If we complain to Nvidia about there weird closed source limitations, I think Mojo is just as bad. You don't even know what your compiler might be doing, and if it does something wrong you can't fix it, you now have to file a bug and wait until the gods from above come to your rescue.
I have had similar issues with drivers, I have faced soo many driver bugs in my work and the answer is always write more code that works around it somehow, this warp level is bad, this feature doesn't work with these values, etc. etc. Why can't I fix them, I have often on Linux just pinged the Mesa team about driver bugs with a rough draft of a patch and gotten it fixed, I can even patch and run it myself when I am in a hurry.
I feel like atleast making stuff, source available like Unreal should be the baseline for any "core" software where a bug could possibly be a major blocking issue for a developer. Windows and Mac are very bad with this.
Mac's CoreML has had soo many bugs over the last couple years I have had to email someone I know at the company to get them fixed or try to get into contact with someone.
Intel's drivers have had bugs too but I have had more contacts there which is a wash. AMD well it's AMD...
Either way closed software sucks I don't want to use fully closed stuff unless I don't have a choice people can make what they want of it. I don't really care.
I care much less about just foss.
melodyogonna | 20 hours ago
jibal | 19 hours ago
TylerE | 14 hours ago
jibal | 13 hours ago
And intelligent imaginative people can make quite a bit of sense out of announcing 1.0 prior to the conference. Open sourcing it may require efforts that simply didn't coincide with that announcement. I see this sort of pronouncement in the chat for the chess.com daily puzzle all the time -- "the solution makes no sense!" ... and yet it always does.
P.S.
> "They will probably be releasing it coincident with their August 18 conference."
Yes, I know I wrote that, genius.
And no, I didn't ask a question, and that's not a rational explanation of why you responded. And I don't owe anyone an explanation of my attitude or tone. If you don't like it then don't interact with me.
TylerE | 13 hours ago
Edit to your edit: You asked a question, I answered it. Why be a rude about it, "genius"?
swiftcoder | 22 hours ago
I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
giancarlostoro | 22 hours ago
I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python.
I do see this one overtaking Nim over time, which kind of saddens me, because I like Nim for what it is, but Mojo trying to be a superset of Python is a no-brainer for most Python developers. Reminds me of how a lot of Go devs were former Python devs not C++.
pansa2 | 18 hours ago
Not any more. That was the initial announcement, but I think then somebody actually looked at Python and realised what a complex language it is - so they refocused on being a Python-like language. Python has a reputation for being a simple language, but in reality it isn’t at all.
saghm | 15 hours ago
To preempt all of the inevitable responses: yes, I'm aware that this was started by the same guy who started LLVM and Swift. That doesn't automatically mean anything he comes up with will be great, especially when it's specifically trying to be "like" a language that doesn't really have much on common with either of those; there are plenty of instances of very smart people having an overabundance of confidence when jumping into something they assume they'll excel at and getting humbled. I'd also argue both Swift and LLVM have some common criticisms that very much are in line with the same concern I've expressed here (i.e. long term design suffering due to expanded or pivoted scope; even the name LLVM alludes to some of that history of having a somewhat different goal originally). His name is enough that I'll probably always click to take a first look at anything he comes up with, but I'm not going to ignore things that seem like issues because of that either. Smart people don't need to held to a lower standard because their work should be able to speak for itself.
FrustratedMonky | 4 hours ago
SJMG | 14 hours ago
winding | 12 hours ago
SJMG | 3 hours ago
Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
prirun | 3 hours ago
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
SJMG | 2 hours ago
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
manojlds | 21 hours ago
swiftcoder | 21 hours ago
steve1977 | 21 hours ago
tyre | 21 hours ago
mplewis | 21 hours ago
syrrim | 20 hours ago
ioasuncvinvaer | 20 hours ago
syrrim | 20 hours ago
larodi | 19 hours ago
syrrim | 19 hours ago
larodi | 10 hours ago
BeetleB | 20 hours ago
ekianjo | 12 hours ago
BeetleB | 3 hours ago
grim_io | 19 hours ago
What kind of special whitespace requirements do people have?
pansa2 | 18 hours ago
Functional-style programming has become much more popular since Python was designed in the 1990s, and there doesn’t seem to be a good way to have Python-like significant indentation and also support true anonymous functions.
maleldil | 16 hours ago
ameliaquining | 15 hours ago
winding | 12 hours ago
One interesting PL concept they implement are linear types https://mojolang.org/docs/std/traits/anytype/AnyType/
jampekka | 10 hours ago
pjmlp | 9 hours ago
Guido doesn't want them in the language, as simple as that.
pjmlp | 9 hours ago
Fraterkes | 20 hours ago
ioasuncvinvaer | 20 hours ago
ekianjo | 12 hours ago
steve1977 | 9 hours ago
usef- | 20 hours ago
People complained about this in 1999 but then I used it and it's never mattered.
dgellow | 18 hours ago
usef- | 17 hours ago
(On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)
dgellow | 16 hours ago
usef- | 15 hours ago
The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?
dgellow | 10 hours ago
ameliaquining | 15 hours ago
pjmlp | 9 hours ago
Also it isn't the only one, many ML derived languages also use indentation, including the famous F#, Standard ML, OCaml, Haskell,....
ameliaquining | 15 hours ago
jhbadger | 14 hours ago
dimator | 17 hours ago
ekianjo | 12 hours ago
jeltz | an hour ago
totalperspectiv | 21 hours ago
Very excited for Mojo once it's open sourced later this year.
cpeterso | 21 hours ago
Chris Lattner said in a Developer Voices podcast interview:
"Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
nu11ptr | 21 hours ago
melodyogonna | 17 hours ago
Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.
Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
osigurdson | 17 hours ago
melodyogonna | 16 hours ago
edflsafoiewq | 14 hours ago
What techniques?
MohamedMabrouk | 9 hours ago
pjmlp | 9 hours ago
https://www.research-collection.ethz.ch/entities/publication...
C# compiler is also fully multithreaded since the Roslyn rewrite in 2016.
melodyogonna | 8 hours ago
pjmlp | 7 hours ago
melodyogonna | 5 hours ago
ModernMech | 4 hours ago
> The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
You said they parallelized LLVM with novel techniques, but then claimed the novelty is the very act of parallelizing it. That's circular, you still haven't explained what are the novel techniques?
melodyogonna | 3 hours ago
afdbcreid | 21 hours ago
Why? Because it uses MLIR? Rust has its own MIR, it's even more not-LLVM-wrapper.
giancarlostoro | 20 hours ago
skavi | 19 hours ago
afdbcreid | 19 hours ago
But even if yes, MLIR is part of the LLVM project, so it's technically still "just an LLVM wrapper".
skavi | 17 hours ago
embedding-shape | 21 hours ago
https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.
efficax | 20 hours ago
1. https://mlir.llvm.org/
jibal | 18 hours ago
swiftcoder | 5 hours ago
timmyd | 17 hours ago
Feedback welcome as always and thanks for checking it out! Encourage you to watch ModCon next week for some exciting announcements :)
swiftcoder | an hour ago
Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
sakesun | 13 hours ago
I'd love the language and platform be succesful, nevertheless.
adsharma | 12 hours ago
You can stick to python and generate mojo or rust or lean.
There is more than one solution to the two language problem.
jillesvangurp | 12 hours ago
> "Qualcomm to Acquire Modular"
That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive.
The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc.
I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.
Certhas | 9 hours ago
And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on.
Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
pjmlp | 9 hours ago
The evolution of iPaaS low coding tools.
Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that.
COBOL is already laughing at the efforts to write so much English text to keep AI on track.
andsoitis | 4 hours ago
Sorry, but what's the pitch?
erdinc | 10 hours ago
blackhaz | 9 hours ago
https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...
samuell | 9 hours ago
FrustratedMonky | 4 hours ago
hnfwd5lqmp | 22 hours ago
jax_bro | 21 hours ago
r_lee | 21 hours ago
awesome
netdur | 21 hours ago
tyre | 21 hours ago
This gave me a chuckle. When I think of languages evolving their standards, I do think of C++. But not, you know, in a good way.
melodyogonna | 3 hours ago
cuzezzzbbfofai | 21 hours ago
derbOac | 21 hours ago
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
spprashant | 20 hours ago
It seems like a deliberate pivot towards creating an AI-era language which make GPU programming as easy as writing Python.
usef- | 19 hours ago
pansa2 | 18 hours ago
It absolutely was, but IMO was never going to happen. Python has a reputation as a simple language, but it really isn’t. It’s a very complex language hiding behind friendly syntax.
I think once the Mojo team realised that, they had to adjust their expectations.
twsted | 20 hours ago
willseth | 19 hours ago
blltprfmnk | 14 hours ago
ltbarcly3 | 19 hours ago
whimsicalism | 19 hours ago
gabrielsroka | 13 hours ago
ModernMech | 12 hours ago
bobajeff | 18 hours ago
adsharma | 12 hours ago
But mojo is a superset, not a subset. So why not use a subset, infer what you need and generate mojo?
I've never seen this question actually presented to the company and discussed in more detail.
SP3269 | 11 hours ago
Basically, same raison d'etre as that of Julia.
Certhas | 9 hours ago
jakobnissen | 7 hours ago
joddystreet | 11 hours ago
python superset would have been perfect.
I do hope the language thrives and gets a community.
All the best to the modular team.
mojo-10 | 11 hours ago
(B) MOJO should should have used Nvidia.
AbuAssar | 10 hours ago
jdnier | 10 hours ago
https://mojolang.org/nightly/docs/vision/
ubercore | 7 hours ago
EDIT: I guess this kind of answers my curiosity: https://programming-journal.org/2023/7/2/
Etheryte | 7 hours ago
tomburgs | 7 hours ago
melodyogonna | 7 hours ago
tomburgs | 6 hours ago
ryukoposting | 3 hours ago
"AI slop image below the headline" is an unmistakable mark of low-quality content written by a sophomoric AI evangelist. Let them keep watermarking their own content.
MetroWind | 58 minutes ago
What's wrong with people?