19 ms·

Mojo – a new programming language for AI developers

643 points by lairv 3y ago

cs702 3y ago
Well, I'm blown away. If this succeeds, it will allow you to use Python for the entire AI stack: high-level model composition (as usual), fast compiled CPU code (instead of, say, libs written with C++), and on-device operations (instead of, say, libs that use CUDA). Oh, and it will make your Python code parallel (i.e., there's no GIL). Obviously, we'll have to wait until Mojo is production-ready, but I'm excited after seeing Jeremy Howard's easy-to-follow examples during the live keynote presentation. Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while. Props to the Mojo team!
- lairv 3y ago
  Exciting stuff indeed, looks like a unified approach to recent developments like (OpenAI) Triton, TVM, OpenXLA, ONNX Runtime, etc. though we'll have to wait for proper benchmarks and compatibility to know how great it is. Also it's a bit of a bummer that the compiler is behind a waitlist for now
- throwaway894345 3y ago
  This isn’t Python though, right? It’s just a Python-like syntax for a much lower level programming language (sort of like Cython) from my cursory glance? It seems a lot like Rust with a Pythonic veneer, so I would expect it will run into many of the same problems that Rust has (lots of difficulty pacifying the borrow checker)?
  - cs702 3y ago
    The source code is Python (well, a superset of Python), but it's not interpreted and run by the official Python interpreter. Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic.
    - throwaway894345 3y ago
      Maybe someone can correct me, but I don't think it's a superset of Python--I don't think it will accept existing Python programs and I'm pretty sure you can't do all of the dynamic Python stuff (otherwise you would have to essentially compile/link an interpreter into your binaries giving you these super slow paths that aren't necessarily obvious when reading source code). > Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic. I think it "feels Pythonic" because you're looking at Pythonic syntax. I suspect when you're banging your head against a borrow checker it will feel more like writing Rust. Like I'm pretty sure anything with a borrow checker will have to deal with lifetimes, mutable-vs-immutable references, shared mutability (cell/refcell in rust), etc; I don't know how you "Pythonify" that in any meaningful way?
      - bjornasm 3y ago
        >We utilize CPython to run all existing Python3 code “out of the box” without modification >Further, we decided that the right long-term goal for Mojo is to provide a superset of Python
        asqueella 3y ago
        The FAQ states that “Mojo is still early and not yet a Python superset, so only simple programs can be brought over as-is with no code changes.” I have no idea how to reconcile that with the quotes you provided. [edit] Ah, it seems you can control things running in a bundled CPython: plt = Python.import_module("matplotlib.pyplot") fig = plt.figure(1, [width, height], dpi) ax = fig.add_axes([0.0, 0.0, 1.0, 1.0], False, 1), "hsv", 0, 0, 1.5) ... plt.imshow(image)
- otoburb 3y ago
  >>If this succeeds, it will allow you to use Python for the entire AI stack [...] If this succeeds, the terminal endpoint will be the Python Software Foundation adopting Modular as the defacto and eventually official implementation since, as Modular noted in their docs, they effectively need Mojo to be absolutely amazing on generalized host CPUs as the key enabler allowing for the unified Python-superset experience across other types of general and specialized hardware ("xPU"). Julia will be dealt an adoption setback proportional to Mojo's growing success.
  - ipsum2 3y ago
    No it won't. The language is not a super-set of Python, its another language that somewhat resembles Python. You can't drop in some Python code and run it with Mojo and expect it to work.
    - jadodev 3y ago
      The goal is for the language to be a superset of Python > Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (i.e. be compatible with existing programs) and to embrace the CPython immediately for long-tail ecosystem enablement. https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html
      - azakai 3y ago
        But see the section "Intentional differences from Python", which is after your quote, https://docs.modular.com/mojo/why-mojo.html#intentional-differences-from-python https://docs.modular.com/mojo/why-mojo.html#intentional-diff... > our approach to compatibility is two fold: > 1. We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. > 2. We will provide a mechanical migrator that provides very good compatibility for people who want to move Python code to Mojo. > Together, this allows Mojo to integrate well in a mostly-CPython world, but allows Mojo programmers to be able to progressively move code (a module or file at a time) to Mojo. This approach was used and proved by the Objective-C to Swift migration that Apple performed. Maybe the long-term goal is to try to make it a true superset, but it sounds like the detailed plan is more practical, to basically provide a "Python-next" language, like Swift for Objective-C.
- jph00 3y ago
  > Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while Oh yes!
  - cs702 3y ago
    :-)
  - fredguth 3y ago
    I can’t wait to see fast.ai-next in mojo :-)
PartiallyTyped 3y ago
NB: sign-up with email required to "get started".
rvz 3y ago
A magnificent game changing project once again by the creator(s) of LLVM. I think this time they might have a proper Python alternative. Many have tried like Julia Lang, R, C#, Swift, Rust, Haskell, etc and all have failed in competing against Python. Perhaps this time, we finally have one that is a proper replacement for anything requiring intensive compute and performance without being a systems programmer, all thanks to the finest compiler engineers who brought you LLVM, MLIR and now Mojo. (Not the AI hype squad sitting on O̶p̶e̶n̶AI.com's APIs.) If you know Python you have learned 90% of Mojo. Just waiting to see if it can compile to a binary.
- verdverm 3y ago
  Will I be able to use all of the existing libraries from Python? If not, it's going to be hard to make the switch
  - chrislattner 3y ago
    Yep, they already just work, Check the website or the demo in the launch video from Jeremy Howard. Also potentially interesting: https://docs.modular.com/mojo/programming-manual.html#python-integration https://docs.modular.com/mojo/programming-manual.html#python... https://docs.modular.com/mojo/notebooks/Mandelbrot.html https://docs.modular.com/mojo/notebooks/Mandelbrot.html
    - JonChesterfield 3y ago
      If that works with any libraries built on the CPython C API it would be worth calling it out in the docs - it currently reads like pure python or numpy work, but I assumed that was because you'd reimplemented numpy, not managed to dlopen it (and worked around those libraries relying on the GIL).
      - JonChesterfield 3y ago
        Found said part of the docs at https://docs.modular.com/mojo/why-mojo.html#how-compatible-is-mojo-with-python-really https://docs.modular.com/mojo/why-mojo.html#how-compatible-i... notably > We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem
chubot 3y ago
Seems like it could be interesting ... Initial impression is that the animation of Mojo code vs. Python code has a bad UX. Why not just show the code side-by-side instead of animating it and making me click? Another obvious question is how is it different than Numba and so forth? https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html The Mojo language has lofty goals - we want full compatibility with the Python ecosystem, we would like predictable low-level performance and low-level control, and we need the ability to deploy subsets of code to accelerators. We also don’t want ecosystem fragmentation - we hope that people find our work to be useful over time, and don’t want something like the Python 2 => Python 3 migration to happen again. These are no small goals! and Mojo already supports many core features of Python including async/await, error handling, variadics, etc, but… it is still very early and missing many features - so today it isn’t very compatible. Mojo doesn’t even support classes yet! So I think the idea is good, but yeah re-implementing Python is a huge effort ! Though the comparison right below is notable: A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community
- ChrisRackauckas 3y ago
  > A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way. The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances. That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about (https://www.youtube.com/watch?v=VdD0nHbcyk4 https://www.youtube.com/watch?v=VdD0nHbcyk4). What I would find worrisome too is that this approach sounds like compile time city. A lot of the recent advancements in Julia have been by sending less to LLVM: optimizations are done in Julia and dead code is eliminated, calls are found to be the same and check caches, and then with v1.9 those caches use precompiled binaries to avoid having to call LLVM again. And the timeline of improvements shows that making LLVM be in the picture as little as possible has lead to some dramatic improvements in Julia's latency (https://viralinstruction.com/posts/latency/ https://viralinstruction.com/posts/latency/). Given what was seen from that, I'm weary of an approach that does everything in LLVM (via MLIR) on an even more dynamic representation (i.e. Python). My guess is that only things with explicit types will compile, and the rest is probably hitting some Python interpreter to avoid this issue. [If part is using Python/GC through an interpreter though, wouldn't that part be harder to target to accelerators since it wouldn't compile through LLVM? That would mean only the code that is explicitly typed gets the nice new features, but not the Python parts?] But hey, if this gets Chris Lattner and crew a reason to start taking LLVM compile times more seriously, then it's a win for Julia as well. I'm excited to see how the communities can benefit from one another, especially if Mojo is open source then it can be a win for all (which was definitely not clear in the presentation). And I do think that some of the ideas of lower level memory control are cool and should be added similarly to languages like Julia and Numba.
kerinin 3y ago
Interesting to see some of Rust's ideas start to spread. I never thought borrow checking would become popular ;)
cube2222 3y ago
This looks quite interesting with big names behind it. I'd love to see a comparison vs Julia though, which I think tried to tackle some of the same problems.
- UncleOxidant 3y ago
  Yeah, it seems like they sort of reinvented Julia but with more of a Python syntax?
- cube2222 3y ago
  > we want full compatibility with the Python ecosystem Oh, I guess that's one big philosophical difference.
- TheMagicHorsey 3y ago
  I was thinking about Julia too. I guess they will try to make it reasonably compatible with Python directly making rewrites easier than Julia? Edit: just saw this is a project by Chris Latner and Tim Davis. Hahaha ... that's immediate credibility.
  - UncleOxidant 3y ago
    but Mojo seems to keep all of that numpy cruft that's there because Python. (numeric computing was bolted onto python via numpy, but it's built-into Julia)
  - borodi 3y ago
    I'm sure there are reasons for it, but Chris Lattner has been jumping around a bit. Remember swift4TF. But hopefully this one is seen through with lots of open source too.
- staticfloat 3y ago
  It is a little disappointing that they're setting the bar against vanilla Python in their comparisons. While I'm sure they have put massive engineering effort into their ML compiler, the demos they showed of matmul are not that impressive in an absolute sense; with the analogous Julia code, making use of [LoopVectorization.jl](https://github.com/JuliaSIMD/LoopVectorization.jl https://github.com/JuliaSIMD/LoopVectorization.jl) to automatically choose good defaults for vectorization, etc... julia> using LoopVectorization, BenchmarkTools, Test function AmulB!(C,A,B) @turbo for n = indices((C,B),2), m = indices((C,A),1) Cmn = zero(eltype(C)) for k = indices((A,B),(2,1)) Cmn += A[m,k]*B[k,n] end C[m,n]=Cmn end end M = K = N = 144; A = rand(Float32, M,K); B = rand(Float32, K,N); C0 = A*B; C1 = similar(C0); AmulB!(C1,A,B) @test C1 ≈ C0 2e-9*M*K\*N/@belapsed(AmulB!($C1,$A,$B)) 96.12825754527164 I'm able to achieve 96GFLOPs on a single core (Apple M1) or 103 GFLOPs on a single core (AMD EPYC 7502). And that's not even as good as what you can achieve using e.g. TVM to do the scheduling exploration that Mojo purports to do. Perhaps they have more extensive examples coming that showcase the capabilities further. I understand it's difficult to show all strengths of the entire system in a short demonstration video. :) EDIT: As expected, there are significantly better benchmarks shown at https://www.modular.com/blog/the-worlds-fastest-unified-matrix-multiplication https://www.modular.com/blog/the-worlds-fastest-unified-matr... so perhaps this whole discussion truly is just a matter of the demo not showcasing the true power of the system. Hopefully achieving those high performance numbers for sgemm is doable without too much ugly code.
UncleOxidant 3y ago
So... did they reinvent Julia? (but with more of a python syntax)
deleted 3y ago
[deleted]
alberth 3y ago
So is this actually Python or not? I’m a bit confused.
- abc_lisper 3y ago
  This is like C++ to C - so python++, ++ is for features and native compilation
- bufo 3y ago
  It's a superset of Python. What you call "Python" is actually CPython, a C implementation of the Python language. Many other Python implementations exist, though they typically don't support all packages well (for example lack of support of native Python extensions like what Numpy relies on). It looks like Mojo has its own runtime (so not CPython) but also packages CPython for compatibility?
  - ipsum2 3y ago
    Wrong, Mojo is not a runtime for Python.
tgma 3y ago
Swift already imported Python code in a similar fashion. Feels like this is a more Pythonic syntax for Swift and likely carries over all the underlying goodness. [FWIW, folks waiting for this should also look at Cython, which is different, but uses Pythonic syntax for more of a C-like semantics.]
- liuliu 3y ago
  Swift doesn't do a good job of interleaving with Python (i.e. allowing Python to call into Swift, while possible, is nothing like Numba due to various object type translation required). Mojo seems to be targeting Mojo -> Python -> Mojo too (i.e. Mojo can do high level control flow, delegate some more control flow / unsupported ops to Python, then implement some accelerator supports that Python will call back to). This can be quite difficult if you want to have very low bridging cost (Python objects are quite large and different libraries, such as Python / numpy have different representations in C on top of these Python objects). It is all possible (after all, we are doing computer stuff), but it is a quite difficult path comparing to other success interop stories (Swift / ObjC took a decade to achieve somewhat low bridging cost, Kotlin / Java simply gives up and doing everything in JVM).
chrislattner 3y ago
There are a bunch of questions about Julia, so I'll do my best to give a short answer to a very long and complicated topic. Up front, Julia is a wonderful language and a wonderful community, I am a super fan. That said, Mojo is a completely different thing. It is aligned with the Python community to solve specific problems outlined here: https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html Mojo also has a bunch of technical advancements compared to Julia by virtue of it being a much newer development and being able to learn from it (and Swift and Rust, and C++ and many many other languages). Including things like ownership and no GC. We also think there is room for a new language that is easier to deploy, scales down to small envelopes, works directly with the full Python ecosystem, is designed for ML and for MLIR from first principles, etc. Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) EDIT: Just in case there is any confusion, I work for Modular, built LLVM, Swift, Clang, MLIR and a variety of other things. I wasn't trying to misrepresent as being unaffiliated.
- travisoliphant 3y ago
  Congratulations on the launch and work so far! This is indeed very interesting. I believe a language like this is necessary for future progress. I have also been impressed with Julia and its progress. I would have liked to see more progress on Ahead of Time compilation and using it to write Python extension modules. For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers. We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate. Understanding what will be open-source is of course, critical for that.
- UncleOxidant 3y ago
  I notice that Mojo still seems to use numpy or something that looks "numpyish" for compatibility. Will Mojo also have an alternative syntax for doing things like matrix multiplication that looks more native like Julia's?
drivingmenuts 3y ago
Somewhere out there, a recruiter is gearing up to demand 5 years experience with Mojo before they will look at your resume.
- pknerd 3y ago
  I already added "Mojo Evangelism is my mojo" in my LinkedIn Title.
  - Archit3ch 3y ago
    Dibs on Mojo Dojo (mojodojo.com), your new premier training resource for Mojo.
    - Apocryphon 3y ago
      I wonder if GoJo (Lukas Matsson‘s app) is built with Mojo
    - mkaic 3y ago
      Mojo Dojo was briefly the name of a trampoline park in Sacramento before it got bought out by SkyZone
- kps 3y ago
  Hey, I've used https://source.chromium.org/chromium/chromium/src/+/main:mojo/ https://source.chromium.org/chromium/chromium/src/+/main:moj... (tl;dr Chromium's IPC) which is enough to pass the recruiter screening. (And, uh, just applied to this Mojo because I'd love to get back to language compiler work.)
l2dy 3y ago
A file extension of [fire emoji], this is not easy to type from a terminal. Edit: It's even stripped on HN!
- lairv 3y ago
  Read on their discord server that it both support .mojo and the fire emoji
  - newswasboring 3y ago
    The fire emoji as file extension makes me feel very uncomfortable. Am I old now? (I know I don't have to use it, but I usually work in big projects with lots of other people's code).
- kps 3y ago
  echo $'<Multi_key> <m> <o> <j> <o> : "\U1F525" U1F525 # FIRE' >>~/.XCompose I'm not personally a fan of emoji, but I do like using and typing more than plain ASCII in the terminal. (One thing I liked about Julia is their partial embrace of Unicode, and one thing I don't is that you can't write lambdas with ‘↦’.)
calebm 3y ago
Python Interoperability seems like a killer feature.
otabdeveloper4 3y ago
Sorry, I can't apply this to my use case until it gets a blockchain plugin.
mindcrime 3y ago
Will Mojo be OSS? Or is this strictly proprietary?
- chrislattner 3y ago
  Open source over time as it matures: https://twitter.com/Modular_AI/status/1653439606522802176?s=20 https://twitter.com/Modular_AI/status/1653439606522802176?s=...
dunefox 3y ago
I wish new languages would move away from python syntax and semantics and just do their own thing more.
- dom96 3y ago
  I wish more would take inspiration from Python syntax.
tikkun 3y ago
Fascinating. The AI industry is currently beholden to Nvidia, in part because of CUDA's superiority over ROCm. Therefore there's a big need for projects like this. See also: https://openai.com/research/triton https://openai.com/research/triton
minhazm 3y ago
Is this closed source? I just assumed that a new programming language would be open source but I don't see any links to GitHub or any other place. The getting started page also requires you to put in your name and contact information.
- ModernMech 3y ago
  This is exactly what I was trying to figure out. It seems like the answer is no at this time.
  - lairv 3y ago
    From their FAQ https://docs.modular.com/mojo/faq.html https://docs.modular.com/mojo/faq.html "Will Mojo be open-sourced? Yes, we expect that Mojo will be open-sourced. However, Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out. We don’t have an established plan yet. Why not develop Mojo in the open from the beginning? Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.)."
    - theLiminator 3y ago
      Their response to why it's faster to move while closed source seems kinda like a false dichotomy. They can choose to start with it open disallow input from the community or close their issue tracker to the community.
      - vosper 3y ago
        Why bother doing it that way? Just to entertain people who works like to observe the commit history as the language evolves?
        3y ago
deleted 3y ago
[deleted]
alberth 3y ago
The parallelism of Mojo would make it an interesting language for a web framework.
ConanRus 3y ago
[dead]
Sukera 3y ago
Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that only parts of python will actually be supported for full acceleration? At least your docs[1] seem to say so.. -- [1]: https://docs.modular.com/mojo/why-mojo.html#intentional-differences-from-python https://docs.modular.com/mojo/why-mojo.html#intentional-diff...
- throwawaymaths 3y ago
  Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependencies. Venv/conda which do sneaky things e.g. with your shell is super dangerous (https://twitter.com/garybernhardt/status/1653171980483575808 https://twitter.com/garybernhardt/status/1653171980483575808), and a misstep can trash your system especially when it has to deal with wheels with system-level dependencies (looking at you, tensorflow -- probably half of the reason why people moved to pytorch). Poetry sounds nice. It's been a while since I've checked in with the python ecosystem. Are ML people using that yet? - Subpar deployment. Let's remember that Containerization basically exists because Python does not have an ops story. - Subpar integration with web. You are forced to either create a microservice, or, spin it up within Django (nobody really does this). Then you typically have to pull in a bunch of sidecar processes (Redis, Celery, etc.) just to get queuing of your web jobs correct. - Poor concurrency. Sure, you can run your tensorflow code in an awkward 'with' statement but I think there are very few ML practicioners who could really explain to you what that with is doing. That GPU is actually fundamentally an asynchronous entity. And god help you if you want to run and debug async python. - No distribution story. Sure, the big guys are able to spin up, e.g. Horovod, but it's not really a thing for someone with less resources for a hot second on a few machines, and again, god help you if something goes wrong and you need to debug it. Does Mojo solve any of these issues? From a cursory look, it looks like no.
  - 3y ago
helen___keller 3y ago
Was very pleased to see that for meta programming, they went with something similar to Zigs comptime
JonChesterfield 3y ago
Reached end of docs. I'm sold. - Compile time language is ~ the runtime one. That's the model most systems languages seem to have ended up at. It doesn't have macros or reflection, but neither of those seem to be very popular - The struct/let notation and lifetime model essentially give you C++ semantics with saner syntax. The class/def notation essentially give you python semantics. This is a clean answer to the gradual-typing-for-performance problem - You can drop into MLIR at will and the std types are implemented like that. This makes the language look a lot like syntactic sugar over writing the IR which closely matches how (at least some) compiler devs think about programming languages Yeah, I think that'll work. Python/C++ mashup is a popular dev stack and this can make that much cleaner. Faster than C is rather unproven but given the difference in compile time control should be achievable.
- kashif 3y ago
  Have a good look at Nim
deleted 3y ago
[deleted]
silisili 3y ago
Is this usable as a general purpose language, or is it too tailored to AI/ML tasks and thus missing a lot of 'general' libraries and such? How does performance compare to Python in the general case, when not dropping into tricks? Either way, kudos, exciting stuff, just questions I had after reading about it.
- drBonkers 3y ago
  I'm also curious. Modular seems to be what Chris wanted with Swift, but couldn't because of Apple's thumb.
- JonChesterfield 3y ago
  Looks great for writing compilers in to me. Doesn't need much in the way of external libs, really well positioned to build parts of MLIR using it.
- tomhallett 3y ago
  Yeah, obviously curious if a fastapi port could be written in mojo
- gazpacho 3y ago
  I would like to know this as well. Not just “can you write general purpose programs” but is that one of the fundamental design goals. For example, in my personal opinion Julia does not meet the bar. One of Python’s powerful features outside of being a great glue language for AI is rich runtime reflection and introspection. This is what allows things like FastAPI/Pydantic to work. Will Mojo support this level of runtime introspection? I’m also curious about the type system. Will it be Python level or TypeScript level?
version_five 3y ago
The website is unusable for me (brave on android). I can't really scroll. Am I the only having this problem?
earthboundkid 3y ago
One of the biggest problems with Python is packaging, and one of the biggest problems with Python packaging is installing scientific computing modules that rely on C/C++/Fortran. Will Mojo attempt to address these problems?
- IceHegel 3y ago
  Yes this must be fixed. Python packaging is such a nightmare I use a fresh docker image for every project, which is much easier than messing with pyenvs, conda, broken wheels and that whole mess.
tabtab 3y ago
Is there a sample or tutorial that jumps right into typical examples of what's different or special about it? I tried to find such, but the docs get lost in syntax details and other minutia. I want the ADHD-meat-and-potatoes tutorial. Maybe that's asking too much, but I did it anyhow, as any ADHDer would.
- ModernMech 3y ago
  > I want the ADHD-meat-and-potatoes tutorial. What does this mean?
  - tabtab 3y ago
    "Gimme gimme gimme!"
kraihx 3y ago
Not to be confused with the now more than a decade old web framework for Perl, and most popular module on CPAN: https://metacpan.org/pod/Mojo https://metacpan.org/pod/Mojo Or it's port to TypeScript: https://mojojs.org https://mojojs.org
ubj 3y ago
Looks really interesting! A couple questions: * Will Mojo be able to generate portable, standalone binaries and libraries? * If so, will the size of the binaries / libraries be similar to C / Rust binary sizes? These are pretty big pain points for both JAX and Julia (Julia is slowly making progress on this front though)
sytse 3y ago
Very cool development. There is too much busy work going from development to test to production. This will help to unify everything. OpenAI Triton https://github.com/openai/triton/ https://github.com/openai/triton/ is going for a similar goal. But this is a more fundamental approach.
vsskanth 3y ago
Can this produce a static AOT compiled binary ? This seems to be currently one of the biggest limitations to Julia (and even Python) in terms of distribution, especially in the embedded space. PackageCompiler.jl helps, but binaries are still huge
- ModernMech 3y ago
  How big are the binaries? (what I mean is, are they 1MB, or 100MB, or worse?)
  - ubj 3y ago
    Over 150 MB for "Hello world" [1][2]. There are a few options for going smaller (e.g. StaticCompiler.jl), but they're not very mature yet. [1]: https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hello_world_application/ https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hel... [2]: https://discourse.julialang.org/t/standalone-hello-world-executable-size-comparison-to-node-js/97656 https://discourse.julialang.org/t/standalone-hello-world-exe...
  - adgjlsfhk1 3y ago
    Julia's binaries are currently 50mb to 1gb depending on what you put in them. The large floor comes from the fact that you have to ship LLVM which is around 50 MB by itself. (the 1gb binaries are if you include a couple thousand packages in the binary also).
ricopags 3y ago
Congratulations on the launch preview! This is exciting, as I've been waiting for this announcement since Jim Keller's callout on Lex Fridman podcast two years ago[0]. I'm curious about the teasing around open source. Obviously the amount of money and the slick product launch dictate a need to capitalize on this pooled expertise. Don't want to give away the game to the hyperscalers. I wonder what the revenue and license models are going to end up looking like. A cloud of their own, professional services to HW manufacturers to optimize their performance, professional services to hyperscalers? Curious if anybody has any ideas beyond the obvious. [0]https://youtu.be/G4hL5Om4IJ4?t=4048 https://youtu.be/G4hL5Om4IJ4?t=4048
throwaway12223 3y ago
what about pointers?
- chrislattner 3y ago
  What's the question? They are sharp and pointy and Mojo has an unsafe `Pointer` struct vended by the standard library for folks who know what the they are doing.
fleur-de-lotus 3y ago
Could you consider choosing another name for the language? mojo doesn't sound sexy. Ask for suggestions.
nojonestownpls 3y ago
This is the final nail in the coffin for "Julia as a replacement for Python" in my eyes. Maybe I'm very late to that conclusion, maybe the writing's been on the wall for a while, but I still held out hope that Julia could be at least a parallel peer to Python sharing the market. But now, it seems almost certain that Julia will end up a possible replacement-for-Matlab niche language, unknown and unused by most outside the niche. It's a pretty big and important niche, to be sure, but a bit disappointing given how nice the language is.
- nologic01 3y ago
  Predicting language ecosystem development is difficult, especially if its about the future. It does feel that Julia may have missed its window of opportunity. But maybe not. On the one hand Python's mindshare has been growing exponentially, riding on successive waves of data science, machine learning, deep learning, AI and now AGI hypes. NB: The two hypes it did not benefit from (for obvious reasons) are big data and crypto/blockchain. Given, though, Python's heavy historical baggage, you could think that eventually gravity would re-assert itself - with a potential crash landing. So in a sense, if the mojo project succeeds becoming a very broad based renewal effort (a Python 4 thing) that fixes some of Python's limitations, it will lock-in Python's current amazing popularity. If not, then the field is still open for a challenger and Julia could well be that. The broader technology space feels very febrile right now. Lots of talk, much less walk. The winners will be simply those who deliver tangible "next-gen" experiences to developers and end-users.
- pjmlp 3y ago
  Julia is doing alright, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
  - freilanzer 3y ago
    Alright most likely isn't going to cut it when Python gets even more entrenched.
    - pjmlp 3y ago
InitEnabler 3y ago
Wonder how this compares to Nim.
AbuAssar 3y ago
Chris Lattner of LLVM and Swift fame is behind mojo
gok 3y ago
Finally, the package management ecosystem of Python with the compiler speed and error messages of Rust and Swift.
rg111 3y ago
I would have started using it today for my personal projects and write tutorials if it were FOSS. It looks sooo good. Once it turns into FOSS (if it does), I will start using it as quickly as I can. Then, if and when it gets more mature, and delivers on its promises, I might start using it at my work.
drBonkers 3y ago
Why would I use this over Nim?
- pineapple_sauce 3y ago
  From what I can tell: 1. They have a REPL and Jupyter integration 2. They're planning to do C and C++ interop. This is achievable in Nim but it is a pain, i.e. there is not easy way to import/include a C header in Nim, e.g. nothing as straight-forward as @cImport("cheader.h") in Zig or #include "cheader.h" in C++; one must go through c2nim or a third-party library (1) cannot be achieved without a custom linker or using a JIT such as LLVM or compiling to WASM and embedding a WASM runtime into the binary I really hope Nim gets some language/compiler upgrades due to this.
  - xigoi 3y ago
    > there is not easy way to import/include a C header in Nim I prefer writing an explicit wrapper anyway. It allows me to rename symbols to a more idiomatic name.
singularity2001 3y ago
Wonderful language. Only complaints (so far) : DynamicVector should be named Array and SIMD should be named Vector and dispatched to whatever SIMD/vector pipeline the host offers, similar to the Flexible Vectors proposal in WASM: https://github.com/WebAssembly/flexible-vectors/blob/main/proposals/flexible-vectors/FlexibleVectors.md https://github.com/WebAssembly/flexible-vectors/blob/main/pr... And please make Optional[T] as ergonomic as Swift / Kotlin with a simple '?'
dom96 3y ago
Impressive. I think this has a real chance of being successful. Backwards compatibility with Python and what appears to be a strong focus on improving what makes Python frustrating to work with (let/var, no GIL, compiled) all looking promising. I'll definitely be keeping a close eye on this and look forward to getting access to the playground. Reading the docs it seems there are still some things that aren't settled and I would like to offer my feedback. From https://docs.modular.com/mojo/programming-manual.html https://docs.modular.com/mojo/programming-manual.html: > Alternative: instead of using the `&` sigil, we could call this an `inout` argument. I think you should do this. What makes Python great is its readability so don't compromise on this.
codepoet80 3y ago
Palm has entered the chat: https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk-now-available/ https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk...
raphlinus 3y ago
This looks exciting, and I'm looking forward to its progress. I have questions about GPU infrastructure in particular. It seems like the GPU backend is primarily through MLIR. Does that target CUDA? Vulkan compute shaders? WebGPU? Metal shaders? I note that IREE has the first three of those listed as targets, but am not clear on exactly where that fits in to the rest of the ecosystem. I have an idea of a dream GPU infrastructure based on compute shaders, where you compile your problem into GPU IR suitable for your operating system (SPIR-V, Metal, DXIL) and have a very lightweight runtime that just runs those. For the ahead of time compilation case, you wouldn't need to ship GPU compilers in a deployed application, though you would want that for more rapid iteration when doing research and exploratory programming. From what I can see so far, this seems basically orthogonal to what Modular and Mojo are trying to do, but it's entirely possible I'm missing something. I'm wondering if anyone is actually building this (IREE and MediaPipe are the closest things in the space I'm aware of), and if not, why not.
- boywitharupee 3y ago
  You can lift to various dialects in MLIR, for example, there is a Metal dialect, but it's not actively maintained. So, while it's possible, the question is whether Modular will add support for it.
Jarred 3y ago
This looks really good
jph00 3y ago
Hi Jeremy Howard here. I pop up in the launch video to demo super-fast matmul and mandelbrot in mojo. I'm pretty excited about this language, to say the least - not just for AI/ML, but for pretty much everything! Lemme know if you have any questions and I'll answer as best as I can. (I'm an advisor to Modulo.)
- fvncc 3y ago
  Hi is there any plan to have high level model training tools (one example is things like Pytorch dataset loaders), or is the focus more on inference/deployment use cases?
  - jph00 3y ago
    If I have anything to do with it, there will be high level model training tools. Perhaps something a little like fastai, for instance?...
    - fvncc 3y ago
      That would work nicely :)
      - chrislattner 3y ago
        I can't speak for others, but I think fast.ai is pretty great...
- skybrian 3y ago
  I'm wondering how the Python interop is implemented. When you import a Python library, is there a separate interpreter that runs the Python code?
  - jadodev 3y ago
    It looks like the Mojo compiler/runtime hooks into the CPython interpreter. > We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. Running code this way will get no benefit from Mojo, but the sheer existence and availability of this ecosystem will rapidly accelerate the bring-up of Mojo, and leverage the fact that Python is really great for high level programming already. https://docs.modular.com/mojo/why-mojo.html#how-compatible-is-mojo-with-python-really https://docs.modular.com/mojo/why-mojo.html#how-compatible-i...
ozinenko 3y ago
@chrislattner out of curiosity, can you share on which CPU the numbers in https://docs.modular.com/mojo/notebooks/Matmul.html https://docs.modular.com/mojo/notebooks/Matmul.html are obtained and/or the fraction of peak performance on that machine? Speedups over naive Python feel kind of strawman. I can see a 3500x improvement over that with practically vanilla MLIR, similar schedule, and no autotuning.
woah 3y ago
I hope this doesn't bring the terrible python dependency story
fulafel 3y ago
For related work, this also uses MLIR for neural net kernels and had some ofthe same people involved: https://www.tensorflow.org/mlir https://www.tensorflow.org/mlir / https://github.com/tensorflow/runtime https://github.com/tensorflow/runtime
programmarchy 3y ago
> No CUDA required Nvidia has a ton of lock-in with CUDA. Seems like it could shake up the GPU industry if this takes hold as a standard tool in ML. Also, I'd imagine AMD, Intel, Apple, and others will be lining up at the door to sponsor this project.
OhNoNotAgain_99 3y ago
[dead]
bob6745 3y ago
I think the future of programming and programming languages is turning pseudocode into machine language using LLMs.
mfld 3y ago
Another "Python with high-performance compiled builds" would be https://github.com/exaloop/codon https://github.com/exaloop/codon.
pankajdoharey 3y ago
How do i actually install this ? Is this a commercial compiler with no github?
FireInsight 3y ago
I don't see any reason why someone would rather use this proprietary python sibling instead of using Julia or Nim.
stephen 3y ago
Wow. Could someone do this for Typescript/JavaScript? Like the language is full interop with the existing JS ecosystem, but if I opt into certain restrictions (and run on some novel runtime), I get an insta-performance boost? Personally wonder if the Typescript team themselves could drive this short of evolution, albeit I know that lately they're very committed to being "just types" and nothing that affects runtime. Which I get.
shay_ker 3y ago
I have a very naive question. Why does Python have a GIL? Is it because of the language design, or because of its implementation? If it’s due to the language design, how will Mojo avoid a GIL, given its goal is to be a superset of Python?
- detaro 3y ago
  > Is it because of the language design, or because of its implementation? Bit of both? The language expects properties that lend themselves to having a GIL (i.e. attempts at removing it from CPython have turned out to make it slower in many cases), but it's not impossible for an implementation that does more advanced analysis to be able to figure out cases where it isn't needed. Code written to massively parallelize will want to/have to keep accesses inside the thread context anyways, and thus won't hit cases the GIL serves, and if you allow language extensions they can make that explicit where needed.
johntash 3y ago
I've only skimmed through the docs so far, and it sounds interesting, but.. > The Mojo standard library, compiler, and runtime are not available for local development yet, so we created a hosted development environment where you can try it out. We call it the Mojo Playground! Is this going to be a SaaS-style programming language, or will it be open source and local later? I'm not sure I understand why a new programming language wouldn't start off as open source, or at least able to be used locally?
fredguth 3y ago
What are the implications for Intel, Apple, NVIDIA? How much can Mojo helps leveling the competition landscape?
DataPastor 3y ago
Sounds really exciting. If you can carry out your ambitions, and avoid all the pitfalls of licensing and community building, this might be the next big thing in the field of data science. Do you have an ambitioned release date? Maybe in 2024?
stallionz53 3y ago
That video had really high production quality making it seem like Modular.com is very well funded. What is their source of funding, what’s going to be their business model?
abhimanyuaryan 3y ago
Fellow Julia user. Quite excited about Mojo. Been following Chris from his MLIR days at Swift 4 TF and his course with Jeremy on fastai. I hope we can also derive some exciting learning from Mojo :)

643 points by lairv 3y ago

Well, I'm blown away. If this succeeds, it will allow you to use Python for the entire AI stack: high-level model composition (as usual), fast compiled CPU code (instead of, say, libs written with C++), and on-device operations (instead of, say, libs that use CUDA). Oh, and it will make your Python code parallel (i.e., there's no GIL). Obviously, we'll have to wait until Mojo is production-ready, but I'm excited after seeing Jeremy Howard's easy-to-follow examples during the live keynote presentation. Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while. Props to the Mojo team!

lairv 3y ago
Exciting stuff indeed, looks like a unified approach to recent developments like (OpenAI) Triton, TVM, OpenXLA, ONNX Runtime, etc. though we'll have to wait for proper benchmarks and compatibility to know how great it is. Also it's a bit of a bummer that the compiler is behind a waitlist for now
throwaway894345 3y ago
This isn’t Python though, right? It’s just a Python-like syntax for a much lower level programming language (sort of like Cython) from my cursory glance? It seems a lot like Rust with a Pythonic veneer, so I would expect it will run into many of the same problems that Rust has (lots of difficulty pacifying the borrow checker)?
- cs702 3y ago
  The source code is Python (well, a superset of Python), but it's not interpreted and run by the official Python interpreter. Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic.
  - throwaway894345 3y ago
    Maybe someone can correct me, but I don't think it's a superset of Python--I don't think it will accept existing Python programs and I'm pretty sure you can't do all of the dynamic Python stuff (otherwise you would have to essentially compile/link an interpreter into your binaries giving you these super slow paths that aren't necessarily obvious when reading source code). > Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic. I think it "feels Pythonic" because you're looking at Pythonic syntax. I suspect when you're banging your head against a borrow checker it will feel more like writing Rust. Like I'm pretty sure anything with a borrow checker will have to deal with lifetimes, mutable-vs-immutable references, shared mutability (cell/refcell in rust), etc; I don't know how you "Pythonify" that in any meaningful way?
    - bjornasm 3y ago
      >We utilize CPython to run all existing Python3 code “out of the box” without modification >Further, we decided that the right long-term goal for Mojo is to provide a superset of Python
      - asqueella 3y ago
        The FAQ states that “Mojo is still early and not yet a Python superset, so only simple programs can be brought over as-is with no code changes.” I have no idea how to reconcile that with the quotes you provided. [edit] Ah, it seems you can control things running in a bundled CPython: plt = Python.import_module("matplotlib.pyplot") fig = plt.figure(1, [width, height], dpi) ax = fig.add_axes([0.0, 0.0, 1.0, 1.0], False, 1), "hsv", 0, 0, 1.5) ... plt.imshow(image)
otoburb 3y ago
>>If this succeeds, it will allow you to use Python for the entire AI stack [...] If this succeeds, the terminal endpoint will be the Python Software Foundation adopting Modular as the defacto and eventually official implementation since, as Modular noted in their docs, they effectively need Mojo to be absolutely amazing on generalized host CPUs as the key enabler allowing for the unified Python-superset experience across other types of general and specialized hardware ("xPU"). Julia will be dealt an adoption setback proportional to Mojo's growing success.
- ipsum2 3y ago
  No it won't. The language is not a super-set of Python, its another language that somewhat resembles Python. You can't drop in some Python code and run it with Mojo and expect it to work.
  - jadodev 3y ago
    The goal is for the language to be a superset of Python > Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (i.e. be compatible with existing programs) and to embrace the CPython immediately for long-tail ecosystem enablement. https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html
    - azakai 3y ago
      But see the section "Intentional differences from Python", which is after your quote, https://docs.modular.com/mojo/why-mojo.html#intentional-differences-from-python https://docs.modular.com/mojo/why-mojo.html#intentional-diff... > our approach to compatibility is two fold: > 1. We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. > 2. We will provide a mechanical migrator that provides very good compatibility for people who want to move Python code to Mojo. > Together, this allows Mojo to integrate well in a mostly-CPython world, but allows Mojo programmers to be able to progressively move code (a module or file at a time) to Mojo. This approach was used and proved by the Objective-C to Swift migration that Apple performed. Maybe the long-term goal is to try to make it a true superset, but it sounds like the detailed plan is more practical, to basically provide a "Python-next" language, like Swift for Objective-C.
jph00 3y ago
> Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while Oh yes!
- cs702 3y ago
  :-)
- fredguth 3y ago
  I can’t wait to see fast.ai-next in mojo :-)

PartiallyTyped 3y ago

NB: sign-up with email required to "get started".

rvz 3y ago

A magnificent game changing project once again by the creator(s) of LLVM. I think this time they might have a proper Python alternative. Many have tried like Julia Lang, R, C#, Swift, Rust, Haskell, etc and all have failed in competing against Python. Perhaps this time, we finally have one that is a proper replacement for anything requiring intensive compute and performance without being a systems programmer, all thanks to the finest compiler engineers who brought you LLVM, MLIR and now Mojo. (Not the AI hype squad sitting on O̶p̶e̶n̶AI.com's APIs.) If you know Python you have learned 90% of Mojo. Just waiting to see if it can compile to a binary.

verdverm 3y ago
Will I be able to use all of the existing libraries from Python? If not, it's going to be hard to make the switch
- chrislattner 3y ago
  Yep, they already just work, Check the website or the demo in the launch video from Jeremy Howard. Also potentially interesting: https://docs.modular.com/mojo/programming-manual.html#python-integration https://docs.modular.com/mojo/programming-manual.html#python... https://docs.modular.com/mojo/notebooks/Mandelbrot.html https://docs.modular.com/mojo/notebooks/Mandelbrot.html
  - JonChesterfield 3y ago
    If that works with any libraries built on the CPython C API it would be worth calling it out in the docs - it currently reads like pure python or numpy work, but I assumed that was because you'd reimplemented numpy, not managed to dlopen it (and worked around those libraries relying on the GIL).
    - JonChesterfield 3y ago
      Found said part of the docs at https://docs.modular.com/mojo/why-mojo.html#how-compatible-is-mojo-with-python-really https://docs.modular.com/mojo/why-mojo.html#how-compatible-i... notably > We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem

chubot 3y ago

Seems like it could be interesting ... Initial impression is that the animation of Mojo code vs. Python code has a bad UX. Why not just show the code side-by-side instead of animating it and making me click? Another obvious question is how is it different than Numba and so forth? https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html The Mojo language has lofty goals - we want full compatibility with the Python ecosystem, we would like predictable low-level performance and low-level control, and we need the ability to deploy subsets of code to accelerators. We also don’t want ecosystem fragmentation - we hope that people find our work to be useful over time, and don’t want something like the Python 2 => Python 3 migration to happen again. These are no small goals! and Mojo already supports many core features of Python including async/await, error handling, variadics, etc, but… it is still very early and missing many features - so today it isn’t very compatible. Mojo doesn’t even support classes yet! So I think the idea is good, but yeah re-implementing Python is a huge effort ! Though the comparison right below is notable: A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community

ChrisRackauckas 3y ago
> A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way. The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances. That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about (https://www.youtube.com/watch?v=VdD0nHbcyk4 https://www.youtube.com/watch?v=VdD0nHbcyk4). What I would find worrisome too is that this approach sounds like compile time city. A lot of the recent advancements in Julia have been by sending less to LLVM: optimizations are done in Julia and dead code is eliminated, calls are found to be the same and check caches, and then with v1.9 those caches use precompiled binaries to avoid having to call LLVM again. And the timeline of improvements shows that making LLVM be in the picture as little as possible has lead to some dramatic improvements in Julia's latency (https://viralinstruction.com/posts/latency/ https://viralinstruction.com/posts/latency/). Given what was seen from that, I'm weary of an approach that does everything in LLVM (via MLIR) on an even more dynamic representation (i.e. Python). My guess is that only things with explicit types will compile, and the rest is probably hitting some Python interpreter to avoid this issue. [If part is using Python/GC through an interpreter though, wouldn't that part be harder to target to accelerators since it wouldn't compile through LLVM? That would mean only the code that is explicitly typed gets the nice new features, but not the Python parts?] But hey, if this gets Chris Lattner and crew a reason to start taking LLVM compile times more seriously, then it's a win for Julia as well. I'm excited to see how the communities can benefit from one another, especially if Mojo is open source then it can be a win for all (which was definitely not clear in the presentation). And I do think that some of the ideas of lower level memory control are cool and should be added similarly to languages like Julia and Numba.

kerinin 3y ago

Interesting to see some of Rust's ideas start to spread. I never thought borrow checking would become popular ;)

cube2222 3y ago

This looks quite interesting with big names behind it. I'd love to see a comparison vs Julia though, which I think tried to tackle some of the same problems.

UncleOxidant 3y ago
Yeah, it seems like they sort of reinvented Julia but with more of a Python syntax?
cube2222 3y ago
> we want full compatibility with the Python ecosystem Oh, I guess that's one big philosophical difference.
TheMagicHorsey 3y ago
I was thinking about Julia too. I guess they will try to make it reasonably compatible with Python directly making rewrites easier than Julia? Edit: just saw this is a project by Chris Latner and Tim Davis. Hahaha ... that's immediate credibility.
- UncleOxidant 3y ago
  but Mojo seems to keep all of that numpy cruft that's there because Python. (numeric computing was bolted onto python via numpy, but it's built-into Julia)
- borodi 3y ago
  I'm sure there are reasons for it, but Chris Lattner has been jumping around a bit. Remember swift4TF. But hopefully this one is seen through with lots of open source too.
staticfloat 3y ago
It is a little disappointing that they're setting the bar against vanilla Python in their comparisons. While I'm sure they have put massive engineering effort into their ML compiler, the demos they showed of matmul are not that impressive in an absolute sense; with the analogous Julia code, making use of [LoopVectorization.jl](https://github.com/JuliaSIMD/LoopVectorization.jl https://github.com/JuliaSIMD/LoopVectorization.jl) to automatically choose good defaults for vectorization, etc... julia> using LoopVectorization, BenchmarkTools, Test function AmulB!(C,A,B) @turbo for n = indices((C,B),2), m = indices((C,A),1) Cmn = zero(eltype(C)) for k = indices((A,B),(2,1)) Cmn += A[m,k]*B[k,n] end C[m,n]=Cmn end end M = K = N = 144; A = rand(Float32, M,K); B = rand(Float32, K,N); C0 = A*B; C1 = similar(C0); AmulB!(C1,A,B) @test C1 ≈ C0 2e-9*M*K\*N/@belapsed(AmulB!($C1,$A,$B)) 96.12825754527164 I'm able to achieve 96GFLOPs on a single core (Apple M1) or 103 GFLOPs on a single core (AMD EPYC 7502). And that's not even as good as what you can achieve using e.g. TVM to do the scheduling exploration that Mojo purports to do. Perhaps they have more extensive examples coming that showcase the capabilities further. I understand it's difficult to show all strengths of the entire system in a short demonstration video. :) EDIT: As expected, there are significantly better benchmarks shown at https://www.modular.com/blog/the-worlds-fastest-unified-matrix-multiplication https://www.modular.com/blog/the-worlds-fastest-unified-matr... so perhaps this whole discussion truly is just a matter of the demo not showcasing the true power of the system. Hopefully achieving those high performance numbers for sgemm is doable without too much ugly code.

UncleOxidant 3y ago

So... did they reinvent Julia? (but with more of a python syntax)

deleted 3y ago

[deleted]

alberth 3y ago

So is this actually Python or not? I’m a bit confused.

abc_lisper 3y ago
This is like C++ to C - so python++, ++ is for features and native compilation
bufo 3y ago
It's a superset of Python. What you call "Python" is actually CPython, a C implementation of the Python language. Many other Python implementations exist, though they typically don't support all packages well (for example lack of support of native Python extensions like what Numpy relies on). It looks like Mojo has its own runtime (so not CPython) but also packages CPython for compatibility?
- ipsum2 3y ago
  Wrong, Mojo is not a runtime for Python.

tgma 3y ago

Swift already imported Python code in a similar fashion. Feels like this is a more Pythonic syntax for Swift and likely carries over all the underlying goodness. [FWIW, folks waiting for this should also look at Cython, which is different, but uses Pythonic syntax for more of a C-like semantics.]

liuliu 3y ago
Swift doesn't do a good job of interleaving with Python (i.e. allowing Python to call into Swift, while possible, is nothing like Numba due to various object type translation required). Mojo seems to be targeting Mojo -> Python -> Mojo too (i.e. Mojo can do high level control flow, delegate some more control flow / unsupported ops to Python, then implement some accelerator supports that Python will call back to). This can be quite difficult if you want to have very low bridging cost (Python objects are quite large and different libraries, such as Python / numpy have different representations in C on top of these Python objects). It is all possible (after all, we are doing computer stuff), but it is a quite difficult path comparing to other success interop stories (Swift / ObjC took a decade to achieve somewhat low bridging cost, Kotlin / Java simply gives up and doing everything in JVM).

chrislattner 3y ago

There are a bunch of questions about Julia, so I'll do my best to give a short answer to a very long and complicated topic. Up front, Julia is a wonderful language and a wonderful community, I am a super fan. That said, Mojo is a completely different thing. It is aligned with the Python community to solve specific problems outlined here: https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html Mojo also has a bunch of technical advancements compared to Julia by virtue of it being a much newer development and being able to learn from it (and Swift and Rust, and C++ and many many other languages). Including things like ownership and no GC. We also think there is room for a new language that is easier to deploy, scales down to small envelopes, works directly with the full Python ecosystem, is designed for ML and for MLIR from first principles, etc. Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) EDIT: Just in case there is any confusion, I work for Modular, built LLVM, Swift, Clang, MLIR and a variety of other things. I wasn't trying to misrepresent as being unaffiliated.

travisoliphant 3y ago
Congratulations on the launch and work so far! This is indeed very interesting. I believe a language like this is necessary for future progress. I have also been impressed with Julia and its progress. I would have liked to see more progress on Ahead of Time compilation and using it to write Python extension modules. For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers. We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate. Understanding what will be open-source is of course, critical for that.
UncleOxidant 3y ago
I notice that Mojo still seems to use numpy or something that looks "numpyish" for compatibility. Will Mojo also have an alternative syntax for doing things like matrix multiplication that looks more native like Julia's?

drivingmenuts 3y ago

Somewhere out there, a recruiter is gearing up to demand 5 years experience with Mojo before they will look at your resume.

pknerd 3y ago
I already added "Mojo Evangelism is my mojo" in my LinkedIn Title.
- Archit3ch 3y ago
  Dibs on Mojo Dojo (mojodojo.com), your new premier training resource for Mojo.
  - Apocryphon 3y ago
    I wonder if GoJo (Lukas Matsson‘s app) is built with Mojo
  - mkaic 3y ago
    Mojo Dojo was briefly the name of a trampoline park in Sacramento before it got bought out by SkyZone
kps 3y ago
Hey, I've used https://source.chromium.org/chromium/chromium/src/+/main:mojo/ https://source.chromium.org/chromium/chromium/src/+/main:moj... (tl;dr Chromium's IPC) which is enough to pass the recruiter screening. (And, uh, just applied to this Mojo because I'd love to get back to language compiler work.)

l2dy 3y ago

A file extension of [fire emoji], this is not easy to type from a terminal. Edit: It's even stripped on HN!

lairv 3y ago
Read on their discord server that it both support .mojo and the fire emoji
- newswasboring 3y ago
  The fire emoji as file extension makes me feel very uncomfortable. Am I old now? (I know I don't have to use it, but I usually work in big projects with lots of other people's code).
kps 3y ago
echo $'<Multi_key> <m> <o> <j> <o> : "\U1F525" U1F525 # FIRE' >>~/.XCompose I'm not personally a fan of emoji, but I do like using and typing more than plain ASCII in the terminal. (One thing I liked about Julia is their partial embrace of Unicode, and one thing I don't is that you can't write lambdas with ‘↦’.)

calebm 3y ago

Python Interoperability seems like a killer feature.

otabdeveloper4 3y ago

Sorry, I can't apply this to my use case until it gets a blockchain plugin.

mindcrime 3y ago

Will Mojo be OSS? Or is this strictly proprietary?

chrislattner 3y ago
Open source over time as it matures: https://twitter.com/Modular_AI/status/1653439606522802176?s=20 https://twitter.com/Modular_AI/status/1653439606522802176?s=...

dunefox 3y ago

I wish new languages would move away from python syntax and semantics and just do their own thing more.

dom96 3y ago
I wish more would take inspiration from Python syntax.

tikkun 3y ago

Fascinating. The AI industry is currently beholden to Nvidia, in part because of CUDA's superiority over ROCm. Therefore there's a big need for projects like this. See also: https://openai.com/research/triton https://openai.com/research/triton

minhazm 3y ago

Is this closed source? I just assumed that a new programming language would be open source but I don't see any links to GitHub or any other place. The getting started page also requires you to put in your name and contact information.

ModernMech 3y ago
This is exactly what I was trying to figure out. It seems like the answer is no at this time.
- lairv 3y ago
  From their FAQ https://docs.modular.com/mojo/faq.html https://docs.modular.com/mojo/faq.html "Will Mojo be open-sourced? Yes, we expect that Mojo will be open-sourced. However, Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out. We don’t have an established plan yet. Why not develop Mojo in the open from the beginning? Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.)."
  - theLiminator 3y ago
    Their response to why it's faster to move while closed source seems kinda like a false dichotomy. They can choose to start with it open disallow input from the community or close their issue tracker to the community.
    - vosper 3y ago
      Why bother doing it that way? Just to entertain people who works like to observe the commit history as the language evolves?
      - 3y ago

deleted 3y ago

[deleted]

alberth 3y ago

The parallelism of Mojo would make it an interesting language for a web framework.

ConanRus 3y ago

[dead]

Sukera 3y ago

Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that only parts of python will actually be supported for full acceleration? At least your docs[1] seem to say so.. -- [1]: https://docs.modular.com/mojo/why-mojo.html#intentional-differences-from-python https://docs.modular.com/mojo/why-mojo.html#intentional-diff...

throwawaymaths 3y ago
Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependencies. Venv/conda which do sneaky things e.g. with your shell is super dangerous (https://twitter.com/garybernhardt/status/1653171980483575808 https://twitter.com/garybernhardt/status/1653171980483575808), and a misstep can trash your system especially when it has to deal with wheels with system-level dependencies (looking at you, tensorflow -- probably half of the reason why people moved to pytorch). Poetry sounds nice. It's been a while since I've checked in with the python ecosystem. Are ML people using that yet? - Subpar deployment. Let's remember that Containerization basically exists because Python does not have an ops story. - Subpar integration with web. You are forced to either create a microservice, or, spin it up within Django (nobody really does this). Then you typically have to pull in a bunch of sidecar processes (Redis, Celery, etc.) just to get queuing of your web jobs correct. - Poor concurrency. Sure, you can run your tensorflow code in an awkward 'with' statement but I think there are very few ML practicioners who could really explain to you what that with is doing. That GPU is actually fundamentally an asynchronous entity. And god help you if you want to run and debug async python. - No distribution story. Sure, the big guys are able to spin up, e.g. Horovod, but it's not really a thing for someone with less resources for a hot second on a few machines, and again, god help you if something goes wrong and you need to debug it. Does Mojo solve any of these issues? From a cursory look, it looks like no.
- 3y ago

helen___keller 3y ago

Was very pleased to see that for meta programming, they went with something similar to Zigs comptime

JonChesterfield 3y ago

Reached end of docs. I'm sold. - Compile time language is ~ the runtime one. That's the model most systems languages seem to have ended up at. It doesn't have macros or reflection, but neither of those seem to be very popular - The struct/let notation and lifetime model essentially give you C++ semantics with saner syntax. The class/def notation essentially give you python semantics. This is a clean answer to the gradual-typing-for-performance problem - You can drop into MLIR at will and the std types are implemented like that. This makes the language look a lot like syntactic sugar over writing the IR which closely matches how (at least some) compiler devs think about programming languages Yeah, I think that'll work. Python/C++ mashup is a popular dev stack and this can make that much cleaner. Faster than C is rather unproven but given the difference in compile time control should be achievable.

kashif 3y ago
Have a good look at Nim

deleted 3y ago

[deleted]

silisili 3y ago

Is this usable as a general purpose language, or is it too tailored to AI/ML tasks and thus missing a lot of 'general' libraries and such? How does performance compare to Python in the general case, when not dropping into tricks? Either way, kudos, exciting stuff, just questions I had after reading about it.

drBonkers 3y ago
I'm also curious. Modular seems to be what Chris wanted with Swift, but couldn't because of Apple's thumb.
JonChesterfield 3y ago
Looks great for writing compilers in to me. Doesn't need much in the way of external libs, really well positioned to build parts of MLIR using it.
tomhallett 3y ago
Yeah, obviously curious if a fastapi port could be written in mojo
gazpacho 3y ago
I would like to know this as well. Not just “can you write general purpose programs” but is that one of the fundamental design goals. For example, in my personal opinion Julia does not meet the bar. One of Python’s powerful features outside of being a great glue language for AI is rich runtime reflection and introspection. This is what allows things like FastAPI/Pydantic to work. Will Mojo support this level of runtime introspection? I’m also curious about the type system. Will it be Python level or TypeScript level?

version_five 3y ago

The website is unusable for me (brave on android). I can't really scroll. Am I the only having this problem?

earthboundkid 3y ago

One of the biggest problems with Python is packaging, and one of the biggest problems with Python packaging is installing scientific computing modules that rely on C/C++/Fortran. Will Mojo attempt to address these problems?

IceHegel 3y ago
Yes this must be fixed. Python packaging is such a nightmare I use a fresh docker image for every project, which is much easier than messing with pyenvs, conda, broken wheels and that whole mess.

tabtab 3y ago

Is there a sample or tutorial that jumps right into typical examples of what's different or special about it? I tried to find such, but the docs get lost in syntax details and other minutia. I want the ADHD-meat-and-potatoes tutorial. Maybe that's asking too much, but I did it anyhow, as any ADHDer would.

ModernMech 3y ago
> I want the ADHD-meat-and-potatoes tutorial. What does this mean?
- tabtab 3y ago
  "Gimme gimme gimme!"

kraihx 3y ago

Not to be confused with the now more than a decade old web framework for Perl, and most popular module on CPAN: https://metacpan.org/pod/Mojo https://metacpan.org/pod/Mojo Or it's port to TypeScript: https://mojojs.org https://mojojs.org

ubj 3y ago

Looks really interesting! A couple questions: * Will Mojo be able to generate portable, standalone binaries and libraries? * If so, will the size of the binaries / libraries be similar to C / Rust binary sizes? These are pretty big pain points for both JAX and Julia (Julia is slowly making progress on this front though)

sytse 3y ago

Very cool development. There is too much busy work going from development to test to production. This will help to unify everything. OpenAI Triton https://github.com/openai/triton/ https://github.com/openai/triton/ is going for a similar goal. But this is a more fundamental approach.

vsskanth 3y ago

Can this produce a static AOT compiled binary ? This seems to be currently one of the biggest limitations to Julia (and even Python) in terms of distribution, especially in the embedded space. PackageCompiler.jl helps, but binaries are still huge

ModernMech 3y ago
How big are the binaries? (what I mean is, are they 1MB, or 100MB, or worse?)
- ubj 3y ago
  Over 150 MB for "Hello world" [1][2]. There are a few options for going smaller (e.g. StaticCompiler.jl), but they're not very mature yet. [1]: https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hello_world_application/ https://www.reddit.com/r/Julia/comments/ytegfk/size_of_a_hel... [2]: https://discourse.julialang.org/t/standalone-hello-world-executable-size-comparison-to-node-js/97656 https://discourse.julialang.org/t/standalone-hello-world-exe...
- adgjlsfhk1 3y ago
  Julia's binaries are currently 50mb to 1gb depending on what you put in them. The large floor comes from the fact that you have to ship LLVM which is around 50 MB by itself. (the 1gb binaries are if you include a couple thousand packages in the binary also).

ricopags 3y ago

Congratulations on the launch preview! This is exciting, as I've been waiting for this announcement since Jim Keller's callout on Lex Fridman podcast two years ago[0]. I'm curious about the teasing around open source. Obviously the amount of money and the slick product launch dictate a need to capitalize on this pooled expertise. Don't want to give away the game to the hyperscalers. I wonder what the revenue and license models are going to end up looking like. A cloud of their own, professional services to HW manufacturers to optimize their performance, professional services to hyperscalers? Curious if anybody has any ideas beyond the obvious. [0]https://youtu.be/G4hL5Om4IJ4?t=4048 https://youtu.be/G4hL5Om4IJ4?t=4048

throwaway12223 3y ago

what about pointers?

chrislattner 3y ago
What's the question? They are sharp and pointy and Mojo has an unsafe `Pointer` struct vended by the standard library for folks who know what the they are doing.

fleur-de-lotus 3y ago

Could you consider choosing another name for the language? mojo doesn't sound sexy. Ask for suggestions.

nojonestownpls 3y ago

This is the final nail in the coffin for "Julia as a replacement for Python" in my eyes. Maybe I'm very late to that conclusion, maybe the writing's been on the wall for a while, but I still held out hope that Julia could be at least a parallel peer to Python sharing the market. But now, it seems almost certain that Julia will end up a possible replacement-for-Matlab niche language, unknown and unused by most outside the niche. It's a pretty big and important niche, to be sure, but a bit disappointing given how nice the language is.

nologic01 3y ago
Predicting language ecosystem development is difficult, especially if its about the future. It does feel that Julia may have missed its window of opportunity. But maybe not. On the one hand Python's mindshare has been growing exponentially, riding on successive waves of data science, machine learning, deep learning, AI and now AGI hypes. NB: The two hypes it did not benefit from (for obvious reasons) are big data and crypto/blockchain. Given, though, Python's heavy historical baggage, you could think that eventually gravity would re-assert itself - with a potential crash landing. So in a sense, if the mojo project succeeds becoming a very broad based renewal effort (a Python 4 thing) that fixes some of Python's limitations, it will lock-in Python's current amazing popularity. If not, then the field is still open for a challenger and Julia could well be that. The broader technology space feels very febrile right now. Lots of talk, much less walk. The winners will be simply those who deliver tangible "next-gen" experiences to developers and end-users.
pjmlp 3y ago
Julia is doing alright, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
- freilanzer 3y ago
  Alright most likely isn't going to cut it when Python gets even more entrenched.
  - pjmlp 3y ago

InitEnabler 3y ago

Wonder how this compares to Nim.

AbuAssar 3y ago

Chris Lattner of LLVM and Swift fame is behind mojo

gok 3y ago

Finally, the package management ecosystem of Python with the compiler speed and error messages of Rust and Swift.

rg111 3y ago

I would have started using it today for my personal projects and write tutorials if it were FOSS. It looks sooo good. Once it turns into FOSS (if it does), I will start using it as quickly as I can. Then, if and when it gets more mature, and delivers on its promises, I might start using it at my work.

drBonkers 3y ago

Why would I use this over Nim?

pineapple_sauce 3y ago
From what I can tell: 1. They have a REPL and Jupyter integration 2. They're planning to do C and C++ interop. This is achievable in Nim but it is a pain, i.e. there is not easy way to import/include a C header in Nim, e.g. nothing as straight-forward as @cImport("cheader.h") in Zig or #include "cheader.h" in C++; one must go through c2nim or a third-party library (1) cannot be achieved without a custom linker or using a JIT such as LLVM or compiling to WASM and embedding a WASM runtime into the binary I really hope Nim gets some language/compiler upgrades due to this.
- xigoi 3y ago
  > there is not easy way to import/include a C header in Nim I prefer writing an explicit wrapper anyway. It allows me to rename symbols to a more idiomatic name.

singularity2001 3y ago

Wonderful language. Only complaints (so far) : DynamicVector should be named Array and SIMD should be named Vector and dispatched to whatever SIMD/vector pipeline the host offers, similar to the Flexible Vectors proposal in WASM: https://github.com/WebAssembly/flexible-vectors/blob/main/proposals/flexible-vectors/FlexibleVectors.md https://github.com/WebAssembly/flexible-vectors/blob/main/pr... And please make Optional[T] as ergonomic as Swift / Kotlin with a simple '?'

dom96 3y ago

Impressive. I think this has a real chance of being successful. Backwards compatibility with Python and what appears to be a strong focus on improving what makes Python frustrating to work with (let/var, no GIL, compiled) all looking promising. I'll definitely be keeping a close eye on this and look forward to getting access to the playground. Reading the docs it seems there are still some things that aren't settled and I would like to offer my feedback. From https://docs.modular.com/mojo/programming-manual.html https://docs.modular.com/mojo/programming-manual.html: > Alternative: instead of using the `&` sigil, we could call this an `inout` argument. I think you should do this. What makes Python great is its readability so don't compromise on this.

codepoet80 3y ago

Palm has entered the chat: https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk-now-available/ https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk...

raphlinus 3y ago

This looks exciting, and I'm looking forward to its progress. I have questions about GPU infrastructure in particular. It seems like the GPU backend is primarily through MLIR. Does that target CUDA? Vulkan compute shaders? WebGPU? Metal shaders? I note that IREE has the first three of those listed as targets, but am not clear on exactly where that fits in to the rest of the ecosystem. I have an idea of a dream GPU infrastructure based on compute shaders, where you compile your problem into GPU IR suitable for your operating system (SPIR-V, Metal, DXIL) and have a very lightweight runtime that just runs those. For the ahead of time compilation case, you wouldn't need to ship GPU compilers in a deployed application, though you would want that for more rapid iteration when doing research and exploratory programming. From what I can see so far, this seems basically orthogonal to what Modular and Mojo are trying to do, but it's entirely possible I'm missing something. I'm wondering if anyone is actually building this (IREE and MediaPipe are the closest things in the space I'm aware of), and if not, why not.

boywitharupee 3y ago
You can lift to various dialects in MLIR, for example, there is a Metal dialect, but it's not actively maintained. So, while it's possible, the question is whether Modular will add support for it.

Jarred 3y ago

This looks really good

jph00 3y ago

Hi Jeremy Howard here. I pop up in the launch video to demo super-fast matmul and mandelbrot in mojo. I'm pretty excited about this language, to say the least - not just for AI/ML, but for pretty much everything! Lemme know if you have any questions and I'll answer as best as I can. (I'm an advisor to Modulo.)

fvncc 3y ago
Hi is there any plan to have high level model training tools (one example is things like Pytorch dataset loaders), or is the focus more on inference/deployment use cases?
- jph00 3y ago
  If I have anything to do with it, there will be high level model training tools. Perhaps something a little like fastai, for instance?...
  - fvncc 3y ago
    That would work nicely :)
    - chrislattner 3y ago
      I can't speak for others, but I think fast.ai is pretty great...
skybrian 3y ago
I'm wondering how the Python interop is implemented. When you import a Python library, is there a separate interpreter that runs the Python code?
- jadodev 3y ago
  It looks like the Mojo compiler/runtime hooks into the CPython interpreter. > We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. Running code this way will get no benefit from Mojo, but the sheer existence and availability of this ecosystem will rapidly accelerate the bring-up of Mojo, and leverage the fact that Python is really great for high level programming already. https://docs.modular.com/mojo/why-mojo.html#how-compatible-is-mojo-with-python-really https://docs.modular.com/mojo/why-mojo.html#how-compatible-i...

ozinenko 3y ago

@chrislattner out of curiosity, can you share on which CPU the numbers in https://docs.modular.com/mojo/notebooks/Matmul.html https://docs.modular.com/mojo/notebooks/Matmul.html are obtained and/or the fraction of peak performance on that machine? Speedups over naive Python feel kind of strawman. I can see a 3500x improvement over that with practically vanilla MLIR, similar schedule, and no autotuning.

woah 3y ago

I hope this doesn't bring the terrible python dependency story

fulafel 3y ago

For related work, this also uses MLIR for neural net kernels and had some ofthe same people involved: https://www.tensorflow.org/mlir https://www.tensorflow.org/mlir / https://github.com/tensorflow/runtime https://github.com/tensorflow/runtime

programmarchy 3y ago

> No CUDA required Nvidia has a ton of lock-in with CUDA. Seems like it could shake up the GPU industry if this takes hold as a standard tool in ML. Also, I'd imagine AMD, Intel, Apple, and others will be lining up at the door to sponsor this project.

OhNoNotAgain_99 3y ago

[dead]

bob6745 3y ago

I think the future of programming and programming languages is turning pseudocode into machine language using LLMs.

mfld 3y ago

Another "Python with high-performance compiled builds" would be https://github.com/exaloop/codon https://github.com/exaloop/codon.

pankajdoharey 3y ago

How do i actually install this ? Is this a commercial compiler with no github?

FireInsight 3y ago

I don't see any reason why someone would rather use this proprietary python sibling instead of using Julia or Nim.

stephen 3y ago

Wow. Could someone do this for Typescript/JavaScript? Like the language is full interop with the existing JS ecosystem, but if I opt into certain restrictions (and run on some novel runtime), I get an insta-performance boost? Personally wonder if the Typescript team themselves could drive this short of evolution, albeit I know that lately they're very committed to being "just types" and nothing that affects runtime. Which I get.

shay_ker 3y ago

I have a very naive question. Why does Python have a GIL? Is it because of the language design, or because of its implementation? If it’s due to the language design, how will Mojo avoid a GIL, given its goal is to be a superset of Python?

detaro 3y ago
> Is it because of the language design, or because of its implementation? Bit of both? The language expects properties that lend themselves to having a GIL (i.e. attempts at removing it from CPython have turned out to make it slower in many cases), but it's not impossible for an implementation that does more advanced analysis to be able to figure out cases where it isn't needed. Code written to massively parallelize will want to/have to keep accesses inside the thread context anyways, and thus won't hit cases the GIL serves, and if you allow language extensions they can make that explicit where needed.

johntash 3y ago

I've only skimmed through the docs so far, and it sounds interesting, but.. > The Mojo standard library, compiler, and runtime are not available for local development yet, so we created a hosted development environment where you can try it out. We call it the Mojo Playground! Is this going to be a SaaS-style programming language, or will it be open source and local later? I'm not sure I understand why a new programming language wouldn't start off as open source, or at least able to be used locally?

fredguth 3y ago

What are the implications for Intel, Apple, NVIDIA? How much can Mojo helps leveling the competition landscape?

DataPastor 3y ago

Sounds really exciting. If you can carry out your ambitions, and avoid all the pitfalls of licensing and community building, this might be the next big thing in the field of data science. Do you have an ambitioned release date? Maybe in 2024?

stallionz53 3y ago

That video had really high production quality making it seem like Modular.com is very well funded. What is their source of funding, what’s going to be their business model?

abhimanyuaryan 3y ago

Fellow Julia user. Quite excited about Mojo. Been following Chris from his MLIR days at Swift 4 TF and his course with Jeremy on fastai. I hope we can also derive some exciting learning from Mojo :)