I would add quick note to this as title is misleading
* It was partially open-sourced before this. There were a lot of cool things they open sourced before like MAX for large scale LLM serving which was outperforming VLLM, Dynamo, etc on a lot of models. (super valuable GPU kernels). This is why Qualcomm acquire them imo.
* Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning.
Mojo is an awesome language, I've used it a lot as a Swift/Python lover. A couple things though
* If you want to understand Mojo spend 10x the time in MLIR before. It's just a fancy MLIR wrapper (good thing)
* They still haven't lived up to the python "superset" promise and that's the big thing preventing bigger adoption.
When people talk about a language being open source they primarily mean the compiler. A closed compiler surrounded by a collection of open source things is an anti-pattern and trap to be avoided if you're interested in open tools, that's why open sourcing the Mojo compiler was so important to many people.
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right.
Chris literally was saying it from the very beginning (you can watch early interviews, obviously he was being asked about it), everything that happens with progressive opening is what he said he'll do and he gave rationale for it which is summarized by what parent comment says.
That doesn't seem to address what the parent comment says; they're arguing that the rationale for the progressive opening doesn't make sense, not that it didn't or wouldn't happen. If I say "I'm going to work on feature XYZ at work today because the sky is yellow and grass is purple", it would not make sense to defend my claim tomorrow by pointing out that I did work on feature XYZ.
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully ope source at
I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it. Yes, they might write code that depends on things that could change, but until last week it wasn't even 1.0 anyhow, so it's not like stuff might not break for people even if they didn't do that. Why was the language even being marketed at all pre-1.0 if "scaling" too quickly is a genuine concern?
The only explanation that makes any sense to me is that he (or his employer) just didn't really care about prioritizing making it open. That's totally fair, but being disingenuous about is not. It honestly just sounds like they didn't want to admit that they didn't care to prioritize being open source, and I think that has some potentially concerning implications for what to expect in terms of communication around the direction of the language and ecosystem in the future. The fact that it's being developed in the open now is good, but it doesn't seem like the actual decision making is, and that's a red flag.
>I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it.
Deep link to Chris Lattner interview where he says he learned lessons from Swift being rapidly released as open source meant that early design decisions that were suboptimal caused quick revisions. This caused a lot of complaints when later revisions to Swift caused breakages. This caused a lot of stress for Chris & the Swift team so he says he didn't want to repeat that for Mojo.
Sure, one can simple redo the exact same playbook with Mojo and iterate out in the open with early versions, and when people complain again about their code breaking, he can "just ignore it" but he didn't like that experience with Swift.
That doesn't clarify anything at all to me at least. If the goal was to avoid people depending on it before it was ready, why had I been hearing about it for so long before this? Something being marketed is not consistent with a concern to avoid having people rely on it and voice their opinions.
>to avoid people depending on it before it was ready, why had I been hearing about it for so long before this?
There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.
I think it's as simple as comparing the the community dynamics of 2 different timelines:
- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0
- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0
Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.
> Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
Yes, and it's open source, and more to the point, it's because the developers do genuinely seem to want feedback and interaction with the community. That's ostensibly the entire point of having public release announcements, which Mojo has had before 1.0.
> The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
That does not seem accurate in terms of what I'm asking about here; if I'm reading the history right, Swift was not open source until version 2.2.
It's still not clear to me how any what you have said addresses what I'm asking: how does being closed source solve the problem that's cited as the reason for it being closed for so long, and why wouldn't not marketing/releasing the language at all be the actual solution to those sort of problems?
I don't understand the point you're trying to make. Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? I don't buy the claim that a pre-1.0 language only a few years old without widespread production use is comparable to one of the most widely used languages on the planet that had been around for close to two decades at the time of what you're describing.
Even if I did think that was a comparable precedent, that still doesn't address the more direct point I made about marketing the language at all if this was a concern. What does being closed source do to prevent people from running old versions of a compiler to avoid updating their code?
It prevents endless discussions on github, hurt egos when my precious PR is rejected by committers, and commentary on not being true open source because they are not welcoming source contribution, feature request, when they are trying stabilize compiler and so on.
Now none of these are guaranteed to happen when it is open source. But at least it is guaranteed to not happen when its not open source.
I don't understand that argument at all, unless you think that the only value of open source is in the potential for people to say nice things about your project. If you think there's inherent value in something being open source, you don't even need to have a Github repo (a tarball on your website with the source code is open source), and nothing anyone says would take away from that inherent value.
I'm firmly of the opinion that there's inherent value in being open source. I would honestly expect most developers to recognize that nowadays, but maybe I'm wrong. My concern is that someone who doesn't think this is the case is probably more likely to also not want to come right out and say it, because that would potentially prevent them from getting the value they're truly looking for from the stuff they do open source. The justifications that are being given here is that they seem to be heavily predicated on the value of open source being primarily from marketing rather than the very nature of code being open having value on its own, and I would be both surprised and disappointed if that's the opinion of the people in charge of Mojo. I'm sincerely hoping that there's something else going on here though, so I'm trying to give the benefit of the doubt and see if I'm missing something.
Okay, but by that logic, if I can point to one instance of something suboptimal happening due to software being closed source, then it's reasonable to be wary of that too. I don't see how this is a plausible justification for keeping something closed source in the absence of taking into account the likelihood of something similar happening here, and for the reasons I laid out previously, I think it's borderline absurd to claim that was a real concern in the timeline that Mojo was closed.
People choose what to worry about. You can say it's unfair because they could've worried about a different set of things, but at the end of the day it's their choice.
I'm not saying you can't worry about this; I'm saying it does not seem to be a particular compelling reason for Mojo being closed source for so long, and I'm dubious that the rationale was due to anything like this.
Has the title changed since you wrote this? It doesn't seem misleading to me. Misleading would be if it still wasn't fully open source. "It was partly open before" doesn't seem like it's worth a big warning. But that's just my impression FWIW
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning.
Then he has learned the completely wrong lesson. Swift spent its first years floundering from breaking change to breaking change (from Swift 1.0 in 2014 to approximately Swift 5.0 in 2019) precisely because it wasn't open-sourced from the outset, instead being developed in the traditional airtight Apple fashion. In contrast, Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years pushing embarrassing major releases to an allegedly-1.0 language to fix problems that any actual user could have identified.
Well I think point was if they had gotten some fundamental things right from beginning they would not have to go through this 4.0 -> 5.0 breakage mess.
> Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years
One can keep pounding on this but endless discussions about pros/cons Rust Async model, library, framework bifurcation and shortcuts to deal with it does not seem like given an open design win that many in Rust community assume.
Going by the way Rust always seems to get inserted in any language related discussion no matter what, IMO it could a meme "What would Rust people do?" when deciding what should not be done.
I think a bigger issue than open source timing is the community governance necessary to shape a tool that serves the needs of a lot of stakeholders. Swift has lived under the shadow of Apple's (often secret) product priorities. The extremely poor backwards compatibility is why I invested in Rust instead, and I think Chris has expressed some misgivings about how the function builder stuff got added unilaterally. It appears what they're trying to do with Mojo is build a more coherent starting design with a closed process but the experience of client work, and then open having skipped over some of the teething issues. We'll see if it works.
> IMO it could a meme "What would Rust people do?" when deciding what should not be done
You betray your own ignorance here. Rust became massively successful despite having no corporate mandate or Big Tech progenitor, precisely because it listened to its users and empowered them to participate in the language design and development process. Trying to feebly gesture in the direction of Rust's async support doubly betrays your ignorance, both because Rust's async support is extremely good for its given design goals (not that it couldn't still be better), but also because you don't appear to realize that being developed in the open was what revealed the disastrous interactions between Rust's goals and the original pre-1.0 green thread runtime which characterized the language for a large proportion of its nascent development. Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.
"There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'" ~ Isaac Asimov, 1980
True. On positive side sometimes cult members do see wrong in their ways and apologize[1] . Sadly it is not always they will do that. Mostly they will spend time on attacking non-members.
I'm glad that it's open source now and they are supporting a lot more hardware. There are some interesting features that I hope the language design community pays attention to.
It's built on top of MLIR so you can make compiler optimizations in a library instead of the compiler. I believe Reactant.jl has been using MLIR for optimizing higher level abstractions in Julia. Imagine a Lisp with that capability.
Mojo as MLIR++ is how I've thought about it as well.
Many users will find transpiling static python to mojo an interesting path.
Updating py2many --mojo to 1.0 to see what breaks.
Also looking forward to translating existing python adt module to mojo Variant in phase 2. I hope the mojo pattern matching proposal looks more like rust (expression) and not like python (statement).
IMO saying julia is literally a lisp is just not worth the type of discussion it generates. I'd much prefer to say the important part: Julia learned a ton of very important lessons from the lisp family of languages, and has integrated a lot of them.
The parser and lowering passes were in femtolisp, and yes Jeff wrote femtolisp.
However, There's now a pure julia implementation of the parser that's on by default, and the julia implementation of lowering is also almost done and ready to replace the femtolisp one.
But honestly, these things aren't really what I mean when I say julia is lispy, those are just easter eggs. I more mean the language design and semantics.
Does this project have any meaningful traction? Seemed like a cool idea, but I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...
I found that a big issue with it in practice is that the numbers are just not great, and the repo is very vibe-coded. When the numbers are great, it's sometimes cheating with the setup. For example some GEMMs only compute each 8th value and reach close to peak TFLOPs because of this, but it's a vibe-coded reward hack and the verifier does not check all numbers of the target.
Also, compilers have a lot to prove in 2026. Why not just hill-climb a Triton or Cuda kernel if you need perf?
> But I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...
At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem. Ocaml is barely mentioned in the news and rarely HNers here use that language, but it is Jane Street that maintains and uses it.
Judging by hype isn't a great way of evaluating a language. I am not going to check the entire Nvidia stack, from CUDA, to CUTLASS to cuDNN and even on PyTorch's side just to solve a runtime error that could have originated from either place when Mojo solves all of that.
Jane Street's use of OCamel gives them a comparative advantage in hiring. Many devs put a premium on the tools they use. Same story with Anduril/Mercury using Haskell. You can run a successful prop trading firm/weapons design shop/startup-banking(?) platform without these things. They differentiate you from your competitors by being cool, not by being the best technical solution. If anything they were otherwise unprove at scale and out of pure engineering consideration a gamble. Developers are consumers.
> At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem.
No need for snarky comments. These days tools/frameworks/languages/libraries/etc are popping all the time. Do you expect people to research every simple signal they catch in the wild?
The interesting opportunity in 2026 for languages is that an LLM doesn't complain if there's an ecosystem or whether any other LLMs or people are using a language, they'll just write the code in whatever language you tell it to. Already authors are writing languages with features aimed at making it more more attractive for AI to write than people. Also great for working with research languages. I just used AI to write a Halide program and I wouldn't have bothered to do so before, for the reasons you state.
the main value proposition of mojo is being a (modern language for heterogenous compute). when writing code for the CPU, it is a nice language. it looks a bit like python, have arguably one of the best SIMD abstraction, a bit easier than Rust .. etc. but in my opinion, that does not justify deep investment in learning the language vs rust or zig.
what sets Mojo apart is that it was designed from the grounds up to natively supprt other types of hardware (starting with GPUs).
I have been in the mojo community from the beginning and almost every other project presentation starts with (I wanted to do XYZ in my domain and I could match or get close to Rust, C++ perf but then I wanted to see if I can make work on the GPU and it was much easier than expected and now I can solve my problem 10x faster).
this is massive advantage that is underutilized outside of the AI/LLM and few other niches.
running natively and being portable to NVIDIA/AMD/Apple GPUs means that you can transform any arbitrary workload you have in mind to the GPU and you won't need to worry about the separate CUDA/ROCm/Metal stacks, slightly different programming models, building headaches. you will be using the same language and the same compiler for CPUs and GPUs (all of them). or you won't need to coerce your problem in the shape of Triton to make it portable. If you have a problem in mind and don't like what you see? write your own GPU abstractions, containers, data moving and pipelining logic, work partitioning .. etc. this is extremely powerful and it sets Mojo apart from any other mainstream systems language that I have seen.
that's why bigger mojo projects (even pre 1.0) like NuMojo and Marrow are all dabbling with GPU support even before the first stable release.
and now with support for TPUs and Trainium chips it is becoming even better. some problems will work better on some architectures and you will be able to split your problem to the best hardware doing some work on the CPU and some work on the accelerator(s) of choice, all with a modern language and one compiler with good tooling. that seems to be a good enough value proposition for me.
I think the compiler not being open-source hurt with getting people to check it out. Today, people are accustomed to most of it regarding PL development being out in the open, and Mojo was an outlier here.
The "problem" it might solve for me, personally, is having a systems-level language that matches my personal style a bit better than Rust or other more modern systems level languages.
I know they're putting a lot of weight on GPU programming, which is fine and probably solves problems, but this is the part that would motivate me personally.
I was pretty disappointed that didn't work out, but it also is a direct precursor to Mojo which actually makes me more optimistic about Mojo's design choices.
Maybe I'm a party pooper, but given Qualcomm history, open sourcing just after acquisition feels like they don't care about it and they're going to let it die while they cut Modular in pieces and extract all the juice possible of their cloud offering.
nearly as bad as closed source compilers. Looking at you ADA (one of the imho nicest designed languages) suffering from an awfull network of closed source compilers.
I had been holding off on testing out mojo till it was open sourced, and started picking it up this week.
So far I've been enjoying the language (pythonic, comptime, tile support) and plan to spend time using it to work with gpus to learn more, the puzzles are also pretty cool.
I remember being really interested a few years ago when it was billed as a superset of Python. I know they pivoted away from that, but I might play with it now that the compiler is also open source.
This is nice, but the long time it took them to open source I think burnt a lot of the initial traction. I do like the idea & I'll see whether I can make use of it
If you like C++, you're going to like Mojo (if you're looking for alternatives). Some of the semantics and designs are inspired by C++, but wrapped in a Python-like skin. The way to think about Mojo, when compared to Rust, is that it was designed by expert C++ programmers as what they imagine a good C++ will look like. When I see Rust, I see designers who loved the functional programming paradigm and wanted to make a lot of the concept mainstream. This is why some of the semantics can seem awkward if you're coming from a procedural language
This isn't quite accurate; Mojo uses the same memory safety approach as Rust. It has some mutable aliasing, but only intra-function, so in practice programs will be pretty much Rust-shaped.
Their comment seems to be mostly focused on surface-level syntax from what I can tell (e.g. "wrapped in a Python-like skin"; "what they imagine a good C++ will look like"). Rust code probably does resemble functional languages to someone who uses C++ primarily, and Mojo doesn't resemble them as much. I don't find that to be a particularly enlightening insight, but I have to imagine that the syntax of Mojo is one of the first things that will catch people's attention, so it's not surprising to me that it's something that people will have a lot to say about.
My hot take is that what a good C++ will act like is basically just already Rust, mostly because the main problems with C++ can only be solved by taking away some of what makes it C++ in the first place. Some C++ developers will probably not be happy with a language that takes away the parts they still want to use, but others might just not like what Rust "looks like", so if dressing up the same Rust semantics in a new skin ends up getting the world more code written without the bad parts of C++, that's probably a good thing.
Yeah exactly. Rust could also be thought of as a much better C++ (semantically) but syntatically it is much more functional, while Mojo adopts (and even extends) similar memory safety ideas but dressed in a skin that is potentially much more approachable to people used to procedural programmng.
Can you explain this in more detail? I'm not really familiar with Mojo but I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s.
Rust's type system is very Haskell/ML inspired, specifically the first class support for algebraic types and pattern matching.
Modern C++ has come a long way with typed optionals and variants, but it's very tacked-on and lacks the safety guarantees and ergonomics of a language designed with this paradigm at a fundamental level.
I consider it basically an accident of history that the first non-research languages to support ADTs were functional. (The first language to have them was actually CLU, which was imperative, but it was a research language.) There isn't really anything about ADTs that makes them incompatible with imperative languages.
So what does this actually translate to in terms of Mojo? Rust has algebraic types and pattern matching, C++ has some specific use cases that are "tacked-on", to use your phrasing, so when the parent comment says that Mojo is what a good C++ would look like, they're saying...it doesn't have algebraic types, or that they're tacked on? It's not clear to me why that would be a selling point, so giving the parent commenter the benefit of the doubt, I don't think this sounds like what they were trying to say.
I don't know about Mojo. I was just answering "...I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s"
> expert C++ programmers as what they imagine a good C++ will look like
Mojo looks nice but with coding agents the landscape has shifted at least in my view. There is no need for DSLs and abstractions that reduce human cognitive load. So, I still struggle with the usecase for Mojo. If you want close to metal performance, code in something that touches metal (c,c++), and doesnt abstract you away from it or require unsafe primitives. As a programmer who cares for performance, you want the least separation between your tools and the hw in the sense that you can visualize precisely what the hw is doing with no abstractions to hide it.
How I wish people will stop spamming me with this garbage, or at least do some basic research first; C/C++ are not lower-level than Mojo, in fact, a core semantic of Mojo is that the programmer is as explicit as possible while defining what they want to accomplish rather than relying on compiler optimisations. You have facilities to interact with MLIR, LLVM, and Assembly intrinsics... in fact, most (if not all) of built-in Mojo types is exactly this, types wrapping low-level compiler MLIR intrisics.
It sounds like they were saying that they think you shouldn't have to use a language primitive like `unsafe` to be able to do the stuff that C/C++ does. (To be clear, I completely disagree with this viewpoint, because I don't think there's any evidence at all that agents won't struggle with the same fundamental problems in writing C/C++ that humans do, but I think it's what they're saying).
that you can visualize precisely what the hw is doing with no abstractions to hide it.
How can one hold the nuances of different architectures in their head, unless you stick to something like a console that doesn't evolve much for a half a decade or more? Don't you want at least some abstraction?
I'm pretty excited about mojo and look forward to it continuing into the phase of supporting systems programming. I have been using rust a lot lately for things I had used python for (that were not computation). I really like rust for static typing and functional programming patterns... but not for numerics. Hopefully mojo can become a serious staticly typed alternative to python.
When mojo 1.0 was announced, I looked into porting my current rust project (a very opinionated type-driven DICOM library/anonymizer that has a spec implemented in haskell) and it wasn't ready for that sort of work yet vs continuing with rust. Which is fine! The numerics side looks great. I'm glad they have reached 1.0 and open sourced.
If anybody wants to give a talk on this at the 2027 Carolina Code Conference, our call for speakers will be open from January to March. Love featuring languages like this.
Exciting. For hobby projects, I was looking into what should be my programming language. Open source was a criteria. Now I have choice between Rust and Mojo.
[ mojo explaining why they didn't create an embedded DSL]
> This is particularly problematic if you're trying to introduce fundamental new concepts because you can't change the grammar of Python or C++.
Yet, this is exactly the approach py2many is taking.
Keep it 99% python compatible. Deviate from the python grammar only for new features and where python made a decision incompatible with compiled language backends.
Slightly OT - but what's the process for training an LLM to author a new language like this proficiently?
I ask because I have my own language I maintain, and we're currently prompt-stuffing to get LLM's to author it - but I wonder what type of training set you'd need, and what base image one would use to fine-tune a model, and how effective it'd be?
If we program NPUs on Qualcomm-based chips using Mojo, the PC AI programming as a hobby would be getting much more interesting. I wish they don't limit this to the server chips.
Qualcomm is changing a lot. They are learning and adopting open source. I’ve seen this in other Silicon vendors, they used to deal only with big corps and would talk to you only if you promised to buy millions of parts. Now they are all moving to a model where they want an open ecosystem , attract developers, promote open source. It’s changing , it’s not going to be perfect, there will be false steps but the direction is good and we all benefit from this change.
As someone else said they are way ahead of NVIDIA in open source adoption so you should keep an eye on Qualcomm
I'm waiting for Phase 2[1]: especially "Algebraic data types & pattern matching". Current tagged union[2] use is pretty awkward/verbose and lacks exhaustiveness checking and typed error handling.
Extensible trait support seems like another big one if the ecosystem is going to significantly grow. Not having clearly defined traits in the language made larger projects composing many libraries in Julia difficult.
I'd rather have an established company give broad autonomy to PL developers at a loss (Go at Google, Swift at Apple) than risk eventual squeeze when VCs ask for their money back.
This was caused by the company running out of money, not by investor pressure, and it resulted in the language becoming more open rather than less. So it doesn't seem like an example at all.
Those seem quite different to me? Any kind of endeavor reliant on paid labor needs a source of funding and has to shut down if it can't find any; that's different from a situation where a business could have been sustainable by itself but has already taken investment from VCs for whom that's not good enough.
I would add quick note to this as title is misleading
* It was partially open-sourced before this. There were a lot of cool things they open sourced before like MAX for large scale LLM serving which was outperforming VLLM, Dynamo, etc on a lot of models. (super valuable GPU kernels). This is why Qualcomm acquire them imo.
* Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning.
Mojo is an awesome language, I've used it a lot as a Swift/Python lover. A couple things though
* If you want to understand Mojo spend 10x the time in MLIR before. It's just a fancy MLIR wrapper (good thing)
* They still haven't lived up to the python "superset" promise and that's the big thing preventing bigger adoption.
* https://www.spheron.network/blog/modular-max-mojo-gpu-cloud-...
When people talk about a language being open source they primarily mean the compiler. A closed compiler surrounded by a collection of open source things is an anti-pattern and trap to be avoided if you're interested in open tools, that's why open sourcing the Mojo compiler was so important to many people.
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right.
This I don't buy so much, as there seem to be a lot of core design decisions still up in the air: https://mojolang.org/docs/roadmap/
Chris literally was saying it from the very beginning (you can watch early interviews, obviously he was being asked about it), everything that happens with progressive opening is what he said he'll do and he gave rationale for it which is summarized by what parent comment says.
That doesn't seem to address what the parent comment says; they're arguing that the rationale for the progressive opening doesn't make sense, not that it didn't or wouldn't happen. If I say "I'm going to work on feature XYZ at work today because the sky is yellow and grass is purple", it would not make sense to defend my claim tomorrow by pointing out that I did work on feature XYZ.
[dead]
> He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning
“Too soon”, I could believe, but “at the beginning”? https://en.wikipedia.org/wiki/Swift_(programming_language):
“Development of Swift started in July 2010 by Chris Lattner, with the eventual collaboration of many other programmers at Apple”
and
“It was initially a proprietary language, but version 2.2 was made open-source software under the Apache License 2.0 on December 3, 2015”
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully ope source at
I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it. Yes, they might write code that depends on things that could change, but until last week it wasn't even 1.0 anyhow, so it's not like stuff might not break for people even if they didn't do that. Why was the language even being marketed at all pre-1.0 if "scaling" too quickly is a genuine concern?
The only explanation that makes any sense to me is that he (or his employer) just didn't really care about prioritizing making it open. That's totally fair, but being disingenuous about is not. It honestly just sounds like they didn't want to admit that they didn't care to prioritize being open source, and I think that has some potentially concerning implications for what to expect in terms of communication around the direction of the language and ecosystem in the future. The fact that it's being developed in the open now is good, but it doesn't seem like the actual decision making is, and that's a red flag.
>I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it.
Deep link to Chris Lattner interview where he says he learned lessons from Swift being rapidly released as open source meant that early design decisions that were suboptimal caused quick revisions. This caused a lot of complaints when later revisions to Swift caused breakages. This caused a lot of stress for Chris & the Swift team so he says he didn't want to repeat that for Mojo.
https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=2h22m05s
Sure, one can simple redo the exact same playbook with Mojo and iterate out in the open with early versions, and when people complain again about their code breaking, he can "just ignore it" but he didn't like that experience with Swift.
That doesn't clarify anything at all to me at least. If the goal was to avoid people depending on it before it was ready, why had I been hearing about it for so long before this? Something being marketed is not consistent with a concern to avoid having people rely on it and voice their opinions.
>to avoid people depending on it before it was ready, why had I been hearing about it for so long before this?
There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.
I think it's as simple as comparing the the community dynamics of 2 different timelines:
- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0
- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0
Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.
> Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.
Yes, and it's open source, and more to the point, it's because the developers do genuinely seem to want feedback and interaction with the community. That's ostensibly the entire point of having public release announcements, which Mojo has had before 1.0.
> The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.
That does not seem accurate in terms of what I'm asking about here; if I'm reading the history right, Swift was not open source until version 2.2.
It's still not clear to me how any what you have said addresses what I'm asking: how does being closed source solve the problem that's cited as the reason for it being closed for so long, and why wouldn't not marketing/releasing the language at all be the actual solution to those sort of problems?
Do you remember how long it took Python 2.7 to die after Python 3 came out? Years. It was horrible.
I don't understand the point you're trying to make. Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? I don't buy the claim that a pre-1.0 language only a few years old without widespread production use is comparable to one of the most widely used languages on the planet that had been around for close to two decades at the time of what you're describing.
Even if I did think that was a comparable precedent, that still doesn't address the more direct point I made about marketing the language at all if this was a concern. What does being closed source do to prevent people from running old versions of a compiler to avoid updating their code?
It prevents endless discussions on github, hurt egos when my precious PR is rejected by committers, and commentary on not being true open source because they are not welcoming source contribution, feature request, when they are trying stabilize compiler and so on.
Now none of these are guaranteed to happen when it is open source. But at least it is guaranteed to not happen when its not open source.
I don't understand that argument at all, unless you think that the only value of open source is in the potential for people to say nice things about your project. If you think there's inherent value in something being open source, you don't even need to have a Github repo (a tarball on your website with the source code is open source), and nothing anyone says would take away from that inherent value.
I'm firmly of the opinion that there's inherent value in being open source. I would honestly expect most developers to recognize that nowadays, but maybe I'm wrong. My concern is that someone who doesn't think this is the case is probably more likely to also not want to come right out and say it, because that would potentially prevent them from getting the value they're truly looking for from the stuff they do open source. The justifications that are being given here is that they seem to be heavily predicated on the value of open source being primarily from marketing rather than the very nature of code being open having value on its own, and I would be both surprised and disappointed if that's the opinion of the people in charge of Mojo. I'm sincerely hoping that there's something else going on here though, so I'm trying to give the benefit of the doubt and see if I'm missing something.
> Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time?
No, just saying it's happened before and it doesn't seem unreasonable to be wary of it.
Okay, but by that logic, if I can point to one instance of something suboptimal happening due to software being closed source, then it's reasonable to be wary of that too. I don't see how this is a plausible justification for keeping something closed source in the absence of taking into account the likelihood of something similar happening here, and for the reasons I laid out previously, I think it's borderline absurd to claim that was a real concern in the timeline that Mojo was closed.
People choose what to worry about. You can say it's unfair because they could've worried about a different set of things, but at the end of the day it's their choice.
I'm not saying you can't worry about this; I'm saying it does not seem to be a particular compelling reason for Mojo being closed source for so long, and I'm dubious that the rationale was due to anything like this.
> I'm not saying you can't worry about this
The relentless demand for justification is indistinguishable from a demand for others to stop doing things you don't like.
> but you can also just ignore it.
Apparently, this isn't as easy for some people who are deeply involved
E.g. GRRM avoids reading fan theories so that he doesn't change his writings to actively thwart them.
Has the title changed since you wrote this? It doesn't seem misleading to me. Misleading would be if it still wasn't fully open source. "It was partly open before" doesn't seem like it's worth a big warning. But that's just my impression FWIW
> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning.
Then he has learned the completely wrong lesson. Swift spent its first years floundering from breaking change to breaking change (from Swift 1.0 in 2014 to approximately Swift 5.0 in 2019) precisely because it wasn't open-sourced from the outset, instead being developed in the traditional airtight Apple fashion. In contrast, Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years pushing embarrassing major releases to an allegedly-1.0 language to fix problems that any actual user could have identified.
Well I think point was if they had gotten some fundamental things right from beginning they would not have to go through this 4.0 -> 5.0 breakage mess.
> Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years
One can keep pounding on this but endless discussions about pros/cons Rust Async model, library, framework bifurcation and shortcuts to deal with it does not seem like given an open design win that many in Rust community assume.
Going by the way Rust always seems to get inserted in any language related discussion no matter what, IMO it could a meme "What would Rust people do?" when deciding what should not be done.
I think a bigger issue than open source timing is the community governance necessary to shape a tool that serves the needs of a lot of stakeholders. Swift has lived under the shadow of Apple's (often secret) product priorities. The extremely poor backwards compatibility is why I invested in Rust instead, and I think Chris has expressed some misgivings about how the function builder stuff got added unilaterally. It appears what they're trying to do with Mojo is build a more coherent starting design with a closed process but the experience of client work, and then open having skipped over some of the teething issues. We'll see if it works.
> IMO it could a meme "What would Rust people do?" when deciding what should not be done
You betray your own ignorance here. Rust became massively successful despite having no corporate mandate or Big Tech progenitor, precisely because it listened to its users and empowered them to participate in the language design and development process. Trying to feebly gesture in the direction of Rust's async support doubly betrays your ignorance, both because Rust's async support is extremely good for its given design goals (not that it couldn't still be better), but also because you don't appear to realize that being developed in the open was what revealed the disastrous interactions between Rust's goals and the original pre-1.0 green thread runtime which characterized the language for a large proportion of its nascent development. Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.
> Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.
Well, one can always head back to their echo chamber to avoid hurt feelings, instead of telling others to not speak their mind.
"There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'" ~ Isaac Asimov, 1980
True. On positive side sometimes cult members do see wrong in their ways and apologize[1] . Sadly it is not always they will do that. Mostly they will spend time on attacking non-members.
1. https://blog.rust-lang.org/2023/05/29/RustConf/
> * Chris (also created swift)
He also created LLVM compiler
Also MLIR which is so prevalent in the ML compile stack everywhere.
https://mlir.llvm.org/
Also Clang and OpenCL.
Once they get an async story figured out I will be much more motivated to dive deeper into Mojo
I'm glad that it's open source now and they are supporting a lot more hardware. There are some interesting features that I hope the language design community pays attention to.
It's built on top of MLIR so you can make compiler optimizations in a library instead of the compiler. I believe Reactant.jl has been using MLIR for optimizing higher level abstractions in Julia. Imagine a Lisp with that capability.
Julia is extremely lispy in its semantics and design, it's mostly separated by syntax.
Mojo as MLIR++ is how I've thought about it as well.
Many users will find transpiling static python to mojo an interesting path.
Updating py2many --mojo to 1.0 to see what breaks.
Also looking forward to translating existing python adt module to mojo Variant in phase 2. I hope the mojo pattern matching proposal looks more like rust (expression) and not like python (statement).
Julia is a Lisp, just like Dylan or Lisp 2.
Many Lisps have that capability.
IMO saying julia is literally a lisp is just not worth the type of discussion it generates. I'd much prefer to say the important part: Julia learned a ton of very important lessons from the lisp family of languages, and has integrated a lot of them.
isnt its core literally femtolisp, ehich was written by one of the julia authors?
The parser and lowering passes were in femtolisp, and yes Jeff wrote femtolisp.
However, There's now a pure julia implementation of the parser that's on by default, and the julia implementation of lowering is also almost done and ready to replace the femtolisp one.
But honestly, these things aren't really what I mean when I say julia is lispy, those are just easter eggs. I more mean the language design and semantics.
Agreed.
Indeed Reactant looks like a young, fantastic piece of technology.
Does this project have any meaningful traction? Seemed like a cool idea, but I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...
I found that a big issue with it in practice is that the numbers are just not great, and the repo is very vibe-coded. When the numbers are great, it's sometimes cheating with the setup. For example some GEMMs only compute each 8th value and reach close to peak TFLOPs because of this, but it's a vibe-coded reward hack and the verifier does not check all numbers of the target.
Also, compilers have a lot to prove in 2026. Why not just hill-climb a Triton or Cuda kernel if you need perf?
> But I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...
At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem. Ocaml is barely mentioned in the news and rarely HNers here use that language, but it is Jane Street that maintains and uses it.
Judging by hype isn't a great way of evaluating a language. I am not going to check the entire Nvidia stack, from CUDA, to CUTLASS to cuDNN and even on PyTorch's side just to solve a runtime error that could have originated from either place when Mojo solves all of that.
Jane Street's use of OCamel gives them a comparative advantage in hiring. Many devs put a premium on the tools they use. Same story with Anduril/Mercury using Haskell. You can run a successful prop trading firm/weapons design shop/startup-banking(?) platform without these things. They differentiate you from your competitors by being cool, not by being the best technical solution. If anything they were otherwise unprove at scale and out of pure engineering consideration a gamble. Developers are consumers.
> At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem.
No need for snarky comments. These days tools/frameworks/languages/libraries/etc are popping all the time. Do you expect people to research every simple signal they catch in the wild?
How noob do you have to be to really feel this way lol
Edit: a language is by definition an ecosystem. Learning/using a language that no one else uses is completely pointless.
The interesting opportunity in 2026 for languages is that an LLM doesn't complain if there's an ecosystem or whether any other LLMs or people are using a language, they'll just write the code in whatever language you tell it to. Already authors are writing languages with features aimed at making it more more attractive for AI to write than people. Also great for working with research languages. I just used AI to write a Halide program and I wouldn't have bothered to do so before, for the reasons you state.
the main value proposition of mojo is being a (modern language for heterogenous compute). when writing code for the CPU, it is a nice language. it looks a bit like python, have arguably one of the best SIMD abstraction, a bit easier than Rust .. etc. but in my opinion, that does not justify deep investment in learning the language vs rust or zig. what sets Mojo apart is that it was designed from the grounds up to natively supprt other types of hardware (starting with GPUs). I have been in the mojo community from the beginning and almost every other project presentation starts with (I wanted to do XYZ in my domain and I could match or get close to Rust, C++ perf but then I wanted to see if I can make work on the GPU and it was much easier than expected and now I can solve my problem 10x faster). this is massive advantage that is underutilized outside of the AI/LLM and few other niches. running natively and being portable to NVIDIA/AMD/Apple GPUs means that you can transform any arbitrary workload you have in mind to the GPU and you won't need to worry about the separate CUDA/ROCm/Metal stacks, slightly different programming models, building headaches. you will be using the same language and the same compiler for CPUs and GPUs (all of them). or you won't need to coerce your problem in the shape of Triton to make it portable. If you have a problem in mind and don't like what you see? write your own GPU abstractions, containers, data moving and pipelining logic, work partitioning .. etc. this is extremely powerful and it sets Mojo apart from any other mainstream systems language that I have seen. that's why bigger mojo projects (even pre 1.0) like NuMojo and Marrow are all dabbling with GPU support even before the first stable release.
and now with support for TPUs and Trainium chips it is becoming even better. some problems will work better on some architectures and you will be able to split your problem to the best hardware doing some work on the CPU and some work on the accelerator(s) of choice, all with a modern language and one compiler with good tooling. that seems to be a good enough value proposition for me.
I think the compiler not being open-source hurt with getting people to check it out. Today, people are accustomed to most of it regarding PL development being out in the open, and Mojo was an outlier here.
The "problem" it might solve for me, personally, is having a systems-level language that matches my personal style a bit better than Rust or other more modern systems level languages.
I know they're putting a lot of weight on GPU programming, which is fine and probably solves problems, but this is the part that would motivate me personally.
I'm in the same category, but GPU support is definitely interesting too. The idea of offloading intensive processing to the GPU has its merits.
You can read a lot more about it here: https://mojolang.org/docs/vision/
[flagged]
Summarized here: https://www.phoronix.com/news/Modular-Mojo-Open-Source
This is by Chris Lattner, known for LLVM and Swift.
Also Swift for Tensorflow, lets not ignore that effort as well.
I was pretty disappointed that didn't work out, but it also is a direct precursor to Mojo which actually makes me more optimistic about Mojo's design choices.
Maybe I'm a party pooper, but given Qualcomm history, open sourcing just after acquisition feels like they don't care about it and they're going to let it die while they cut Modular in pieces and extract all the juice possible of their cloud offering.
Open sourcing was on Mojo's roadmap long before Qualcomm was in the picture.
close source language is a dumb concept anyway
nearly as bad as closed source compilers. Looking at you ADA (one of the imho nicest designed languages) suffering from an awfull network of closed source compilers.
I had been holding off on testing out mojo till it was open sourced, and started picking it up this week.
So far I've been enjoying the language (pythonic, comptime, tile support) and plan to spend time using it to work with gpus to learn more, the puzzles are also pretty cool.
This is how I imagined you seeing Qualcomm :D
https://youtu.be/eFbtGDGbdFU?si=VJ0XSiuNO9Z36DtD&t=30
The actual blog post on open-sourcing: https://www.modular.com/blog/mojo-open-source
I remember being really interested a few years ago when it was billed as a superset of Python. I know they pivoted away from that, but I might play with it now that the compiler is also open source.
I am much more interested in it now that it is not a subset of Python. That felt like something which would hold it back and seems like they agreed.
I think this submission should be merged with this much older one since they link to the same post: https://news.ycombinator.com/item?id=49348079
This is nice, but the long time it took them to open source I think burnt a lot of the initial traction. I do like the idea & I'll see whether I can make use of it
I'd bet 99% of people who will ever hear about or write in Mojo haven't heard about it for the first time yet.
If you like C++, you're going to like Mojo (if you're looking for alternatives). Some of the semantics and designs are inspired by C++, but wrapped in a Python-like skin. The way to think about Mojo, when compared to Rust, is that it was designed by expert C++ programmers as what they imagine a good C++ will look like. When I see Rust, I see designers who loved the functional programming paradigm and wanted to make a lot of the concept mainstream. This is why some of the semantics can seem awkward if you're coming from a procedural language
This isn't quite accurate; Mojo uses the same memory safety approach as Rust. It has some mutable aliasing, but only intra-function, so in practice programs will be pretty much Rust-shaped.
Their comment seems to be mostly focused on surface-level syntax from what I can tell (e.g. "wrapped in a Python-like skin"; "what they imagine a good C++ will look like"). Rust code probably does resemble functional languages to someone who uses C++ primarily, and Mojo doesn't resemble them as much. I don't find that to be a particularly enlightening insight, but I have to imagine that the syntax of Mojo is one of the first things that will catch people's attention, so it's not surprising to me that it's something that people will have a lot to say about.
My hot take is that what a good C++ will act like is basically just already Rust, mostly because the main problems with C++ can only be solved by taking away some of what makes it C++ in the first place. Some C++ developers will probably not be happy with a language that takes away the parts they still want to use, but others might just not like what Rust "looks like", so if dressing up the same Rust semantics in a new skin ends up getting the world more code written without the bad parts of C++, that's probably a good thing.
Yeah exactly. Rust could also be thought of as a much better C++ (semantically) but syntatically it is much more functional, while Mojo adopts (and even extends) similar memory safety ideas but dressed in a skin that is potentially much more approachable to people used to procedural programmng.
Can you explain this in more detail? I'm not really familiar with Mojo but I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s.
Rust's type system is very Haskell/ML inspired, specifically the first class support for algebraic types and pattern matching.
Modern C++ has come a long way with typed optionals and variants, but it's very tacked-on and lacks the safety guarantees and ergonomics of a language designed with this paradigm at a fundamental level.
I consider it basically an accident of history that the first non-research languages to support ADTs were functional. (The first language to have them was actually CLU, which was imperative, but it was a research language.) There isn't really anything about ADTs that makes them incompatible with imperative languages.
So what does this actually translate to in terms of Mojo? Rust has algebraic types and pattern matching, C++ has some specific use cases that are "tacked-on", to use your phrasing, so when the parent comment says that Mojo is what a good C++ would look like, they're saying...it doesn't have algebraic types, or that they're tacked on? It's not clear to me why that would be a selling point, so giving the parent commenter the benefit of the doubt, I don't think this sounds like what they were trying to say.
I don't know about Mojo. I was just answering "...I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s"
> expert C++ programmers as what they imagine a good C++ will look like
Mojo looks nice but with coding agents the landscape has shifted at least in my view. There is no need for DSLs and abstractions that reduce human cognitive load. So, I still struggle with the usecase for Mojo. If you want close to metal performance, code in something that touches metal (c,c++), and doesnt abstract you away from it or require unsafe primitives. As a programmer who cares for performance, you want the least separation between your tools and the hw in the sense that you can visualize precisely what the hw is doing with no abstractions to hide it.
How I wish people will stop spamming me with this garbage, or at least do some basic research first; C/C++ are not lower-level than Mojo, in fact, a core semantic of Mojo is that the programmer is as explicit as possible while defining what they want to accomplish rather than relying on compiler optimisations. You have facilities to interact with MLIR, LLVM, and Assembly intrinsics... in fact, most (if not all) of built-in Mojo types is exactly this, types wrapping low-level compiler MLIR intrisics.
I'm confused, C and C++ do require unsafe primitives? I think I must be misunderstanding your comment somehow.
It sounds like they were saying that they think you shouldn't have to use a language primitive like `unsafe` to be able to do the stuff that C/C++ does. (To be clear, I completely disagree with this viewpoint, because I don't think there's any evidence at all that agents won't struggle with the same fundamental problems in writing C/C++ that humans do, but I think it's what they're saying).
that you can visualize precisely what the hw is doing with no abstractions to hide it.
How can one hold the nuances of different architectures in their head, unless you stick to something like a console that doesn't evolve much for a half a decade or more? Don't you want at least some abstraction?
> it was designed by expert C++ programmers as what they imagine a good C++ will look like
This also describes Rust. The mistake here is thinking that being an expert C++ programmer means that you can't also be an expert OCaml programmer.
I'm pretty excited about mojo and look forward to it continuing into the phase of supporting systems programming. I have been using rust a lot lately for things I had used python for (that were not computation). I really like rust for static typing and functional programming patterns... but not for numerics. Hopefully mojo can become a serious staticly typed alternative to python.
When mojo 1.0 was announced, I looked into porting my current rust project (a very opinionated type-driven DICOM library/anonymizer that has a spec implemented in haskell) and it wasn't ready for that sort of work yet vs continuing with rust. Which is fine! The numerics side looks great. I'm glad they have reached 1.0 and open sourced.
They made a big mistake by not open sourcing before, doubt they'll ever gain traction now.
Their goal was to get bought. Now it doesn’t matter whether they get traction, they already made a billion dollars.
Really happy to see this. Kudos to Qualcomm for releasing it under a liberal Apache 2.0 license.
Strategically speaking, I think this only makes sense as an anti-NVIDIA play.
If anybody wants to give a talk on this at the 2027 Carolina Code Conference, our call for speakers will be open from January to March. Love featuring languages like this.
Exciting. For hobby projects, I was looking into what should be my programming language. Open source was a criteria. Now I have choice between Rust and Mojo.
What sort of projects are you looking at doing?
[ mojo explaining why they didn't create an embedded DSL]
> This is particularly problematic if you're trying to introduce fundamental new concepts because you can't change the grammar of Python or C++.
Yet, this is exactly the approach py2many is taking.
Keep it 99% python compatible. Deviate from the python grammar only for new features and where python made a decision incompatible with compiled language backends.
Slightly OT - but what's the process for training an LLM to author a new language like this proficiently?
I ask because I have my own language I maintain, and we're currently prompt-stuffing to get LLM's to author it - but I wonder what type of training set you'd need, and what base image one would use to fine-tune a model, and how effective it'd be?
Why Qualcomm Open-Sourced Mojo After Its $3.9B Acquisition https://www.reddit.com/r/LLM/comments/1vsp7vk/why_qualcomm_o...
Finally! I have been waiting for this for years. Mojo has great potential. I would use it for everything if it was for me
Video stream of the ModCon conference yesterday: https://www.youtube.com/watch?v=Yvb_G2Dr0mY
If we program NPUs on Qualcomm-based chips using Mojo, the PC AI programming as a hobby would be getting much more interesting. I wish they don't limit this to the server chips.
[dupe] Discussion on blog post: https://news.ycombinator.com/item?id=49348079
Qualcomm is a notoriously closed source company.
Don't reward them with your support just because they are forced to open source something.
Notoriously is a stretch if almost all of Linux ARM commits these days come from them
Qualcomm is changing a lot. They are learning and adopting open source. I’ve seen this in other Silicon vendors, they used to deal only with big corps and would talk to you only if you promised to buy millions of parts. Now they are all moving to a model where they want an open ecosystem , attract developers, promote open source. It’s changing , it’s not going to be perfect, there will be false steps but the direction is good and we all benefit from this change. As someone else said they are way ahead of NVIDIA in open source adoption so you should keep an eye on Qualcomm
They are no better than Nvidia.
I do not see your point.
NVIDIA is way worse and QCOM are improving
I agree. Saying "Qualcomm is a notoriously closed source company." isn't really a point in the semiconductor space. They all are.
At least with Mojo that is open sourced and Nvidia's nvcc is still closed.
Did you mean “worse”?
I guess they want to go after CUDA for their GPU lines. Now give us the hardware.
If it's 2x faster than rustc, I'll switch.
I'm waiting for Phase 2[1]: especially "Algebraic data types & pattern matching". Current tagged union[2] use is pretty awkward/verbose and lacks exhaustiveness checking and typed error handling.
[1] https://mojolang.org/docs/roadmap/#phase-2
[2] https://mojolang.org/docs/std/utils/variant/Variant/
Extensible trait support seems like another big one if the ecosystem is going to significantly grow. Not having clearly defined traits in the language made larger projects composing many libraries in Julia difficult.
Mojo (owned by Qualcomm ®) is now open source™ try it! Just remember we own it
I'd rather have an established company give broad autonomy to PL developers at a loss (Go at Google, Swift at Apple) than risk eventual squeeze when VCs ask for their money back.
Has that ever happened to a programming language?
Darklang is probably the closest thing that comes to mind - https://blog.darklang.com/goodbye-dark-inc-welcome-darklang-...
This was caused by the company running out of money, not by investor pressure, and it resulted in the language becoming more open rather than less. So it doesn't seem like an example at all.
>company running out of money, not by investor pressure
Potato potato
Those seem quite different to me? Any kind of endeavor reliant on paid labor needs a source of funding and has to shut down if it can't find any; that's different from a situation where a business could have been sustainable by itself but has already taken investment from VCs for whom that's not good enough.