Love this intentionality: ” Our open source approach has been deliberate: we’ve found that small and tight-knit design teams (not committees) are the best for finding the “soul” of a language, but that feedback from a broader community is essential to escape an echo chamber. As such, we first open-sourced the Mojo standard library, then released hundreds of thousands of lines of kernel code written in Mojo, tools, and support. We built together with community feedback and public design proposals, and are now open sourcing the compiler. We will continue to open our processes further as Mojo keeps maturing.”
I don't think the goal of being a true Python superset ever existed.
Given that there are so many failed attempts to optimise arbitrary Python code, it was dubious from the start. Furthermore, the documentation completely ignored these challenges and made it clear that Mojo's goal was to compile to MLIR in order to write kernels for machine learning. The first example of Mojo code was a low level matrix multiplication kernel taking advantage of fancy compilation features and the documentation advertised pointers inspired by Rust's move semantics, neither of which are typically considered friendly or relevant to high level programmers.
That's a bold claim, I would be surprised if that were why they made the decision, there's other Python-like languages that don't need to pretend to be a superset to be successful.
Being a superset of Python may not be necessary to be successful, but perhaps non-committally proposing it was necessary for Modular to win the funding they wanted. While lots of people indirectly run GPU kernels with PyTorch, I think the number of people wanting to write their own kernels is considerably smaller and that this niche already has established players (plenty of whom even already build on top of MLIR), making Mojo's most obvious use case difficult to sell.
it definetely existed and was one of the major things why I was interested in it. I wished I could have used this to slowly migrate away from Python codes in Physics.
But alas they dropped the goal and for me the ball with the decision to stop following this. I will probably not write mojo code when I could use Rust or Julia instead, which are more aligned with my necessities.
It is still a goal. Mojo's semantics are still driven by Pythons, and can only deviate where safety or performance is an issue. Eventually it'll get the dynamic parts of Python
One of my favourite features of Mojo is linear types and how deeply they have been integrated into manual memory management - see:https://x.com/melodyogonna/status/2085089269484343725?s=20.
When I first learned about linear types, my first thought of the use case was making manual allocations and deallocations safer without sacrificing usability, but I didn't know what that could look like; now I do. This is great because in Mojo, pointers are surfaced a lot more than in, say, Rust, but such sharp tooling in a language you expect to be safe by default can be problematic. Linear types, combined with the origin system, give the language a lot of flexibility; it is like using a sharp tool with a safety glove: the tool isn't any less sharp, but the chances of accidentally injuring yourself are reduced.
I did a review of Mojo a few months ago focused on Python compatibility if anyone's curious about that angle. Admittedly it is a narrow angle. I want to take another look at Mojo sometime not focused on Python.
So I think the permissive license like Apache 2 without opening up for upstream contributions would be the way of future open source development. In a very similar way of SQLite. It definitely will help shield off a bunch of AI generated contributions first and foremost and then, aligning mental model with the human contributions with Mojo leader team.
Prediction: Chris Lattner will be off chasing some other shiny thing within a year. Without a strong champion, the company will be subsumed into Qualcomm and stop publishing meaningful updates.
I have this pang too, but for a different reason: everything is moving to the edge, training and inference. Who needs a complicated heterogeneous setup like this when you’re running everything locally?
Chris Lattner is now Qualcomm's VP of AI Software and Tooling, so he is now responsible for all of Qualcomms AI software. Mojo wouldn't be doing any dying
I think people underestimate the fact that Nvidia's GPUs are really good. Modular/Qualcomm's stack will provide a lot more optionality, but from what I saw in the Modcon conference on Tuesday, most of the target audience is towards other hardware vendors. At the moment, after designing a new hardware, you'd have to also build the entire software stack already existing on Cuda, ROCm, etc - this can double or triple your hardware bring up time. If you plug into Max (not Mojo), you get most of the software stack for free, so your software bring up time can go from months of engineering hours to probably weeks.
For AI? GPUs actually kinda suck. NVIDIA’s GPUs are best, and their software stack is great, but they aren’t really adapted to AI (training or inference).
I wouldn't say they suck, but they're general-purpose. Anyway, you've gotten into the core of what makes Modular's stack useful. GPUs are great, but it has become obvious that they leave performance on the table, so dedicated AI accelerators get built; however, these don't have software infrastructure and kernels that have been tuned and optimised for years, like CUDA. The bet here is that you can build great hardware, and with a little bit of effort you can unlock all the necessary software for your hardware.
Even general purpose matrix multipliers built for large linear systems instead of 3D graphics would get you orders of magnitude improvement. That’s essential what the current generation of AI accelerators are. Dedicated hardware could improve that further. I think that counts as “kinda sucks” in the absolute sense. It’s just far faster and more efficient than any other thing you can buy off the shelf today.
This is really exciting. I've been using Mojo off and on for side projects over the last two years.
(copying from some previous Mojo threads) It's got an ownership system adjacent to Rust, comptime similar to Zig, and a first class dependent type system. Even more exciting, is that uses LLVM (to the best of my understanding) in some novel ways and for more optimizations.
Hm, in docs they say that dependent type system is not first class seems.
Is it even dependent? More like refinement types, which seems will be in Rust too.Also HN recently mentioned Rust building similar llvm based integration with GPU.
But compared with Python, Julia, Matlab, R, Rust, C, C++ - Mojo feel relief for working with numerics.
I don't agree at all with your last paragraph. MATLAB and Julia are lovely for numerics, maths is terse and looks like maths! Mojo is hobbled by choosing Python style syntax, which does not lend itself well to maths.
WRT the type system, I agree MATLAB is a mess but Julia's multiple dispatch feels more like maths than any other language I've tried.
I coded Matlab in uni, never got it. And had to look Julia code. I have to learn it to read. I am more SEng rather then Sci or Quant. And on compile time types. So for me Julia is foreign and forces me to look both Python and Julia.
I think problems is too strong a word, it's just how the syntax looks. And of course it's far better than say C++. But specifically, the lack of native vectors/matrices and very few infix operators (e.g dot product, and matrix multiplication with @ is clunky). Explicit but generic broadcasting using `.` also helps.
The way that types interact with methods _feels_ like maths. I.e. you have a method made up of mathematical operators, if you swap out an input, it typically does the natural and correct thing.
you can but through a python interpreter in the mojo process so you get the same numpy speed with mojo<->ptyhon interop overhead.
NuMojo is native and also is now starting to support features that numpy can't really do like native GPU execution.
I wonder if the Python-to-Mojo overhead is significant enough where language-native bindings make more sense. I'd be interested in seeing some benchmarks.
The innovative potential of Mojo would be constrained to relatively niche and senior dev circles until they get a Windows release, which probably won't happen anytime soon. Python keeps the throne for now.
I don't understand this premise. And the more I think about it, the less sense it makes. On the grand scale of things, Windows is the niche platform here. For consumer desktop use cases, it is king, but nobody deploys on it for the use cases that the first version of Mojo is optimised for.
> On the grand scale of things, Windows is the niche platform here.
They plan Windows support: ” Mojo has supported macOS and Linux for years, and Windows developers have been able to use it through WSL. Native Windows support has always been one of our most common requests from developers.
Millions of developers build on Windows every day, across an enormous range of applications and workloads. We believe Mojo can have a meaningful impact across that ecosystem. Bringing Mojo to Windows the right way requires deep expertise in the platform, which is why we’re delighted that the Microsoft Windows team sees the same opportunity we do — and that we’re working together to make it happen.”
Many companies only allow for Windows computers, even if the servers are UNIX like, additionally as proven by NVidia and CUDA, Windows laptops are a great way to get students interested on the technology.
In the category of AI/HPC software Mojo aims to displace (which is my industry), I don't know many people who care that much about running Windows. The software I work on may only run as a Docker image or directly in a Linux/WSL. Mojo is hardly the only tool in the space (currently) lacking Windows support.
Senior is the last word in use to describe myself as a developer, personally, and I think it's hard to overstate the current economical significance of this software niche. Granted that it IS a niche and nobody would recommend Mojo for, say, kernels in video games or art editors.
We already could do that with VMWare Workstation and VirtualBox, since at least 2010.
WSL could have been avoided if Microsoft had been more serious about the POSIX subsystem in Windows NT, or later Subsystem for UNIX-based Applications that was available until 2016.
Because nowadays Linux ABI is more relevant than pure POSIX compliance.
BSDs and all surviving mainframes and micros also have either Linux VM support or syscall compatibility.
Microsoft saw those geeks that were buying Apple as shinny Linux, and then complaining about lack of compatibility, or that they only cared about POSIX toys but not really Linux proper, and saw a business case in shipping Linux in the box to counter that.
Which had they kept and improved POSIX support since Windows NT 3.51, that would never been a matter to discuss about.
Especially when it is actually successful at what it was designed to be, a faster Python for data science folks, having gotten enough researchers, more than most toy languages that almost daily drop on HN and Reddit.
I was excited to try Julia, but then, as I saw it was an interpreted language, with bulky runtime, slow startup times and bloated library sizes - my initial interest quickly faded.
For the same reasons I see languages like Python, Java, C# as inferior.
How is Julia an interpreted language? I sometimes wish there was a robust interpreter for Julia when the compilation latency is not worth the execution speed.
I indeed don't know about Java, but with C# there are a lot of limitations if you want AOT compilation and you still get the bloated binary and limited performance.
I also, personally, never seen a single project written in either Java or C# that distributes aot binaries.
I used Mojo a while back before LLM laziness kicked in and agents started writing all the code. I didn't know anything about GPU programming and it almost felt dirty how easy it was to get some performant kernels running (5070). Even I could do it.
I'm in financial engineering and I feel like mojo is definitely the language for that field in the future, especially with the relatively easy python interop for legacy stuff.
Finally, gonna be a lot of fun to finally play around with, lets see how it compares to Python for ML ultimately :) The build process is quite heavy, pinning all my cores at 100% on a Threadripper 9970X for ~15 minutes which isn't so common.
Curious to know what setups they've tested Mojo on so far, as I understood it to be mainly for ML/AI stuff, so commonly pretty beefy workstation, yet I'm getting warnings that it's not recognizing my GPU (RTX Pro 6000). Seems easy enough to work around by editing the gpu_mapping in MODULE.bazel so I guess isn't a huge issue. Just strange to see a really CPU-heavy build, then not recognizing a somewhat common "prosumer" GPU (common in the ecosystem and expected user audience at least).
My expectation is always that sm120 is the forgotten orphan in the mix and that I'll have to monkey-patch my way to getting things running (and its not always due to lack of tcgen05 or other "real blackwell" features, its often just failing fallback kernel paths doing things that were clearly not tested).
Mojo's design goals would in theory help this problem long term, but my sm120 PTSD still lingers.
Wow. I've been waiting years for this, ever since Modular first announced Mojo. To be entirely honest, I thought they would walk back on this promise and so I never really gave the language a chance. With this and the 1.0 release, it looks like a better time than ever to start taking a look into it.
Cue responses from all the people a week ago moaning about it not being open source on day one, despite there being a precedent from Chris Lattner that it would all go down exactly like this.
Technically soruce available now with the promise of accepting contributions (thus becoming fully open source) early next year. But since it is an Apache 2 license (like the rest of the LLVM project) you are already allowed to fork and contribute to your own fork right now, just no upstreaming.
For many the closed source nature of the compiler was a knock-out criterion. We will see if Mojo can gain traction now or if it has missed its window of opportunity.
Maybe it is not listed by the OSI, but it is 'open source' in practice, if the source is also in the public domain. The FSF's definition of free software makes more sense not only ideologically, but also because it does not try to be exhaustive.
One problem is that a large part of Europe doesn't understand the concept of public domain. I'm not legally allowed to not own my creation, except by transferring it to someone else. That's why licences like CC0 exist.
You're just making up your own definitions of things.
If the complete source is available and distributable under an OSI-approved license, it is absolutely Open Source. Accepting outside contributions is nowhere in the definition of Open Source.
It seems like the same sort of category error that some people make regarding free speech.
Just as you can say whatever you want, but facebook/twitter/reddit/whoever is not required to give you a soapbox, you can download this software and make whatever changes you want, but nobody is required to give a shit about your proposed changes.
Technically, the criteria for open source is freedom to freely distribute and modify the source code, not to upstream changes. That's a different for thing.
Love this intentionality: ” Our open source approach has been deliberate: we’ve found that small and tight-knit design teams (not committees) are the best for finding the “soul” of a language, but that feedback from a broader community is essential to escape an echo chamber. As such, we first open-sourced the Mojo standard library, then released hundreds of thousands of lines of kernel code written in Mojo, tools, and support. We built together with community feedback and public design proposals, and are now open sourcing the compiler. We will continue to open our processes further as Mojo keeps maturing.”
I wish they never abandoned the goal of being a true Python superset. That would have been something.
I don't think the goal of being a true Python superset ever existed.
Given that there are so many failed attempts to optimise arbitrary Python code, it was dubious from the start. Furthermore, the documentation completely ignored these challenges and made it clear that Mojo's goal was to compile to MLIR in order to write kernels for machine learning. The first example of Mojo code was a low level matrix multiplication kernel taking advantage of fancy compilation features and the documentation advertised pointers inspired by Rust's move semantics, neither of which are typically considered friendly or relevant to high level programmers.
It was in their roadmap:
https://forum.modular.com/t/mojo-as-a-python-superset/2490
I think it was there for marketing purposes and that there was little actual intention to work on it.
From the roadmap:
>Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't.
That's a bold claim, I would be surprised if that were why they made the decision, there's other Python-like languages that don't need to pretend to be a superset to be successful.
Being a superset of Python may not be necessary to be successful, but perhaps non-committally proposing it was necessary for Modular to win the funding they wanted. While lots of people indirectly run GPU kernels with PyTorch, I think the number of people wanting to write their own kernels is considerably smaller and that this niche already has established players (plenty of whom even already build on top of MLIR), making Mojo's most obvious use case difficult to sell.
it definetely existed and was one of the major things why I was interested in it. I wished I could have used this to slowly migrate away from Python codes in Physics.
But alas they dropped the goal and for me the ball with the decision to stop following this. I will probably not write mojo code when I could use Rust or Julia instead, which are more aligned with my necessities.
I don't think this goal was ever realistic, it was just a marketing pitch to get a foot in the door.
It is still a goal. Mojo's semantics are still driven by Pythons, and can only deviate where safety or performance is an issue. Eventually it'll get the dynamic parts of Python
It still feels python enough.
One of my favourite features of Mojo is linear types and how deeply they have been integrated into manual memory management - see:https://x.com/melodyogonna/status/2085089269484343725?s=20. When I first learned about linear types, my first thought of the use case was making manual allocations and deallocations safer without sacrificing usability, but I didn't know what that could look like; now I do. This is great because in Mojo, pointers are surfaced a lot more than in, say, Rust, but such sharp tooling in a language you expect to be safe by default can be problematic. Linear types, combined with the origin system, give the language a lot of flexibility; it is like using a sharp tool with a safety glove: the tool isn't any less sharp, but the chances of accidentally injuring yourself are reduced.
How does mojos linear types work in a concurrent environment?
Mojo's concurrency model is yet to be figured out.
I did a review of Mojo a few months ago focused on Python compatibility if anyone's curious about that angle. Admittedly it is a narrow angle. I want to take another look at Mojo sometime not focused on Python.
https://theconsensus.dev/p/2026/03/12/mojos-not-yet-python.h...
So I think the permissive license like Apache 2 without opening up for upstream contributions would be the way of future open source development. In a very similar way of SQLite. It definitely will help shield off a bunch of AI generated contributions first and foremost and then, aligning mental model with the human contributions with Mojo leader team.
Recent and related:
Mojo 1.0 - https://news.ycombinator.com/item?id=49261128 - Aug 2026 (244 comments)
From yesterday:
The Mojo language (by Modular, now Qualcomm) is now open-source - https://news.ycombinator.com/item?id=49358327 - 108 comments
As long as it was proprietary, I could ignore it. Now, I guess I have to learn a little something about it.
"Qualcomm to Acquire Modular 06/24/2026"
https://investor.qualcomm.com/news-events/press-releases/new...
Can acqui-death be far away...?
Prediction: Chris Lattner will be off chasing some other shiny thing within a year. Without a strong champion, the company will be subsumed into Qualcomm and stop publishing meaningful updates.
I have this pang too, but for a different reason: everything is moving to the edge, training and inference. Who needs a complicated heterogeneous setup like this when you’re running everything locally?
100% on both counts but don't know if it's "within a year", or within a couple.
Chris Lattner is now Qualcomm's VP of AI Software and Tooling, so he is now responsible for all of Qualcomms AI software. Mojo wouldn't be doing any dying
Chris Lattner is now very very rich. Once his lockup expires he will not need to work for anyone.
I'm sure Qualcomm would love him to stick around but suspect that they'll maintain mojo even if he leaves.
Is this a case of of Qualcomm commoditizing their complements? Does Mojo have a potential for disrupting Nvidia's current market position?
https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
I think people underestimate the fact that Nvidia's GPUs are really good. Modular/Qualcomm's stack will provide a lot more optionality, but from what I saw in the Modcon conference on Tuesday, most of the target audience is towards other hardware vendors. At the moment, after designing a new hardware, you'd have to also build the entire software stack already existing on Cuda, ROCm, etc - this can double or triple your hardware bring up time. If you plug into Max (not Mojo), you get most of the software stack for free, so your software bring up time can go from months of engineering hours to probably weeks.
For AI? GPUs actually kinda suck. NVIDIA’s GPUs are best, and their software stack is great, but they aren’t really adapted to AI (training or inference).
I wouldn't say they suck, but they're general-purpose. Anyway, you've gotten into the core of what makes Modular's stack useful. GPUs are great, but it has become obvious that they leave performance on the table, so dedicated AI accelerators get built; however, these don't have software infrastructure and kernels that have been tuned and optimised for years, like CUDA. The bet here is that you can build great hardware, and with a little bit of effort you can unlock all the necessary software for your hardware.
Even general purpose matrix multipliers built for large linear systems instead of 3D graphics would get you orders of magnitude improvement. That’s essential what the current generation of AI accelerators are. Dedicated hardware could improve that further. I think that counts as “kinda sucks” in the absolute sense. It’s just far faster and more efficient than any other thing you can buy off the shelf today.
This is really exciting. I've been using Mojo off and on for side projects over the last two years.
(copying from some previous Mojo threads) It's got an ownership system adjacent to Rust, comptime similar to Zig, and a first class dependent type system. Even more exciting, is that uses LLVM (to the best of my understanding) in some novel ways and for more optimizations.
Hm, in docs they say that dependent type system is not first class seems.
Is it even dependent? More like refinement types, which seems will be in Rust too.Also HN recently mentioned Rust building similar llvm based integration with GPU.
But compared with Python, Julia, Matlab, R, Rust, C, C++ - Mojo feel relief for working with numerics.
I don't agree at all with your last paragraph. MATLAB and Julia are lovely for numerics, maths is terse and looks like maths! Mojo is hobbled by choosing Python style syntax, which does not lend itself well to maths.
WRT the type system, I agree MATLAB is a mess but Julia's multiple dispatch feels more like maths than any other language I've tried.
I coded Matlab in uni, never got it. And had to look Julia code. I have to learn it to read. I am more SEng rather then Sci or Quant. And on compile time types. So for me Julia is foreign and forces me to look both Python and Julia.
What problems do you run into for maths with Python? For linear algebra and ML with Jax/Numpy I find it quite readable.
I think problems is too strong a word, it's just how the syntax looks. And of course it's far better than say C++. But specifically, the lack of native vectors/matrices and very few infix operators (e.g dot product, and matrix multiplication with @ is clunky). Explicit but generic broadcasting using `.` also helps.
The way that types interact with methods _feels_ like maths. I.e. you have a method made up of mathematical operators, if you swap out an input, it typically does the natural and correct thing.
> But compared with Python, Julia, Matlab, R, Rust, C, C++ - Mojo feel relief for working with numerics.
Out of those, Julia is the only one that combines Multiple Dispatch and native code, both important for numerics.
Very exciting. Closed source was one of the main things making me not try it out yet.
Any good resources for getting started? And anything on doing NumPy/SciPy-like stuff in it?
https://mojolang.org is the best spot for getting started generally. numojo is the closest thing to numpy right now. You can check out more packages here: https://github.com/modular/modular-community/tree/main/recip...
NuMojo is the closest thing in the ecosystem to numpy and the final aim is offer numpy-like experience. https://github.com/Mojo-Numerics-and-Algorithms-group/NuMojo
Can't you just use Numpy directly in Mojo?
you can but through a python interpreter in the mojo process so you get the same numpy speed with mojo<->ptyhon interop overhead. NuMojo is native and also is now starting to support features that numpy can't really do like native GPU execution.
I wonder if the Python-to-Mojo overhead is significant enough where language-native bindings make more sense. I'd be interested in seeing some benchmarks.
> numpy can't really do like native GPU execution
I'd be interested to see where GPU code beats NUMPY's SIMD implementation, which is really
> features that numpy can't really do like native GPU execution
we use numpy + jax for that; works well
Such an exciting time for Mojo, I don't think people realize just yet the innovation being brought to fore here.
The innovative potential of Mojo would be constrained to relatively niche and senior dev circles until they get a Windows release, which probably won't happen anytime soon. Python keeps the throne for now.
I don't understand this premise. And the more I think about it, the less sense it makes. On the grand scale of things, Windows is the niche platform here. For consumer desktop use cases, it is king, but nobody deploys on it for the use cases that the first version of Mojo is optimised for.
> On the grand scale of things, Windows is the niche platform here.
They plan Windows support: ” Mojo has supported macOS and Linux for years, and Windows developers have been able to use it through WSL. Native Windows support has always been one of our most common requests from developers.
Millions of developers build on Windows every day, across an enormous range of applications and workloads. We believe Mojo can have a meaningful impact across that ecosystem. Bringing Mojo to Windows the right way requires deep expertise in the platform, which is why we’re delighted that the Microsoft Windows team sees the same opportunity we do — and that we’re working together to make it happen.”
—- https://www.modular.com/blog/modcon-announcements
Many companies only allow for Windows computers, even if the servers are UNIX like, additionally as proven by NVidia and CUDA, Windows laptops are a great way to get students interested on the technology.
In the category of AI/HPC software Mojo aims to displace (which is my industry), I don't know many people who care that much about running Windows. The software I work on may only run as a Docker image or directly in a Linux/WSL. Mojo is hardly the only tool in the space (currently) lacking Windows support.
I'd put you in the "relatively niche and senior" bucket without even thinking.
Senior is the last word in use to describe myself as a developer, personally, and I think it's hard to overstate the current economical significance of this software niche. Granted that it IS a niche and nobody would recommend Mojo for, say, kernels in video games or art editors.
[flagged]
The niche is so big that Microsoft invented WSL to run Linux programs on Windows.
We already could do that with VMWare Workstation and VirtualBox, since at least 2010.
WSL could have been avoided if Microsoft had been more serious about the POSIX subsystem in Windows NT, or later Subsystem for UNIX-based Applications that was available until 2016.
> We already could do that with VMWare Workstation and VirtualBox, since at least 2010.
Yes but MS obviously viewed it as important enough to bring it inside their ecosystem.
As for the POSIX subsystem in NT, MacOS is POSIX compliant but Apple provide virtualization APIs to run Linux.
Because nowadays Linux ABI is more relevant than pure POSIX compliance.
BSDs and all surviving mainframes and micros also have either Linux VM support or syscall compatibility.
Microsoft saw those geeks that were buying Apple as shinny Linux, and then complaining about lack of compatibility, or that they only cared about POSIX toys but not really Linux proper, and saw a business case in shipping Linux in the box to counter that.
Which had they kept and improved POSIX support since Windows NT 3.51, that would never been a matter to discuss about.
They announced a partnership with Microsoft today.
That's quite promising - https://www.modular.com/blog/modcon-announcements#:~:text=Wi...
And Julia as well.
It's a sad time to be a fan of Julia-- everyone forgets it's there.
Especially when it is actually successful at what it was designed to be, a faster Python for data science folks, having gotten enough researchers, more than most toy languages that almost daily drop on HN and Reddit.
I was excited to try Julia, but then, as I saw it was an interpreted language, with bulky runtime, slow startup times and bloated library sizes - my initial interest quickly faded.
For the same reasons I see languages like Python, Java, C# as inferior.
How is Julia an interpreted language? I sometimes wish there was a robust interpreter for Julia when the compilation latency is not worth the execution speed.
I still classify JIT languages as interpreted, because they require a runtime and it kills the convenience of sharing small binary e.g. in C or Nim.
And Julia docs are also unambigious in stating that code is sometimes interpreted[0]:
> jl_toplevel_eval_flex() then uses some simple heuristics to decide whether to JIT compile the AST or to interpret it directly.
[0] - https://docs.julialang.org/en/v1/devdocs/eval/#Julia-Executi...
Julia compiles to native code, same as C++/Rust.
Java and C# definitely don't belong on the same basket.
And inferior to what, the crab?
Inferior to languages that compile to native binaries, not burning dramatically more cpu cycles than necessary.
Showing your ignorance regarding Java and C# ecosystems and available compilers on that reply.
I indeed don't know about Java, but with C# there are a lot of limitations if you want AOT compilation and you still get the bloated binary and limited performance.
I also, personally, never seen a single project written in either Java or C# that distributes aot binaries.
You mean bloated as Go, the superior language?
The limited performance of game engines like the one used by Capcom for Devil May Cry on the Playstation 5?
Java binaries deployed in embedded systems by PTC and Aicas are AOT compiled.
Yes, as bloated as Go. I consider Java, C# and Go roughly equivalent in speed, space, and memory.
I used Mojo a while back before LLM laziness kicked in and agents started writing all the code. I didn't know anything about GPU programming and it almost felt dirty how easy it was to get some performant kernels running (5070). Even I could do it.
I'm in financial engineering and I feel like mojo is definitely the language for that field in the future, especially with the relatively easy python interop for legacy stuff.
I wonder how much chance of broader adoption Mojo has now when seemingly everyone has succumbed to that LLM laziness.
Zilch. Probably why they are open sourcing it.
[dead]
Anything in our stack is modern C++ if we can help it. If Mojo can replace those kernels without the Python runtime sitting underneath, even better.
Related:
Mojo 1.0
https://news.ycombinator.com/item?id=49261128
Finally, gonna be a lot of fun to finally play around with, lets see how it compares to Python for ML ultimately :) The build process is quite heavy, pinning all my cores at 100% on a Threadripper 9970X for ~15 minutes which isn't so common.
Curious to know what setups they've tested Mojo on so far, as I understood it to be mainly for ML/AI stuff, so commonly pretty beefy workstation, yet I'm getting warnings that it's not recognizing my GPU (RTX Pro 6000). Seems easy enough to work around by editing the gpu_mapping in MODULE.bazel so I guess isn't a huge issue. Just strange to see a really CPU-heavy build, then not recognizing a somewhat common "prosumer" GPU (common in the ecosystem and expected user audience at least).
My expectation is always that sm120 is the forgotten orphan in the mix and that I'll have to monkey-patch my way to getting things running (and its not always due to lack of tcgen05 or other "real blackwell" features, its often just failing fallback kernel paths doing things that were clearly not tested).
Mojo's design goals would in theory help this problem long term, but my sm120 PTSD still lingers.
Wow. I've been waiting years for this, ever since Modular first announced Mojo. To be entirely honest, I thought they would walk back on this promise and so I never really gave the language a chance. With this and the 1.0 release, it looks like a better time than ever to start taking a look into it.
"Modular Confidential (obviously), May 14, 2022"
lol, feels like espionage
https://github.com/modular/modular/blob/main/KGEN/docs/Desig...
Compiler walkthrough
https://github.com/modular/modular/blob/main/KGEN/docs/MojoC...
I found it a bit curious that Mojo seems more readable, while at the same time less compact, than Rust.
At least according to my small experiment:
https://x.com/smllmp/status/2055602226240893043
Interesting, I found the Rust code _far_ more readable.
Cue responses from all the people a week ago moaning about it not being open source on day one, despite there being a precedent from Chris Lattner that it would all go down exactly like this.
PR here: https://github.com/modular/modular/pull/6904
What a beautiful standard library btw. Much to learn and take from.
Related post with relevant pr: https://news.ycombinator.com/item?id=49347777
How is Mojo compared to Julia?
Can we get back the many thousands of hours wasted by humans holding their noses and pronouncing Lattner as an open source fraud?
This is exciting
Technically soruce available now with the promise of accepting contributions (thus becoming fully open source) early next year. But since it is an Apache 2 license (like the rest of the LLVM project) you are already allowed to fork and contribute to your own fork right now, just no upstreaming.
For many the closed source nature of the compiler was a knock-out criterion. We will see if Mojo can gain traction now or if it has missed its window of opportunity.
It’s open source under the Apache 2 license, not source available.
Accepting contributions is not required to be open source.
SQLite doesn’t accept contributions from random people either [0] (though you could argue being public domain isn’t being open source).
Anyway, this is great, I was waiting for this to take the language for a spin! Congrats to the Mojo team!
[0]: https://simonwillison.net/2025/Dec/29/copyright-release/
Maybe it is not listed by the OSI, but it is 'open source' in practice, if the source is also in the public domain. The FSF's definition of free software makes more sense not only ideologically, but also because it does not try to be exhaustive.
One problem is that a large part of Europe doesn't understand the concept of public domain. I'm not legally allowed to not own my creation, except by transferring it to someone else. That's why licences like CC0 exist.
You're just making up your own definitions of things.
If the complete source is available and distributable under an OSI-approved license, it is absolutely Open Source. Accepting outside contributions is nowhere in the definition of Open Source.
It seems like the same sort of category error that some people make regarding free speech.
Just as you can say whatever you want, but facebook/twitter/reddit/whoever is not required to give you a soapbox, you can download this software and make whatever changes you want, but nobody is required to give a shit about your proposed changes.
Technically, the criteria for open source is freedom to freely distribute and modify the source code, not to upstream changes. That's a different for thing.
https://opensource.org/osd