> following the standards of how mature languages (e.g. C++) evolve over time
This gave me a chuckle. When I think of languages evolving their standards, I do think of C++. But not, you know, in a good way.
Mojo 1.0
71–80 of 233 posts
Re: Mojo 1.0
#72Don't see the value of using a language with a closed source compiler... Much better options out there. Python already has libraries like Pydantic that offload performance to functions written in Rust under the hood.
The value has already been materialized. They were acquired by Qualcomm for $3.9 billion.
Wow, so Lattner became a billionaire. Pays to be in compilers.
Re: Mojo 1.0
#73Re: Mojo 1.0
#74Mojo may be interesting to me, but they should really split it from Max, which is some closed stuff I'm not interested in. They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
They kind of did. It has a separate website now [1] . All the docs, announcements, roadmap, some comparisons as you asked are there. So they do seem to be working towards separation.
Re: Mojo 1.0
#75Apparently they'll be open sourcing it on August 18th, one week from now.
Re: Mojo 1.0
#76Is Mojo being a superset of Python still part of its projected feature set?
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
Re: Mojo 1.0
#77Nothing but respect for Chris, and I understand why founders take these deals. But an acquihire usually means the product is the part that gets left behind, and that's the part I cared about.
Re: Mojo 1.0
#78Is Mojo being a superset of Python still part of its projected feature set? I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from. On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it do…
They moved the goalposts. I think the landscape has changed since their initial Python superset pitch.
It seems like a deliberate pivot towards creating an AI-era language which make GPU programming as easy as writing Python.
Re: Mojo 1.0
#79> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026. Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
It's probably very messy and not a great baseline for outside contributors to start create PRs. That's the favorable interpretation, atleast.
Ladybird is Open Source and doesn't accept outside contributions any more same with sqlite and many other projects. Lots of Google's oss projects also are not very open to contribution.
At this point I find it deeply troubling that it isn't open source. I respect Chris I know folks who have worked with him and but at the end of the day I feel too weird about this entire closed source programming language thing.
If we complain to Nvidia about there weird closed source limitations, I think Mojo is just as bad. You don't even know what your compiler might be doing, and if it does something wrong you can't fix it, you now have to file a bug and wait until the gods from above come to your rescue.
I have had similar issues with drivers, I have faced soo many driver bugs in my work and the answer is always write more code that works around it somehow, this warp level is bad, this feature doesn't work with these values, etc. etc. Why can't I fix them, I have often on Linux just pinged the Mesa team about driver bugs with a rough draft of a patch and gotten it fixed, I can even patch and run it myself when I am in a hurry.
I feel like atleast making stuff, source available like Unreal should be the baseline for any "core" software where a bug could possibly be a major blocking issue for a developer. Windows and Mac are very bad with this.
Mac's CoreML has had soo many bugs over the last couple years I have had to email someone I know at the company to get them fixed or try to get into contact with someone.
Intel's drivers have had bugs too but I have had more contacts there which is a wash. AMD well it's AMD...
Either way closed software sucks I don't want to use fully closed stuff unless I don't have a choice people can make what they want of it. I don't really care.
I care much less about just foss.
Re: Mojo 1.0
#80Earlier quoted context omitted.
So, without significant indentation?
Oh nooooo, they fucked it up too. Why would someone make a language that’s whitespace sensitive? It’s confounding.
Why would someone make a language where the programmer and the interpreter have two different ways of figuring out where blocks start and end?