[HN Gopher] Python can run Mojo now
___________________________________________________________________
Python can run Mojo now
Author : cantdutchthis
Score : 301 points
Date : 2025-06-20 19:46 UTC (3 days ago)
(HTM) web link (koaning.io)
(TXT) w3m dump (koaning.io)
| mindwok wrote:
| I am really rooting for Mojo. I love what the language is trying
| to do, and making it easier to run SOTA AI workloads on hardware
| that isn't Nvidia + CUDA will open up all kinds of possibilities.
|
| I'm just nervous how much VC funding they've raised and what kind
| of impacts that could have on their business model as they
| mature.
| mkaic wrote:
| If they can manage to make good on their plans to open-source
| it, I'll breathe a tentative sigh of relief. I'm also rooting
| for them, but until they're open-source, I'm not willing to
| invest my own time into their ecosystem.
| jillesvangurp wrote:
| They already released their code under the Apache 2.0
| license. Not everything in their stack is open source but the
| core things appear to be open source.
| ayhanfuat wrote:
| Their compiler is not open source. They only released
| stdlib code.
| almostgotcaught wrote:
| > Functions taking more than 3 arguments. Currently
| PyTypeBuilder.add_function() and related function bindings only
| support Mojo functions that take up to 3 PythonObject arguments:
| fn(PythonObject, PythonObject, PythonObject).
|
| Lol wut. For the life of me I cannot fathom what design decision
| in their cconv/ABI leads to this.
| rybosome wrote:
| I was wondering if it is function overloads of the same name,
| defining it non-variadically:
|
| add_function(PythonObject)
|
| add_function(PythonObject, PythonObject)
|
| add_function(PythonObject, PythonObject, PythonObject)
|
| There was a similar pattern in the Guava library years ago,
| where ImmutableList.of(...) would only support up to 20
| arguments because there were 20 different instances of the
| method for each possible argument count.
| bmacho wrote:
| Probably not, since they would surely up it at least 15
| arguments, instead of 3. But what else, then?
| js2 wrote:
| For anyone not up to speed on Mojo: _Mojo is a pythonic language
| for blazing-fast CPU+GPU execution without CUDA_ :
|
| https://news.ycombinator.com/item?id=35790367
| GeekyBear wrote:
| Chris Lattner (the tech lead behind Mojo, LLVM, Clang, Swift and
| MLIR) appeared on a podcast a bit over a week ago and discussed
| the state of Mojo and where it is going.
|
| He also discussed open sourcing Mojo and where the company
| expects to make its money.
|
| https://www.youtube.com/watch?v=04_gN-C9IAo
| mattclarkdotnet wrote:
| That video is restricted, do you have a public link?
| GeekyBear wrote:
| Sorry, but I'm not having any issue with that link.
|
| Here is a link to the episode listing for that podcast, which
| might help.
|
| https://www.youtube.com/@LatentSpacePod
| abybaddi009 wrote:
| Doesn't seem to be restricted. Do you mean region locked?
| slyall wrote:
| Video isn't region locked according to the tool I normally
| use
|
| https://polsy.org.uk/stuff/ytrestrict.cgi
| duttish wrote:
| Just worked fine for me.
|
| I'm logged into youtube, if you're not something with that
| perhaps?
| loudmax wrote:
| It's the Latent Space podcast, published June 13. It's a
| pretty decent podcast for keeping on top of AI stuff. Swyx,
| one of the co-hosts, is active here on HN.
| ModernMech wrote:
| He popped up on r/programminglanguages last week to say a bit
| about that as well:
| https://www.reddit.com/r/ProgrammingLanguages/comments/1lfz9...
| Staross wrote:
| Funny how the already weak case for not working on Julia
| instead of creating a new language is becoming even more
| flimsy :
|
| FAQ:
|
| > Why not make Julia better? > We think Julia is a great
| language and it has a wonderful community, but Mojo is
| completely different. While Julia and Mojo might share some
| goals and look similar as an easy-to-use and high-performance
| alternative to Python, we're taking a completely different
| approach to building Mojo. Notably, Mojo is Python-first and
| doesn't require existing Python developers to learn a new
| syntax.
|
| https://docs.modular.com/mojo/faq/#why-not-make-julia-better
|
| Now :
|
| >We oversold Mojo as a Python superset too early and realized
| that we should focus on what Mojo can do for people TODAY,
| not what it will grow into. As such, we currently explain
| Mojo as a language that's great for making stuff go fast on
| CPUs and GPUs.
| dragonwriter wrote:
| The share of projects that start out "we're going to do X,
| and conpletely support using the syntax and semantics of
| existing language Y, but add more on top" that end up
| "we're going to do X, in a language vaguely reminiscent of
| Y" is very hard to distinguish from 100%.
| amval wrote:
| Even funnier: https://github.com/tensorflow/swift/blob/main
| /docs/WhySwiftF...
|
| > Julia: Julia is another great language with an open and
| active community. They are currently investing in machine
| learning techniques, and even have good interoperability
| with Python APIs.
| Staross wrote:
| Yeah that was a missed opportunity fore sure, joining
| forces 8 years ago would probably had yield better
| results that the current situation.
| ddaud wrote:
| I think the real reason is that Chris Lattner doesn't want
| to work on Julia. He's likely very (and justifiably so)
| opinionated about these topics, and probably wants a
| certain degree of creative authority over his projects.
| serial_dev wrote:
| Why deal with others when you are big enough of a name to
| launch your own and make all the decisions yourself?
| tgma wrote:
| I hope this ends up superseding Cython
| williamstein wrote:
| Same, and I literally started Cython. :-)
| fnands wrote:
| What's your current take on Cython vs other options? E.g.
| DSLs and I guess PyO3?
| fnands wrote:
| I think that's one of the real strong use cases I see coming
| up.
|
| If they can make calling Mojo from Python smooth it would be a
| great replacement for Cython. You also then get easy access to
| your GPU etc.
| Tiberium wrote:
| > as I'm definitely in the market for a simple compiled language
| that can offer Python some really fast functions So, Nim?
| https://github.com/yglukhov/nimpy
| mindwok wrote:
| The real point of Mojo is not the language, it's the deep roots
| into MLIR which is an attempt to do what LLVM did for
| compilers, and do it on GPUs / ML hardware. Chris Lattner is
| leading the project and he created LLVM and MLIR.
| benrutter wrote:
| I've never been thats sold on Mojo, I think I'm unfairly biased
| away from it because I find new languages interesting, and its
| big sell is changing as little as possible from an existing
| language.
|
| That said, importing into Python this easily is a pretty big
| deal. I can see a lot of teams who just want to get unblocked by
| some performance thing, finding this insanely helpful!
| atomicapple wrote:
| > its big sell is changing as little as possible from an
| existing language.
|
| This is not really true. Even though Mojo is adopting Python's
| syntax, it is a drastically different language under the hood.
| Mojo is innovating in many directions (eg: mlir integration,
| ownership model, comptime, etc). The creators didn't feel the
| need to innovate on syntax in addition to all that.
| benrutter wrote:
| You're right- I probably should have said something like
| "part of its sell" or "one of its selling points" or
| something.
|
| I didn't mean to undermine the ambitious goals the project
| has. I still wish it was a little bolder on syntax though,
| Python is a large and complex language as is, so a superset
| of Python is inherently going to be a very complicated
| language.
| anon-3988 wrote:
| I am not that intrigued that Python that can call some pre-
| compiled functions, this is already possible with any language
| that produces a dynamic library.
|
| The space that I am interested in is execution time compiled
| programs. A usecase of this is to generate a perfect hash data
| structure. Say you have a config file that lists out the keywords
| that you want to find, and then dynamically generate the perfect
| hash data structure compiled as if those keywords are compile
| time values (because they are).
|
| Or, if the number of keywords is too small, fallback to a linear
| search method. All done in compile time without the cost of
| dynamic dispatch.
|
| Of course, I am talking about numba. But I think it is cursed by
| the fact that the host language is Python. Imagine if Python is
| stronger typed, it would open up a whole new scale of
| optimization.
| devjab wrote:
| > I am not that intrigued that Python that can call some pre-
| compiled functions, this is already possible with any language
| that produces a dynamic library.
|
| > The space that I am interested in is execution time compiled
| programs. A usecase of this is to generate a perfect hash data
| structure. Say you have a config file that lists out the
| keywords that you want to find, and then dynamically generate
| the perfect hash data structure compiled as if those keywords
| are compile time values (because they are).
|
| I'm not sure I understand you correctly, but these two seem
| connected. If I were to do what you want to do here in Python
| I'd create a zig build-lib and use it with ctypes.
| anon-3988 wrote:
| Can Zig recompile itself if I change a config in production?
| I am talking about this
|
| ``` python program.py --config <change this> ```
|
| It is basically a recompilation of the whole program at every
| execution taking into account the config/machine combination.
|
| So if the config contains no keyword for lookup, then the
| program should be able to be compiled into a noop. Or if the
| config contains keyword that permits a simple perfect hash
| algorithm, then it should recompile itself to use that
| mechanism.
|
| I dont think any of the typical systems programming allows
| this.
| pjmlp wrote:
| I would rather image CPython being like Common Lisp, Scheme,
| Raket, Smalltalk, Self compilation model.
|
| Sadly the contenders on the corner get largely ignored, so we
| need to contend with special cased JIT DSLs, or writing native
| extensions, as in many cases CPython is only implementation
| that is available.
| dukebw wrote:
| Doesn't Mojo already support this in its parameter system?
| https://docs.modular.com/mojo/manual/parameters/
|
| Jitting like you mentioned is supported by the MAX graph API:
| https://docs.modular.com/max/tutorials/build-custom-ops. It
| could have a nicer syntax though to be more like Numba, I think
| you have an interesting idea there.
| boguscoder wrote:
| Are labels on first output misplaced or mojo was actually slower?
|
| ''' 3628800 Time taken: 3.0279159545898438e-05 seconds for mojo
|
| 3628800 Time taken: 5.0067901611328125e-06 seconds for python '''
| que-encrypt wrote:
| My guess is that the slight overhead of interacting with mojo
| led to this speed discrepancy, and if a higher factorial (that
| was within the overflow limits etc) was run, this overhead
| would become negligible (as seen by the second example). Also
| similar to jax code being slower than numpy code for small
| operations, but being much faster for larger ones on cpus etc.
| mkl wrote:
| The Python function is implemented in C and uses a faster
| algorithm [1], and this particular factorial is so small they
| put it in a lookup table [2]. It is a strange and very unequal
| choice for a demo.
|
| [1]
| https://github.com/python/cpython/blob/0d9d48959e050b66cb37a...
|
| [2]
| https://github.com/python/cpython/blob/0d9d48959e050b66cb37a...
| gjvc wrote:
| i wish python were as fast as perl for equivalent string-based
| workloads
| ValtteriL wrote:
| Was lowkey hoping this was about Mojolicious, the Perl web
| framework
| dkechag wrote:
| Yeah, I also get confused with references. I was annoyed from
| the start, when "Mojo" was announced as a Python family
| language. Mojolicious uses the "Mojo" namespace and is referred
| to as that quite often. I know Perl is not as popular as it
| used to be, but Mojolicious is probably the most popular
| framework of a language that is roughly in the same "space" as
| Python, so that naming choice was very ignorant IMHO.
| amval wrote:
| For a language that announced itself (and raised a lot of money
| on the premise of) claiming to be "a Python superset", this does
| not sound like a huge achievement.
|
| In all fairness, their website now reads: "Mojo is a pythonic
| language for blazing-fast CPU+GPU execution without CUDA.
| Optionally use it with MAX for insanely fast AI inference."
|
| So I suppose now is just a compiled language with superficially
| similar syntax and completely different semantics to Python?
| boxed wrote:
| I believe they're still working towards making the syntax and
| semantics more python-like.
| dragonwriter wrote:
| The real unique selling point of Mojo is "CPU+GPU execution
| without CUDA", specifically, you write code that looks like
| code without worrying about distinctions like kernels and
| device functions and different ways of writing code that runs
| on GPU vs. code that runs on CPU, and mojo compiles it to those
| things.
| Certhas wrote:
| I think it was pretty clear immediately that running python
| code was a far away goal. There was a lot more talk about
| lifetimes and ownership semantics than details about Python
| interop. Mojo is more like: Can we take the learnings of Swift
| and Rust and solve the usability and compile time issues, while
| building on MLIR to target arbitrary architectures efficiently
| (and call it a Python superset to raise VC money).
|
| That said, the upside is huge. If they can get to a point where
| Python programmers that need to add speed learn Mojo, because
| it feels more familiar and interops more easily, rather than
| C/CPP that would be huge. And it's a much lower bar than
| superset of python.
| amval wrote:
| It marketed itself explicitly as a "Python superset", which
| could allow Python programmers to avoid learning a second
| language and write performant code.
|
| I'd argue that I am not sure what kind of Python programmer
| is capable of learning things like comptime, borrow checking,
| generics but would struggle with different looking syntax. So
| to me this seemed like a deliberate misrepresentation of the
| actual challenges to generate hype and marketing.
|
| Which fair enough, I suppose this is how things work. But it
| should be _fair_ to point out the obvious too.
| fnands wrote:
| They've backed off a little from the Python superset claims
| and leaned more into "Python family".
|
| > I'd argue that I am not sure what kind of Python
| programmer is capable of learning things like comptime,
| borrow checking
|
| One who previously wrote compiled languages ;-). It's not
| like you forget everything you know once you touch Python.
| oxidi wrote:
| I think the point was that Python syntax is simpler than
| e.g. borrow checking.
|
| Although Python has some seriously PERLesque YOLO
| moments, like "#"*3 == "###". This is admittedly useful,
| but funny nonetheless.
| mkl wrote:
| * does different things depending on the types of the
| operands, which is Python's strong typing at work, not
| Perlesque weak typing. Repeating a string is a useful
| thing to be able to do, and this is a natural choice of
| syntax for it. The same thing works for lists: [1]*3 ==
| [1, 1, 1].
| oxidi wrote:
| I was referring to the "creative syntax" and it wasn't
| meant to be an attack on Python.
|
| We cannot deny that Python has some interesting
| solutions, such as the std lib namedtuple implementation.
| It's basically a code template & exec().
|
| I don't think these are necessarily bad, but they're
| definitely funny.
| pixelpoet wrote:
| I suppose if you accept the innocent-looking
| "#"+"#"=="##" then your example kind of algebraically
| follows. Next it's time to define what exp("#") is :)
| amval wrote:
| The second part of the sentence is very important ;)
|
| "... but would struggle with different looking syntax"
| Certhas wrote:
| Absolutely. The public sales pitch did not match the
| reality. This is what I meant with the "Claim to be Python
| to get VC money" point.
|
| To first order, today every programmer starts out as a
| Python programmer. Python is _the_ teaching language now.
| The jump from Python to C/Cpp is pretty drastic, I don't
| think that it's absurd that learning Mojo concepts step by
| step coming from Python is simpler than learning C. Not
| syntactically but conceptually.
| ForHackernews wrote:
| I've tried learning C a couple times and given up because
| the curve is too steep to be worth the climb. It's not
| even the language itself, it's the inherited weight of
| half a century's worth of cruft. I can't spend weeks
| fighting with compiler nonsense, header files and
| #include. Screw it, I'll just use Go instead.
|
| I'm learning Rust and Zig in the hope that I'll never
| have to write a line of C in my career.
| blks wrote:
| Geez, what a comment. C is much much more simpler than
| Rust. You're not supposed to be spending weeks fighting
| includes or compiler errors, that means you're have some
| very basic misconceptions about the language.
|
| Just read K&R "The C programming language" book. It's
| fairly small and it's a very good introduction to C.
| pjmlp wrote:
| Agreed, I do bash C a lot, and it has plenty of issues,
| but hardly a monster that a mythological hero has to
| face.
|
| And as tip for pointers, regardless of the programming
| language, pen and paper, drawing boxes and arrows, are
| great learning tools.
| codethief wrote:
| I do sympathize with the parent: The language itself
| might not be that difficult but you also have to factor
| in the entire ecosystem. What's the modern way to a build
| a GUI application in C? What's the recommended way to
| build a CLI, short of writing your own arg parser? How do
| you handle Unicode? How do you manage dependencies, short
| of vendoring them? Etc.
| ForHackernews wrote:
| Even more than that: "How do you do a string?" has like
| 100 answers in C depending on what libraries are
| available, what your deploy target is...
| tialaramex wrote:
| Errors too. When, inevitably, you make mistakes the C
| might just compile despite being nonsense, or you might
| get incomprehensible diagnostics. Rust went out of its
| way to deliver great results here.
| blks wrote:
| I am not arguing about how good or easy it is to use C in
| production, I'm merely stating that parent complaints
| about weeks of insolvable errors and issues with includes
| screams that he needs to read some good resource like
| book, because he is definitely misunderstanding something
| important.
| m11a wrote:
| C syntactically is straight forward, but conceptually may
| be harder than Rust. You're exposed to the bare computer
| (memory management, etc) far more than with a GC language
| or even Rust arguably, at least for simple programs.
|
| Towards deployment is even harder. You can very easily
| end up writing exploitable, unsafe code in C.
|
| If I were a Python programmer with little knowledge about
| how a computer works, I'd much prefer Go or Rust (in that
| order) to C.
| blks wrote:
| Rust memory model is very complicated. C memory model is
| very straightforward.
| DasIch wrote:
| C before C11 has no memory model. Rust doesn't have one
| but effectively it inherits the C++/C memory model, so
| there is actually no difference.
| tialaramex wrote:
| The model you're referring to, a Memory Ordering Model,
| is literally the same model as Rust's. The "exception" is
| an ordering nobody knows how to implement which Rust just
| doesn't pretend to offer - a distinction which makes no
| difference.
| ynik wrote:
| That applies only if you take "memory model" to mean
| modeling the effects of concurrent accesses in
| multithreaded programs.
|
| But the term could also be used more generally to include
| stuff like pointer provenance, Rust's "stacked borrows"
| etc. In that case, Rust is more complicated than C-as-
| specified. But C-in-reality is much more complicated,
| e.g. see https://www.open-
| std.org/jtc1/sc22/wg14/www/docs/n2263.htm
| ModernMech wrote:
| This is true, but when you get something wrong related to
| the memory model in C, it just says "segfault". Whereas
| in Rust it will give you a whole explanation for what
| went wrong and helpful suggestions on how to fix it. Or
| at the very least it will tell you _where_ the problem
| is. This is the difference between "simple" and "easy".
| goodpoint wrote:
| Writing hello world in C is easy. Writing complex
| software without memory issues and vulnerability is
| pretty hard.
| Certhas wrote:
| THe thing is, if one is an expert it is incredibly
| difficult to understand the beginner perspective. Here is
| one attempt:
|
| C is simpler than Rust, but C is also _much_ simpler than
| Python. If I solve a problem in Python I have a good
| standard library of data types, and I use concepts like
| classes, iterators, generators, closures, etc...
| constantly. So if I move to Rust, I have access to the
| similar high-level tools, I just have to learn a few
| additional concepts for ressource management.
|
| In comaprison, C looks a lot more alien from that
| perspective. Even starting with including library code
| from elsewhere.
| pjmlp wrote:
| Maybe young generations have some issue learning polyglot
| programming, I guess.
|
| While I agree using Mojo is much preferable to writing C
| or C++ native extensions, back on my day people learned
| to program in K&R C or C++ ARM in high school, kids
| around 12 years old, hardly something pretty drastic.
| ForHackernews wrote:
| No wonder there's so much terrible unsafe C floating
| around...
| pjmlp wrote:
| Many famous Speccy and C64 titles, written in Assembly,
| were written by bedroom coders between the ages of 14 and
| 16 years old, getting some pocket money writing them on
| the UK scene.
|
| Get hold of Retro Gamer magazine for some of their
| stories.
| fwip wrote:
| I think one of the "Python superset" promises was that any
| particular dev wouldn't need to learn all of that at once.
| There could exist a ramp between Python and "fast python"
| that is more gradual than the old ways of dropping into C,
| and more seamless than importing and learning the various
| numpy/numba/polars libraries.
| johnofthesea wrote:
| > and call it a Python superset to raise VC money
|
| What else was proclaimed just to raise VC money?
| dismalaf wrote:
| It was never going to have Python semantics _and_ be fast.
| Python isn 't slow because of a lack of effort or money, it's
| slow because of all the things happening in the interpreter.
| saghm wrote:
| > For a language that announced itself (and raised a lot of
| money on the premise of) claiming to be "a Python superset",
| this does not sound like a huge achievement
|
| I feel like that depends quite a lot on what exactly is in the
| non-subset part of the language. Being able to use a library
| from the superset in the subset requires being able to
| translate the features into something that can run in the
| subset, so if the superset is doing a lot of interesting things
| at runtime, that isn't necessarily going to be trivial.
|
| (I have no idea exactly what features Mojo provides beyond
| what's already in Python, so maybe it's not much of an
| achievement in this case, but my point is that this has less to
| do with just being a superset but about what exactly the extra
| stuff is, so I'm not sure I buy the argument that the marketing
| you mention of enough to conclude that this isn't much of an
| achievement.)
| melodyogonna wrote:
| I've written this somewhere else before, Modular did not raise
| $130m to build a programming language, nobody does that. They
| raised that much money to revolutionize AI infrastructure, of
| which a language is just a subset. You should definitely check
| some of the things they've put together, they're amazing
| Imustaskforhelp wrote:
| Yes. They are revolutionizing AI infrastructure but I guess a
| lot of world is just babbling about AI, but not every
| developer needs to worry about AI.
|
| And so his improvements in mojo and now calling mojo code
| from python just make a lot more net positive to the
| community than being, some other Ai infrastructure company.
|
| So I do wish a lot of good luck to mojo. I have heard that
| mojo isn't open source but it has plans to do so. I'd like to
| try it once if its as fast / even a little slower than rust
| and comparable to understanding as python.
| melodyogonna wrote:
| I don't think investors look at what makes a net positive
| to the community when making large investments like in
| Modular. I was calling out the part of the post that said
| Modular raised a lot of Money to develop Mojo, that isn't
| entirely true as just creating a language isn't enough
| reason to invest $130m into a company, no matter how much
| net-positivity the language would bring.
| ModernMech wrote:
| Agreed, Modular is walking a very fine line, and they're
| doing so by trading on the reputation of Chris Lattner.
|
| On the one had, as the other poster noted, no one raises
| $100M+ for a programming language; programming languages
| have no ROI that would justify that kind of money. So to
| get it, they had to tell VCs a story about how they're
| going to revolutionize AI. It can't just be "python
| superset with MLIR". That's not a $100M story.
|
| On the other hand, they need to appeal to the dev
| community. For devs, they want open source, they want
| integration with their tools, they don't want to be locked
| into a IP-encumbered ecosystem that tries to lock them in.
|
| That's where the tension is. To raise money you need to
| pretend you're the next Oracle, but to get dev buy-in you
| have to promise you're _not_ the next Oracle.
|
| So the line they've decided to walk is "We will be closed
| for now while figure out the tech. Then later once we have
| money coming in to make the VCs happy, we can try to make
| good on our promise to be open."
|
| That last part is the thing people are having trouble
| believing. Because the story always goes: "While we had the
| best intentions to be open and free, that ultimately came
| secondary to our investors' goal of making money. Because
| our continued existence depends on more money, we have
| decided to abandon our goal of being open and free."
|
| And that's what makes these VC-funded language plays so
| fraught for devs. Spend the time to learn this thing which
| may never even live up to its promises? Most people won't,
| and I think the Darklang group found that out pretty
| decisively.
| meander_water wrote:
| Fwiw the website still claims this:
|
| > Further, we decided that the right long-term goal for Mojo is
| to adopt the syntax of Python (that is, to make Mojo compatible
| with existing Python programs) and to embrace the CPython
| implementation for long-tail ecosystem support
|
| Which I don't think has changed.
| JonChesterfield wrote:
| The factorial test giving zero on majo suggests they aren't doing
| arbitrary precision integer arithmetic.
|
| I liked mojo as a python superset. Wanted to be able to run
| arbitrary python through it and selectively change parts to use
| the new stuff.
|
| A "pythonic language" sounds like that goal has been dropped, at
| which point the value prop is much less clear to me.
| bishabosha wrote:
| They explicitly casted it to an 'Int' on the mojo side, but the
| modular website claims that isnt a specific bit-width so i am
| surprised
| melodyogonna wrote:
| From Chris Lattner on Modular discord few days ago:
|
| Yep, that's right. Int behaving like a machine integer is very
| important for systems performance. Leaving the "int" namespace
| untouched allows us to have a object-based bigint in the future
| for compatibility with python. As others have mentioned above,
| it is still a goal to be compatible with python in time, just
| not a short term priority
| saagarjha wrote:
| Taking unchanged Python and making it fast is basically
| impossible.
| fwip wrote:
| Sure - but you can support unchanged Python at regular Python
| speed, and also have extensions to the language that can be
| run at higher speed.
| eyegor wrote:
| I guess they abandoned the python superset idea? I followed
| them for a bit when they first publicly launched and they said
| "don't worry, we'll be a real python superset soon" and the
| biggest omission was no support for classes. A few years later,
| it looks to be missing the same set of python features but
| added a lot of their own custom language features.
| hogepodge wrote:
| I'd say less abandoned, and more deferred.
|
| It was highly aspirational goal, and practically speaking
| it's better right now to take inspiration from Python and
| have stronger integration hooks into the language (full
| disclosure, I work at Modular). We've specifically stopped
| using the "superset of Python" language to be more accurate
| about what the language is meant for right now.
| serial_dev wrote:
| Deferred means it's coming, but we don't know if it will
| ever come. I'd bet it won't.
| pjmlp wrote:
| Given that NVidia now decided to get serious with Python JIT DSLs
| in CUDA as announced at GTC 2025, I wonder how much mindshare
| Mojo will managed win across researchers.
|
| "1001 Ways to Write CUDA Kernels in Python"
|
| https://www.youtube.com/watch?v=_XW6Yu6VBQE
|
| "The CUDA Python Developer's Toolbox"
|
| https://www.nvidia.com/en-us/on-demand/session/gtc25-S72448/
|
| "Accelerated Python: The Community and Ecosystem"
|
| https://www.youtube.com/watch?v=6IcvKPfNXUw
|
| "Tensor Core Programming in Python with CUTLASS 4.0"
|
| https://www.linkedin.com/posts/nvidia-ai_python-cutlass-acti...
|
| There is also Julia, as the black swan many outside Python
| community have moved into, with much more mature tooling, and
| first tier Windows support, for those researchers that for
| whatever reason have Windows issued work laptops.
|
| https://info.juliahub.com/industries/case-studies
|
| Mojo as programming language seems interesting as language nerd,
| but I think the judge is still out there if this is going to be
| another Swift, or Swift for Tensorflow, in regards to market
| adoption, given the existing contenders.
| fulafel wrote:
| The limitations of DSLs and the pull of Python make it a
| practical sweet spot I think if they manage to get the Python
| compatibility up to par.
| bsaul wrote:
| Mojo is marketed as a way to get maximum hardware performance
| on any hardware, not just nvidia.
|
| This may appeal to people wanting to run their code on
| different hardware brands fro various reasons.
| pjmlp wrote:
| True, however that goal is not yet available today, it
| doesn't even run on Windows natively.
|
| And for those that care, Julia is available today on
| different hardware brands, as there are other Python DSL JITs
| as well.
|
| I agree they will get there, now the question is will they
| get there fast enough to matter, versus what the mainstream
| market cares about.
| melodyogonna wrote:
| Mojo GPU kernels can run on both Nvidia and AMD GPUs today
| pjmlp wrote:
| Specific models if I recall correctly.
| melodyogonna wrote:
| Nah, outside of Models you can write Mojo code today that
| work on both Nvidia and AMD gpus, the code itself doesn't
| have to be AI specific.
| fwip wrote:
| I think they meant models of GPU, not models of LLM.
| GeekyBear wrote:
| Just as LLVM doesn't automatically have a backend or
| every new CPU architecture, Mojo/MLIR doesn't
| automatically have a backend for every new CPU/GPU/TPU.
|
| However, writing an LLVM backend for RISC-V sure did add
| support for a whole lot of different programming
| languages and the software you have access to through
| them in one fell swoop.
|
| The same is true here.
|
| Instead of rewiting all your GPU code every time you need
| to target a new GPU/TPU architecture, you just need a new
| backend.
| fnands wrote:
| Mojo (and Modular's whole stack) is pretty much completely
| focused at people who are interested in inference, not training
| nor research so much at this moment.
|
| So going after people who need to build low latency high-
| throughput inference systems.
|
| Also as someone else pointed out, they also target all kinds of
| hardware, not just NVidia.
| pjmlp wrote:
| Currently looks more like CPUs and eventually AMD, from what
| I have been following up on their YouTube sessions, and whole
| blog post series about freedom from NVidia and such.
|
| They also miss CPUs on Windows, unless using WSL.
| MohamedMabrouk wrote:
| Already GPU code, kernels, and complete models can run on
| datacenter AMD GPUs using the same code, the same
| programming model, and same language constructs.
| pjmlp wrote:
| Laptops?
| MohamedMabrouk wrote:
| not sure, modular is focusing mainly on enterprise
| applications. but if you look at the current PRs you can
| see people hacking support for standalone consumer-grade
| Nvidia and AMD gpus because it is easy, you just add the
| missing or different intrinsics for the architecture in
| the lowest level (in pure mojo code) and wire it up in a
| few places and voila you already program and run code on
| this GPU. iGPU/Apple GPUs are still not supported yet but
| it would interesting to see their integration
| patternsplicing wrote:
| Yes, recent NVIDIA and AMD consumer GPUs are supported:
| https://docs.modular.com/max/faq/
| hogepodge wrote:
| There's pretty broad support for server-grade and consumer
| GPUs. It's a bit buried, but one of the most reliable lists
| of supported GPUs is in the Mojo info documentation.https:/
| /docs.modular.com/mojo/stdlib/gpu/host/info/
| orochimaaru wrote:
| Why not use PyO3 instead? It had a much cleaner interface
| than cython and c++ libraries.
|
| The primary advantage of mojo seems to be Gil-free syntax
| that is as close to Python as possible.
| fnands wrote:
| GPU programming in Rust isn't great.
|
| In Mojo it's pretty much the whole point of the language.
| If you're only using CPUs, then yeah, PyO3 is a good
| choice.
| diggan wrote:
| What about Candle, made by Huggingface? Seems to at least
| allow the basics and has lots of examples, all of them
| run on both CPU and GPU. Haven't dived deeper into it,
| but played around with it a bit and found it good enough
| for embedding purposes at least.
| GeekyBear wrote:
| I think the big value add of Mojo is that you are no
| longer writing GPU code that only runs on one particular
| GPU architecture.
|
| In the same way that LLVM allows CPU code to target more
| than one CPU architecture, MLIR/Mojo allows GPU code to
| target multiple vendor's GPUs.
|
| There is some effort required to write the backend for a
| new GPU architecture, and Lattner has discussed it taking
| about two months for them to bring up H100 support.
| ForHackernews wrote:
| I love Julia and want to see it break through. It suffers from
| the lack of a big corporate patron.
| pjmlp wrote:
| Plenty of them exist already, that is why I pointed out this,
| that HNers keep overlooking
|
| https://info.juliahub.com/industries/case-studies
| ForHackernews wrote:
| Sure, a bunch of companies use Julia but none of them are
| backing it the way Google backs Go, Oracle backs Java, or
| Mozilla (formerly) backed Rust.
| pjmlp wrote:
| Didn't hurt that much for Python, Ruby, not having a big
| name in the early days.
|
| Just like I would consider MIT and a few of the companies
| on that listing as relevant, doesn't need to always be a
| FAANG.
| b33j0r wrote:
| I'm someone who should be really excited about this, but I
| fundamentally don't believe that a programming language can
| succeed behind a paywall or industry gatekeeper.
|
| I'm always disappointed when I hear anything about mojo. I can't
| even fully use it, to say nothing of examine it.
|
| We all need money, and like to have our incubators, but the LLVM
| guy thinks like Jonathan Blow with jai?
|
| I don't see the benefit of joining an exclusive club to learn
| exclusively-useful things. That sounds more like a religion or
| MLM than anything RMS ever said :p
| ModernMech wrote:
| > the LLVM guy thinks like Jonathan Blow with jai?
|
| I would not compare Chris Lattner with Jonathan Blow. Lattner
| is a person with a reputation for delivering programming
| languages and infrastructure; whereas for Blow, it seems like
| an ego issue. He's built a nice little cult of personality
| around his unreleased language, and releasing it will kill a
| lot of that magic (running a language project with actual users
| that has to make good on promises is much different than
| running a language project with followers and acolytes that can
| promise anything and never deliver on it).
|
| Lattner has a record of actually delivering dev products people
| can download and use. Mojo is closed source to make raising
| money easier, but at least you can actually use it. Jai isn't
| even available for people to use, and after a decade of Blow
| dangling it in front of people, it's not clear it'll ever be
| available, because I'm not sure he _wants_ it to be available.
| Someone wrote:
| FTA (emphasis added): "Chris Lattner mentioned that Python can
| actually _CALL_ Mojo code now"
|
| So, the message is that it is possible to create nice Python
| bindings from Mojo code, but only if your Mojo code makes the
| effort to create an interface that uses _PythonObject_.
|
| Useful, but I don't see how that's different from C code coding
| the same, as bindings go.
|
| Both make it easier to gradually move Python code over to a
| compiled language.
|
| Mojo presumably will have the advantage that porting from Python
| to Mojo is much closer to a copy paste job than porting Python to
| C is.
| bgwalter wrote:
| No, Python cannot run Mojo. Like Cython and _hundreds of_ other
| projects, Mojo creates a C-extension, which is then loaded.
|
| https://docs.modular.com/mojo/manual/get-started/
| curl -fsSL https://pixi.sh/install.sh | sh pixi init life \
| -c https://conda.modular.com/max-nightly/ -c conda-forge \
| && cd life
|
| No, thanks. C++ is easier.
| justin66 wrote:
| > C++ is easier.
|
| I expect that opinion will not be universally agreed upon.
| sanderjd wrote:
| The example in the article seemed a lot easier to build and use
| than a C++ extension.
|
| It's unclear to me from this comment, what exactly your
| pushback is.
| hogepodge wrote:
| One of the big differences here is that the Mojo/Python interop
| package is doing a lot of the heavy lifting of compiling and
| loading the code. The goal here is to have a language that's
| close to Python that gives you hardware acceleration as you
| need it, without having to configure and build C++ code for
| every platform.
|
| We've run a few events this year (disclosing again that I work
| for Modular, to put my comments into context), and we've had
| some great feedback from people who have never done GPU
| programming about how easy it was to get started using Mojo.
|
| C++ is a powerful and mature language, but it also has a steep
| learning curve. There's a lot of space for making GPU (and
| other high performance computing) easier, and
| platforms/languages like Triton and Julia are also exploring
| the space alongside Mojo. There's a huge opportunity to make
| GPU programming easier, and a bit part of that opportunity is
| in abstracting away as much of the device-specific coding as
| you can.
|
| I was a HPC C++ programmer for a long time, and I always found
| recompiling for new devices to be one of the most painful
| things about working in C++ (for example, the often necessary
| nightmare of cmake). Mojo offers a lot of affordances that
| improve on the programming experience at the language,
| compiler, and runtime levels.
| usrbinbash wrote:
| https://en.wikipedia.org/wiki/Mojo_(programming_language)
|
| > As of February 2025, the Mojo compiler is closed source
|
| And that's where the story begins and ends for me.
| roflmaostc wrote:
| https://docs.modular.com/mojo/faq/#open-source
|
| > Will Mojo be open-sourced?
|
| > We have committed to open-sourcing Mojo in 2026. Mojo is
| still young, so we will continue to incubate it within Modular
| until more of its internal architecture is fleshed out.
|
| Soon it might be though.
| Simon_O_Rourke wrote:
| Many thanks for the update on this particular aspect of it.
| That rules it out of any production deployment until 2026 so.
| diggan wrote:
| > That rules it out of any production deployment until 2026
| so.
|
| Has that stopped everyone before? Java, C#/.NET, Swift and
| probably more started out as closed-source
| languages/platforms, yet seemed to have been deployed to
| production environments before their eventual open-
| sourcing.
| pelcg wrote:
| Many developers had no problem using .NET and C# in
| production despite them starting out as closed-source for
| years.
| usrbinbash wrote:
| Yes, and there is a reason for that: Both are deeply
| integrated in Microsofts ecosystem, and whether one likes
| that or not, that ecosystem is the dominant platform for
| desktop computing, especially in commercial settings.
|
| What would be comparable driver for Mojo?
| mdaniel wrote:
| I don't think Java (when it was owned by Sun) nor .NET
| (even currently) run the risk of a VC "our incredible
| journey" event causing "barrel bending" nor the backing
| company running out of money. In the first flavor, they'd
| want their pound of flesh and the "our new compiler
| pricing is ..." would be no good. In the latter, even if
| they actually opened the platform on the way out, it
| still would require finding a steward who could carry the
| platform forward, which is a :-( place to be if you have
| critical code running upon it
|
| I guess the summary is that neither Java [at the time]
| nor .NET were profit centers for their owners, nor their
| only reason for existing
| altbdoor wrote:
| https://i.imgur.com/0NaxFGB.png
| Scene_Cast2 wrote:
| The thing I focus on when writing compiled extensions for Python
| isn't the speed of the extension, but rather the overhead of the
| call and the overhead of moving objects from Python -> compiled
| and compiled -> Python.
|
| Is there a zero-copy interface for larger objects? How do object
| lifetimes work in that case? Especially if this is to be used for
| ML, you need to haul over huge matrices. And the GIL stuff is
| also a thing.
|
| I wonder how Mojo handles all that.
| MohamedMabrouk wrote:
| AFAIK, there is a zero-copy interface for objects like numpy
| array and torch tensors where you can do in-place manipulation
| in mojo.
| adsharma wrote:
| I like mojo for being closer to python than other systemsy
| languages.
|
| But asking people to learn another language and migrate is a tall
| barrier.
|
| Why not write python and transpile to mojo?
| dummydummy1234 wrote:
| My impression is that mojo is not python, there are
| similarities, but under the hood mojo is much more similar to
| c++/rust.
|
| As part of this it has a stronger type/lifecycle/memory model
| than python.
|
| Maybe you could write, some level of transpiler, but so much of
| the optimizations rely on things that python does not expose
| (types), and there are things that python can do that are not
| supported.
| faceplanted wrote:
| Transpilers in general tend to be significantly less well
| maintained and optimised than direct APIs
| adsharma wrote:
| I'm not a disinterested observer.
|
| Py2many has had a mojo backend for a year now.
|
| https://github.com/py2many/py2many/tree/main/tests/expected
| melodyogonna wrote:
| The plan is to have a mechanical tool someday that can
| transpile Python code to Mojo
| b0a04gl wrote:
| wow, it compiles to python callable '.so' via PythonModuleBuilder
| without extra C layer needed. test cases show tight loop
| performance gains prime count up to 20k runs 0.011s vs 0.446s in
| pure python. this unlocks low friction speedups where python hits
| the wall. there's still type constraints factorial(100) overflows
| due to fixed int width, no bigint fallback. worth tracking how
| array handling evolves, since that'll decide if mojo stays in
| compute heavy corners or becomes viable for broader use. it's
| early but usable is the key word
| MHM5000 wrote:
| > truck of salt
|
| :)))
___________________________________________________________________
(page generated 2025-06-23 23:01 UTC)