[HN Gopher] Mojo - a new programming language for AI developers
___________________________________________________________________
Mojo - a new programming language for AI developers
Author : lairv
Score : 330 points
Date : 2023-05-02 16:45 UTC (6 hours ago)
(HTM) web link (www.modular.com)
(TXT) w3m dump (www.modular.com)
| otabdeveloper4 wrote:
| Sorry, I can't apply this to my use case until it gets a
| blockchain plugin.
| alberth wrote:
| The parallelism of Mojo would make it an interesting language for
| a web framework.
| ricopags wrote:
| 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
| PartiallyTyped wrote:
| NB: sign-up with email required to "get started".
| chrislattner wrote:
| 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
|
| 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.
| mirekrusin wrote:
| Do you have an idea on monetizing it or not yet?
| intalentive wrote:
| >Python has amazing strengths as a glue layer, and low-level
| bindings to C and C++ allow building libraries in C, C++ and
| many other languages with better performance characteristics.
| This is what has enabled things like numpy, TensorFlow and
| PyTorch and a vast number of other libraries in the ecosystem.
| Unfortunately, while this approach is an effective way to
| building high performance Python libraries, its approach comes
| with a cost: building these hybrid libraries is very
| complicated, requiring low-level understanding of the internals
| of cpython, requires knowledge of C/C++/... programming...
|
| But the cost has already been paid. We have NumPy, we have
| PyTorch and TensorFlow. So I don't see the value-add here.
| Maybe there's something I'm missing.
| bjornasm wrote:
| I believe they are thinking about the cost of building the
| next NumPy/PyTorch/TensorFlow.
| earthboundkid wrote:
| Are you still doing any work with Swift and ML, or not anymore?
| longemen3000 wrote:
| i don't think so
| KenoFischer wrote:
| Congratulations on the launch! I think it's always a great
| thing to have people who know what they're doing put a new
| design out there. Raises the bar for everyone. For example, I
| think the Rust folks' work on error messages has really raised
| the bar on what is expected of systems is that regard.
| Sometimes people working on older systems feel a bit
| uncomfortable they see the bar being raised on them (it's weird
| to me to think of Julia as on "older" system, but I guess being
| around for more than a decade counts), but I actually prefer to
| think about it in the opposite way. There are lots of forces in
| systems design that push production systems towards
| conservatism. "We now have a million users, is it really worth
| spending the time/effort/risk on this new experimental
| parser/optimizer/feature, etc?", but if the rest of the world
| raises the bar, it's a great incentive to keep up and make all
| our systems better. So I very sincerely wish you the best of
| luck here and that in the areas where there might end up being
| overlap between Julia and Mojo people will start complaining to
| us that we need to be better, because we might just take them
| up on it ;).
| chrislattner wrote:
| Thank you Keno!
| UncleOxidant wrote:
| 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?
| chrislattner wrote:
| Mojo fully supports arbitrary library designed types, check
| out the note books for examples that define custom matrix
| operations of various types.
| byt143 wrote:
| How does mojo handle function polymorphism and abstraction?
| Julia uses multiple dispatch, Haskell type classes etc
|
| Edit: I see you're going to have protocols/ traits. Can
| those be specializes/monomoprhized at function call time
| like Julia abstract types?
|
| And how about function specialization? Will functions be
| attached to structs in a single dispatch fashion or free
| floating multimethods?
| pama wrote:
| Congrats on the launch! In addition to the dramatic
| possibilities for ML, I hope mojo will have an impact in other
| scientific software through the ease of specialization to
| hardware capabilities. The current common subset of Python and
| "pure" mojo (ie not using CPython) is small, but will expand
| according to your roadmap. Do you envision porting pure Python
| libraries as part of the effort, or perhaps help other
| communities do so? For example einsum in numpy or pytorch are
| great, but how much more work would be needed to have a mojo-
| accelerated einsum interfacing with numpy or mojo-specialized
| arrays? Or have a pure mojo numpy altogether?
| funks_ wrote:
| Are there any plans for native autodiff systems in Mojo?
| mirekrusin wrote:
| Hold on, are you behind it? ...looks like it!
|
| This "detail" shouldn't be hidden away, it means a lot.
| mattnewton wrote:
| As a former apple eng I guess I forgot that some people don't
| know who Chris Lattner is haha. There isn't anything
| unscrupulous going on here he probably just thought posting
| under his username was enough of disclaimer.
| EGreg wrote:
| How does it look like it?
| mirekrusin wrote:
| From "Team"'s link [0]
|
| [0] https://www.modular.com/team
| UncleOxidant wrote:
| > 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! :)
|
| In general this tends to be true. However, in this case I'm not
| so sure. Modular seems to have garnered a lot of investment -
| probably orders of magnitude more than the Julia community has
| been able to get. There are a lot of nagging problems in Julia
| (startup times - though that's gotten better recently, ML
| kernel performance, and executables come to mind) that could
| have been easily fixed if they had the money to throw at them.
| Since they haven't had that kind of investment people who kick
| Julia's tires tend to see these things as built-in limitations
| and move on.
| moelf wrote:
| This is too real and any of the great investment of manpower
| (e.g. Tensorflow for Swift) if happened to Julia would
| probably be 10x or 100x in terms of ROI -- just look at how
| few devs and line of code Julia's alternative to
| pandas/numpy/ML/autodidf/plotting has. If Julia ecosystem can
| be somewhat competitive while only having part time and
| researchers' side project contributors, it WILL thrive if
| properly invested.
| bllguo wrote:
| people used to talk about R vs Python for data science many
| years ago, for instance, and we all know how that ended. imo
| if Mojo lives up to these claims, the pitch of Python
| compatibility is almost certainly too compelling to ignore.
| not to say Julia will die; R still has its uses and dominates
| some niche areas
| esafak wrote:
| R as a language was nothing to write home about. All it had
| going for it was its libraries. I never rooted for R, and I
| don't care for python anymore either. Python was general
| purpose, had enough libraries, and a bigger community. Its
| victory was predictable.
| staticfloat wrote:
| I really like the integration of lower-level memory control in
| a superset of Python. Trying to maintain compatibility with
| such a large and varied ecosystem is a daunting task, and has
| the opportunity to be very valuable for many people who don't
| want (or are unable) to move away from the Python ecosystem.
| Kudos to you all for tackling such a difficult problem! Good
| luck, I look forward to seeing how you guys help to increase
| efficiency across the board!
| int_19h wrote:
| Why is "no GC" an advantage for something aimed at such high-
| level tasks?
| ummonk wrote:
| Yeah funnily enough I think "no GC" would be a much better
| feature in Julia, which would make it a great language for
| real time applications.
| bobbylarrybobby wrote:
| You could do a lot worse than modern GC. For instance, in
| Rust, lack of GC may cause you to reallocate memory or use
| reference counting, both of which are likely slower than
| GC. For instance, building a tree in Rust will do a _lot_
| of reference counting, which is a _lot_ of heap accesses.
| dermesser wrote:
| This is not true at all! Julia usually being JIT-compiled
| makes it very unsuitable for real time applications (and
| there's no reason why it should be great for it). GC is the
| least issue here, and I say that as a fan and daily user of
| Julia.
| Archit3ch wrote:
| After the 1st JIT-compilation (which here we treat as C++
| static compilation), there is no compilation cost. As
| long as you avoid doing dynamic things (e.g. GC), there's
| a great case to be made for real time Julia.
| adgjlsfhk1 wrote:
| Julia is already being used in a number of systems with
| varying levels of real-time-ness. It's early days for
| sure, but there's a bunch of progress. It turns out lots
| of "real time" applications actually just need fast code.
| JIT compile also can be overcome since in real time
| systems, you generally know all the code you are going to
| call so you can just make a .so with all of those bits
| compiled and know that nothing will need to be compiled
| at runtime.
|
| Also on a related topic, the PR for parallel GC in Julia
| just merged 4 days ago
| (https://github.com/JuliaLang/julia/pull/48600), so GC is
| in the process of getting a bunch faster.
| sundarurfriend wrote:
| > Julia is already being used in a number of systems with
| varying levels of real-time-ness.
|
| Any examples you could link to?
| adgjlsfhk1 wrote:
| The coolest I know of is ASML putting Julia on their
| giant chip making machines
| https://www.youtube.com/watch?v=EafTuyy7apY. I think
| there's also work on putting Julia on satellites, but I
| don't have the details.
| fulafel wrote:
| No GC and Python compatibility sounds interesting, is there
| docs about memory management?
|
| Edit: seems some current hints are under the roadmap "Ownership
| and Lifetimes" heading but Python compatibility is not
| described yet.
| ConanRus wrote:
| [dead]
| Sukera wrote:
| 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-
| diff...
| throwawaymaths wrote:
| 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),
| 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.
| ubj wrote:
| 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)
| helen___keller wrote:
| Was very pleased to see that for meta programming, they went with
| something similar to Zigs comptime
| rvz wrote:
| 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 OpenAI.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 wrote:
| 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 wrote:
| 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...
| https://docs.modular.com/mojo/notebooks/Mandelbrot.html
| JonChesterfield wrote:
| 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).
| drBonkers wrote:
| Why would I use this over Nim?
| pineapple_sauce wrote:
| 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.
| earthboundkid wrote:
| 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?
| chubot wrote:
| 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
|
| _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 wrote:
| > 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).
|
| 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/). 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.
| chrislattner wrote:
| Thanks for your interest, I'm pretty confident we can do
| this. I've been working on compilers and languages for
| awhile. :)
|
| Your point about LLVM compile time is great one. Mojo is
| architected from the beginning for fast compile times,
| including deeply integrated caching and distributed
| compilation. LLVM "isn't slow" if you don't keep asking it to
| do the same thing over and over again.
|
| -Chris
| Sukera wrote:
| I think Chris was referring to the leaky abstractions
| python grew on https://www.youtube.com/watch?v=qCGofLIzX6g
| InitEnabler wrote:
| Wonder how this compares to Nim.
| singularity2001 wrote:
| 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/pr...
|
| And please make Optional[T] as ergonomic as Swift / Kotlin with a
| simple '?'
| kerinin wrote:
| Interesting to see some of Rust's ideas start to spread. I never
| thought borrow checking would become popular ;)
| dom96 wrote:
| 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:
|
| > 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.
| [deleted]
| mindcrime wrote:
| Will Mojo be OSS? Or is this strictly proprietary?
| chrislattner wrote:
| Open source over time as it matures:
| https://twitter.com/Modular_AI/status/1653439606522802176?s=...
| alberth wrote:
| So is this actually Python or not?
|
| I'm a bit confused.
| bufo wrote:
| 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 wrote:
| Wrong, Mojo is not a runtime for Python.
| abc_lisper wrote:
| This is like C++ to C - so python++, ++ is for features and
| native compilation
| codepoet80 wrote:
| Palm has entered the chat:
| https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk...
| AbuAssar wrote:
| Chris Lattner of LLVM and Swift fame is behind mojo
| cs702 wrote:
| 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!
| otoburb wrote:
| >> _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 wrote:
| 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.
| bjornasm wrote:
| I think this discussion is a bit better if you read the
| docs:
|
| >We utilize CPython to run all existing Python3 code "out
| of the box" without modification
| jadodev wrote:
| 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
| azakai wrote:
| But see the section "Intentional differences from
| Python", which is after your quote,
|
| 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.
| bjornasm wrote:
| Isn't
|
| >We utilize CPython to run all existing Python3 code "out
| of the box" without modification
|
| from the docs the direct opposite of what the commentator
| claimed?
| [deleted]
| throwaway894345 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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
| lairv wrote:
| 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
| fleur-de-lotus wrote:
| Could you consider choosing another name for the language? mojo
| doesn't sound sexy. Ask for suggestions.
| drivingmenuts wrote:
| Somewhere out there, a recruiter is gearing up to demand 5 years
| experience with Mojo before they will look at your resume.
| pknerd wrote:
| I already added "Mojo Evangelism is my mojo" in my LinkedIn
| Title.
| Archit3ch wrote:
| Dibs on Mojo Dojo (mojodojo.com), your new premier training
| resource for Mojo.
| kps wrote:
| Hey, I've used
| 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.)
| sytse wrote:
| 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/ is
| going for a similar goal. But this is a more fundamental
| approach.
| l2dy wrote:
| A file extension of [fire emoji], this is not easy to type from a
| terminal.
|
| Edit: It's even stripped on HN!
| lairv wrote:
| Read on their discord server that it both support .mojo and the
| fire emoji
| newswasboring wrote:
| 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 wrote:
| 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 '-'.)
| JonChesterfield wrote:
| 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.
| silisili wrote:
| 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.
| JonChesterfield wrote:
| 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.
| drBonkers wrote:
| I'm also curious. Modular seems to be what Chris wanted with
| Swift, but couldn't because of Apple's thumb.
| dunefox wrote:
| I wish new languages would move away from python syntax and
| semantics and just do their own thing more.
| dom96 wrote:
| I wish more would take inspiration from Python syntax.
| rg111 wrote:
| 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.
| calebm wrote:
| Python Interoperability seems like a killer feature.
| cube2222 wrote:
| 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.
| staticfloat wrote:
| 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/JuliaSI
| MD/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-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.
| bufo wrote:
| Yeah I think no one will likely have any edge for a simple
| thing like a matrix multiplication since all the right
| abstractions are supported in both languages and they end up
| in the LLVM code gen. Having Python 3 backwards compatibility
| and easily deploying your code to, say, phones via a C++ API
| is quite big though.
| UncleOxidant wrote:
| Yeah, it seems like they sort of reinvented Julia but with more
| of a Python syntax?
| cube2222 wrote:
| > we want full compatibility with the Python ecosystem
|
| Oh, I guess that's one big philosophical difference.
| TheMagicHorsey wrote:
| 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 wrote:
| 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 wrote:
| 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.
| UncleOxidant wrote:
| So... did they reinvent Julia? (but with more of a python syntax)
| kraihx wrote:
| 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
|
| Or it's port to TypeScript: https://mojojs.org
| gok wrote:
| Finally, the package management ecosystem of Python with the
| compiler speed and error messages of Rust and Swift.
| tikkun wrote:
| 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
| raphlinus wrote:
| 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.
| vsskanth wrote:
| 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 wrote:
| How big are the binaries? (what I mean is, are they 1MB, or
| 100MB, or worse?)
| ubj wrote:
| 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
| _hel...
|
| [2]: https://discourse.julialang.org/t/standalone-hello-
| world-exe...
| adgjlsfhk1 wrote:
| 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).
| [deleted]
| version_five wrote:
| The website is unusable for me (brave on android). I can't really
| scroll. Am I the only having this problem?
| minhazm wrote:
| 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 wrote:
| This is exactly what I was trying to figure out. It seems like
| the answer is no at this time.
| lairv wrote:
| From their FAQ 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.)."
| minhazm wrote:
| The problem with this is that you don't know what the
| licensing will be when/if they open source it. So you could
| start using it now and they might change their mind and
| choose not to open source it or it might be a restrictive
| license.
| neilv wrote:
| Also, even if fully open source, have to also look at
| governance.
|
| (A canonical project can be steered in a way that makes
| it impractical for you, and forking is often also
| impractical.)
|
| For now, I'd treat it as closed source, which is a non-
| starter for investing in, when I can accomplish the same
| in open source ways. And there's no sense in giving away
| the open source uptake benefits to a company when the
| software isn't open source.
| theLiminator wrote:
| 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 wrote:
| Why bother doing it that way? Just to entertain people
| who works like to observe the commit history as the
| language evolves?
| version_five wrote:
| It gives people confidence to start working with it now.
| asadm wrote:
| It's closed so others don't catch up quicker or add those
| optimizations upstream? Then they have no moat.
| Vox_Leone wrote:
| >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.
|
| Well, by the number of 3rd party domains you have to allow to
| see the info it does not look free or OS...
| newswasboring wrote:
| Oh god I hope this is not a close source language. I have spent
| 10+ years fighting the MATLAB ecosystem, I prefer not to spend
| the next 10 years fighting this thing.
| version_five wrote:
| Matlab existed for a reason, and has since become irrelevant,
| in particular in the face of python being used as a more
| flexible open source scientific computing scripting language.
|
| If this is closed source, it's already as irrelevant as
| matlab so no reason to fight it. If there are useful bits
| there will be python versions of them.
| singhrac wrote:
| Strongly disagree with this statement (and agree with the
| parent). In many hard engineering disciplines, appropriate
| solvers (e.g. SuiteSparse) are barely supported, if at all
| (e.g. scikit-sparse only supports CHOLMOD, and UMFPACK is
| supported via another package).
|
| People overestimate how many people are willing to work on
| the "wrap C numerical library in Python" problem. On the
| other hand, Mathworks employs many people to work on things
| like mldivide. At least in the SuiteSparse case, the first
| class citizen is MATLAB.
| version_five wrote:
| Sounds like a niche to me, with lots of options (wrapping
| C numerical libraries in python) for people that don't
| want to be locked in.
|
| When I was in school 15 years ago, matlab was pretty
| ubiquitous.
|
| Maybe it was to strong to say it's irrelevant as opposed
| to niche, though it's definitely irrelevant in many
| fields where it used to be king. I do miss the figures
| though, I liked the combination of programmatic
| formatting + manual tweaks.
| newswasboring wrote:
| > Matlab existed for a reason, and has since become
| irrelevant
|
| My man I wish this was true. I am not exaggerating the 10+
| year thing, there are very important industries being run
| today on MATLAB. You remember the moment when you learned
| that a lot of wall street runs on excel? This is the moment
| you learn a lot of silicon manufacturing runs on MATLAB. An
| obscene amount.
| [deleted]
| tabtab wrote:
| 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 wrote:
| > I want the ADHD-meat-and-potatoes tutorial.
|
| What does this mean?
| nojonestownpls wrote:
| 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 wrote:
| 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.
| tgma wrote:
| 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 wrote:
| 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).
| throwaway12223 wrote:
| what about pointers?
___________________________________________________________________
(page generated 2023-05-02 23:01 UTC)