11 ms·

Mojo 1.0 Beta

375 points by sbt567 4mo ago

chrismsimpson 4mo ago
I do wonder if Mojo was a great idea just a little too late to the party. Porting ‘prototypes’ from Python to lower level languages is fairly trivial now with LLMs.
- msaelices 4mo ago
  Modern LLMs are perfectly capable to learn the syntax of a new language on the fly and write great Code. E.g. there is an official Mojo syntax skill you can use and works well
pjmlp 4mo ago
Still phase one, doesn't do native Windows. Meanwhile Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. So will Mojo still arrive on time to gain wider adoption? Time will tell.
dllu 4mo ago
I remember reading about this 4 years ago as the new Chris Lattner project and was super excited, though a little skeptical. I think that nowadays with vibe/agentic coding, high performance Python-like languages become ever more important. Directly using AI agents to code, say, C++, is painful as the verbose nature of the language often causes the context window to explode.
- boxed 4mo ago
  Not to mention that C++ basically can't be made to be safe. But Rust is probably fine.
  - pjmlp 4mo ago
    In theory that is the idea behind profiles, in practice it remains to be seen what will they deliver until C++29, and if matters by then. Microsoft is invested into using AI for C++ code review, for example.
modeless 4mo ago
When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.
- haskman 4mo ago
  Really the only thing good about Python is its ecosystem.
  - mastermage 4mo ago
    but that ecosystem is realy good.
    - haskman 4mo ago
      That it is
  - coldtea 4mo ago
    Nah, it's also a very fine language for getting an idea down quickly. Might not have the niceties purists like, but perhaps that's exactly it's a great language for that. It's like executable pseudocode, and unlike other languages, all the ceremony is optional. People flocked to it way before it became a "must" for ML and CS thanks to that ecosystem becoming dominant.
    - haskman 4mo ago
      Look at my statement in context of Mojo. Why would someone use this language if all they want is to "get an idea down quickly"? They would just use Python instead
- ainch 4mo ago
  In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.
0xpgm 4mo ago
Right now majority of beginners start programming with a high-level language, say Python or JavaScript - then for more advanced system-level tasks pickup C/C++/Rust/Zig etc. If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.
logicchains 4mo ago
Very bold of them expecting people to use a language with a closed source compiler in the 2020s.
- walterlw 4mo ago
  from what I understand the goal for now is not to get the people to use it, but for enthusiasts to try it
  - kstrauser 4mo ago
    What enthusiast worth getting feedback from is going to tinker with a locked up language?
    - melodyogonna 4mo ago
      You'd be surprised. Anyway, the compiler will be opened with 1.0 release, that's why reaching beta is exciting.
- ainch 4mo ago
  They've said they'll open source the compiler alongside the 1.0 release.
- evertheylen 4mo ago
  If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/ https://julialang.org/
  - runarberg 4mo ago
    I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me. Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
insumanth 4mo ago
I was excited when Mojo launched and thought it might grow big quick. I don't see much traction. The pitch is compelling. What could be the issue?
- tweakimp 4mo ago
  When it was announced it was not generally available for everyone to try out. There was a waitlist phase.
- samuell 4mo ago
  As someone who would have strong reasons to invest time in Modular (simple high performant language for implementing bioinformatics scripts), I would say primarily the worry that development might be too tied to Modular, the startup behind it, which eventually might pivot into other priorities. One would want to see either a strong community build up around it, or really hard evidence for a long-term commitment to the language from Modular. And the latter will take a long time to be assured of I think. Also, editing tools need to catch up before very wide adoption of a language with a lot of new syntax.
- williamstein 4mo ago
  Mojo is still NOT open source (the standard library is but not the compiler). Open source is table stakes for a modern programming language.
- kstrauser 4mo ago
  I have no time for or interest in proprietary compilers. The standard library is Apache 2, but the license link on their home page is to a long terms of service thing. I’d like to be wrong because it looks interesting. Until then, this doesn’t exist in my world. I bet that’s true for a great many people. There are too many wonderful FOSS languages to bother with one you can’t fix or adapt or share.
- pjmlp 4mo ago
  - Doesn't support Windows, which is what many companies give their employees, outside Silicon Valey like culture - The MLIR approach, which was also designed by Chris Lattner while at Google, has proven quite valuable to create Python JIT DSL - The Python ecosystem now being taken seriously by the main GPU vendors, thanks to MLIR, as all their proprietary compilers are based out of LLVM - Others remember Swift for Tensorflow
ainch 4mo ago
As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did `len(x)` (turns out they'd opted for more specific byte-vs-codepoint representations, but the docs contradicted the actual implementation). Hopefully they get Mojo to a good place for more general ML, but at the moment it still feels quite limited - they've actually deprecated some of the nice builtins they had for Tensors etc... For now I'll stick with JAX and check in periodically, fingers crossed.
- coldtea 4mo ago
  >As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
  - Certhas 4mo ago
    This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...
    - _aavaa_ 4mo ago
      I don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.
    - pjmlp 4mo ago
      CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late. Doesn't matter if it was closed, when the alternatives were much worse.
noduerme 4mo ago
Am I old or remembering this wrong... didn't Zuck write the first iteration of Facebook in PHP, and then spend millions to hire people to write something that converted the code to C++?
- dtj1123 4mo ago
  https://en.wikipedia.org/wiki/Hack_(programming_language) https://en.wikipedia.org/wiki/Hack_(programming_language)
  - CodeArtisan 4mo ago
    Hack came after. Noduerme is referring to https://en.wikipedia.org/wiki/HipHop_for_PHP https://en.wikipedia.org/wiki/HipHop_for_PHP
    - dtj1123 4mo ago
      Today I learned
    - brcmthrowaway 4mo ago
      Whoever made this probably got a gigantic bonus!
DeathArrow 4mo ago
>No more choosing between productivity and performance - Mojo gives you both. That's a very big claim.
runarberg 4mo ago
I am actually on a lookout for a low level language which compiles to web assembly to write a (relatively small) supervised learning model which I plan to be good enough for 5 year old phone CPUs. I have a working prototype in Julia and was planning on (eventually) rewrite it in Rust mostly for the web assembly target. I come from a high level language background so the thought of rewriting in rust is a little daunting. So I was excited to learn about Mojo and find out if they had a WebAssembly target in their compiler. But then I read this: > AI native > Mojo is built from the ground up to deliver the best performance on the diverse hardware that powers modern AI systems. As a compiled, statically-typed language, it's also ideal for agentic programming. Well, no thank you. I know the irony here but I want nothing to do with a language made for robots.
- kstrauser 4mo ago
  I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhere else. Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.
  - pjmlp 4mo ago
    I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.
    - kibwen 4mo ago
      I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.
fibonacci112358 4mo ago
Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR). Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code. Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.
- brcmthrowaway 4mo ago
  Interesting, how big impact is CuTile?
- melodyogonna 4mo ago
  People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.
  - pjmlp 4mo ago
    Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway. You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.
    - melodyogonna 4mo ago
      It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfaa4a066a07e40b2806d19/mojo/stdlib/std/gpu/memory/memory.mojo#L774 https://github.com/modular/modular/blob/9b9fc007378f16148cfa... Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular. You don't get this choice using vendor-specific libraries; you're locked into this or that.
thefounder 4mo ago
Does it have the indentation thing? That would be a no go for a lot of people
- IceDane 4mo ago
  Only incredibly inexperienced people think indentation in python is a problem.
  - vga1 4mo ago
    I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.
    - tweakimp 4mo ago
      Use black as format on save and you will never have a problem with that. https://github.com/psf/black https://github.com/psf/black
      - deleted 4mo ago
        [deleted]
      - vga1 4mo ago
        Sure, black's pretty good and definitely better than nothing. Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.
  - tasuki 4mo ago
    Yes, indeed, indentation is one of the very few things in Python which aren't problematic!
  - Petersipoi 4mo ago
    How the fuck could you possibly even possibly begin to validate such a claim. Lol. Asshole.
smartmic 4mo ago
Advertising prominently with "AI native" seems necessary today, at least for some folks. To me, that's kind of off-putting, since it doesn't really say anything. Can anyone of the AI enthusiasts here explain, why, or, what is meant by > As a compiled, statically-typed language, it's also ideal for agentic programming.
- rmnclmnt 4mo ago
  Because a coding agent (when instructed well) will try to make a piece of code work in a loop. Static typing and compilation help in the process (no more undefined variables discovered at runtime for instance). But that’s not bullet proof at all as most of us know
- jpnc 4mo ago
  It's been really interesting to see all the desperation on hero pages for all these products and services ever since AI came into prominence. I think the funniest for me was opening IBM DB2 product page and seeing it labeled as 'AI database'. Hysterical. > why, or, what is meant by More errors caught at compile time means an agent can quickly check their work statically without unit and other tests.
- Reubend 4mo ago
  I don't know what they meant by it, and I share your opinion that "AI native" is somewhat meaningless for a programming language like this. Regarding compilation and static typing, it's extremely helpful to be able to detect issues at compile time when doing agentic programming. That way, you don't run into as many problems at runtime, which of course the agent has more difficulty addressing. Unit tests can help bridge the gap somewhat but not entirely. What's not stated on their website is that Mojo is likely a bad choice for agentic programming simply because there isn't much Mojo training data yet.
  - boxed 4mo ago
    I've recently used Claude to write quite a bit of mojo (https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod) and I can quite confidently say that Claude will write deprecated mojo syntax a lot, but the compiler tells it and it fixes it pretty fast too. The only reason I notice is that I look at Claude while it's working and I see the compilation warnings (and sometimes Claude is lazy and doesn't compile so I have to see it). But yea, to write mojo 1.0 code even after getting errors might take a new training round, so next or even next-next models.
Timot05 4mo ago
I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo. From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe. I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.
- arikrahman 4mo ago
  I'm in the same boat, this would've been in the family of the first language that neural nets and AI were created with back decades ago, Lisp. Coming from the awesome project of Swift, which to their credit, was a massive undertaking to convince Apple execs, I was still hoping for a functional language approach like Haskell with the practicality of Clojure.
- Revanche1367 4mo ago
  The vast majority of real world ML code today is written in languages like Python and C++. Relatively few people outside of academia and online forums are functional language enthusiasts. The industry is also looking like most actual coding is going to be done by LLMs going forward, so it makes little sense to design new languages with a niche potential user base since LLMs need a ton of training data. I’m think that was a factor in deciding to base mojo on Python along with the other reasons they state.
  - Timot05 4mo ago
    agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.
armchairhacker 4mo ago
> We have committed to open-sourcing Mojo in Fall 2026. https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- jlundberg 4mo ago
  Good catch in the noise. Thanks!
- dismalaf 4mo ago
  Nice. I'd love to see the source of an actual state of the art MLIR program.
  - tkocmathla 4mo ago
    HEIR [1] is a homomorphic encryption compiler built on modern MLIR. IREE [2] is very actively developed ML compiler + runtime, also MLIR-based. [1] https://github.com/google/heir https://github.com/google/heir [2] https://github.com/iree-org/iree https://github.com/iree-org/iree
    - mathisfun123 4mo ago
      https://github.com/triton-lang/triton https://github.com/triton-lang/triton https://github.com/tenstorrent/tt-mlir https://github.com/tenstorrent/tt-mlir https://github.com/onnx/onnx-mlir https://github.com/onnx/onnx-mlir https://github.com/openxla/stablehlo https://github.com/openxla/stablehlo plenty more - just google
sriram_malhar 4mo ago
Doesn't anyone here have _one_ kind word to say about its features? Every one seems to be starting with "on the other hand".
- pjmlp 4mo ago
  Many of us were already around during Swift for Tensorflow.
pjmlp 4mo ago
Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. If Mojo will still arrive on time to gain wider adoption remains to be seen.
- adev_ 4mo ago
  > Python cuTile JIT compiler allows writing CUDA kernels in straight Python. It is currently not straight Python and will never be. All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface. They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues. Lets not lie to ourself: Python is inherently bad for efficiency and performance. And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency. The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse. Mojo is different. Mojo tries to start from a clean sheet instead of hacking the existing crap. And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old) And just for that, I wish them success.
  - pjmlp 4mo ago
    I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language. As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,... Heck maybe someone could dig out StarLisp.
tveita 4mo ago
Is there any project that showcases Mojo for running neural network models on the GPU - like ideally something like llama.cpp that could run one or more existing models to showcase the readability and performance?
- melodyogonna 4mo ago
  Something like this https://github.com/tairov/llama2.mojo https://github.com/tairov/llama2.mojo?
DeathArrow 4mo ago
>As a compiled, statically-typed language, it's also ideal for agentic programming. Since there is not much Mojo code in the wild so the LLMs were trained on it, I wonder how it will work in practice. Probably the agents will make lots of mistakes and you will spend 10x the tokens compared to using a language the model are well versed in.
taylorallred 4mo ago
I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)
- totalperspectiv 4mo ago
  Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.
  - simplyvibecode 4mo ago
    Full open source Mojo 1.0 coming this fall!
  - momojo 4mo ago
    I work in bioimaging. What kind of bioinformatics are you doing that requires mojo level power?
    - totalperspectiv 4mo ago
      "requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU. Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there. I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding. Paper on the tool I wrote: https://doi.org/10.1093/bioadv/vbaf292 https://doi.org/10.1093/bioadv/vbaf292
      - momojo 4mo ago
        I might have to look into mojo. What's "alignment" in your context. In bioimaging it usually refers to aligning something to a reference atlas (like the Allen Reference Mouse Brain Atlas) or aligning two microscope channels (like the red channel and green channel)
      - 4mo ago
coppsilgold 4mo ago
Python is basically the master glue language at this point. If more than a few percent of execution time is spent in Python you are probably doing it wrong. Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages: <https://pypi.org/project/rustimport/ https://pypi.org/project/rustimport/> <https://pypi.org/project/import-zig/ https://pypi.org/project/import-zig/> Note that you can even start threads in those languages and use function calls as pseudo-RPC. All without an overly complex build system.
- physicsguy 4mo ago
  Cython and PyBind and Nanobind are good for wrapping an existing library written in C++ and crafting an interface that doesn’t feel like it’s a C++ one. They were a big step from ctypes and SWIG
  - pjmlp 4mo ago
    Plus, even if it has a Perl like feeling to it, C++26 reflection will make this even easier. Already available on GCC 16.
- MohamedMabrouk 4mo ago
  Mojo aims to be this (other language) arguably with easier programming model that rust, familiar syntax to python devs, and a modern design in general. Its stated goal now, is the easiest way to extend python. it provides the same interface for zero-hassle import of .mojo files
- sirfz 4mo ago
  Cython is a no-brainer really. You write the same language with immense speedup (matching what the "other languages" can achieve at much less effort). Also tools like numba can beat them all at way less effort. Imho, dropping into other languages should be the last resort in any project.
- fiedzia 4mo ago
  > If more than a few percent of execution time is spent in Python you are probably doing it wrong. Every program that starts with 1% of Python writes more Python and gets to 20,40, 60 and than 99% of it.
totalperspectiv 4mo ago
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's open sourced later this year.
- tapirl 4mo ago
  > ..., comptime that is more powerful than Zig It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
  - melodyogonna 4mo ago
    Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/ https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.
    - tapirl 4mo ago
      It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.
      - melodyogonna 4mo ago
        Well, it certainly allows you to encode invariants in a more precise manner.
      - totalperspectiv 4mo ago
        That's fair, I think I should have just said "comparable to Zig". The type'd ness is what I was thinking of, but having actually written some zig in the last few days to play with their Io model / see what passing around an allocator is like, Zig is pretty fantastic. I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.
AbuAssar 4mo ago
> AI native What’s that supposed to mean?
- jjice 4mo ago
  My guess is that they expose first party skills and maybe other agent friendly docs? Not positive though.
csvance 4mo ago
Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.
bobajeff 4mo ago
I've been keeping my eye on mojo. Honestly though the thing I least like about Python is it's syntax. Someone else here is bringing up Julia. Which I think is a fine language but the compiler error messages and the library documentation are not what I would want in a language as far along as it is. I'm also worried about the correctness issues I've read about in a blog awhile back. Also I don't feel like I can make the kind of Python module I want with it (because of binary size and time to first x) That being said I'm only hoping that Mojo can become an option. But I really like to use a REPL and I like the dynamicness of Python. So I might not ever get around to doing anything outside of maybe Numpy for performance.
- Recurecur 4mo ago
  I’m a big fan of Mojo’s design. It isn’t comparable to Julia since it has deterministic memory management. I also think Mojo is more focused on being an industrial strength language. I was shocked to see the first iteration of Julia ahead of time compilation did not provide file I/O.
- archargelod 4mo ago
  > the thing I least like about Python is it's syntax. For me it's the opposite - the only thing I like about Python is it's syntax. That's why I really like Nim - you get C speed, "comptime", metaprogramming, powerful type system, memory safety and code is often short and elegant. Mojo seems interesting too, but so far they're mostly focused on ML stuff and not general programming. And I believe compiler is still not open-source?
jadar 4mo ago
Congrats to Chris Lattner and crew! Seems like a neat project. I listened to him talk about Mojo on some podcast a while back and was really impressed. Swift was a runaway success, and I hope he can pull it off again with Mojo! :)
rienbdj 4mo ago
Does anyone know if Mojo is more suitable for functional programming that Python? Things like optimizing away object allocations, pure function inlining, tail call optimization?
andriamanitra 4mo ago
The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems. [1] https://mojolang.org/releases/v1.0.0b1/ https://mojolang.org/releases/v1.0.0b1/
maxloh 4mo ago
Modular is going to open source the entire mojo SDK later this year, including the compiler. > Mojo 1.0 will be finalized later this year, along with opening the compiler and providing language stability. https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-video-gen-and-more https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
VerifiedReports 4mo ago
Is what?

375 points by sbt567 4mo ago

I do wonder if Mojo was a great idea just a little too late to the party. Porting ‘prototypes’ from Python to lower level languages is fairly trivial now with LLMs.

msaelices 4mo ago
Modern LLMs are perfectly capable to learn the syntax of a new language on the fly and write great Code. E.g. there is an official Mojo syntax skill you can use and works well

pjmlp 4mo ago

Still phase one, doesn't do native Windows. Meanwhile Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. So will Mojo still arrive on time to gain wider adoption? Time will tell.

dllu 4mo ago

I remember reading about this 4 years ago as the new Chris Lattner project and was super excited, though a little skeptical. I think that nowadays with vibe/agentic coding, high performance Python-like languages become ever more important. Directly using AI agents to code, say, C++, is painful as the verbose nature of the language often causes the context window to explode.

boxed 4mo ago
Not to mention that C++ basically can't be made to be safe. But Rust is probably fine.
- pjmlp 4mo ago
  In theory that is the idea behind profiles, in practice it remains to be seen what will they deliver until C++29, and if matters by then. Microsoft is invested into using AI for C++ code review, for example.

modeless 4mo ago

When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.

haskman 4mo ago
Really the only thing good about Python is its ecosystem.
- mastermage 4mo ago
  but that ecosystem is realy good.
  - haskman 4mo ago
    That it is
- coldtea 4mo ago
  Nah, it's also a very fine language for getting an idea down quickly. Might not have the niceties purists like, but perhaps that's exactly it's a great language for that. It's like executable pseudocode, and unlike other languages, all the ceremony is optional. People flocked to it way before it became a "must" for ML and CS thanks to that ecosystem becoming dominant.
  - haskman 4mo ago
    Look at my statement in context of Mojo. Why would someone use this language if all they want is to "get an idea down quickly"? They would just use Python instead
ainch 4mo ago
In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.

0xpgm 4mo ago

Right now majority of beginners start programming with a high-level language, say Python or JavaScript - then for more advanced system-level tasks pickup C/C++/Rust/Zig etc. If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.

logicchains 4mo ago

Very bold of them expecting people to use a language with a closed source compiler in the 2020s.

walterlw 4mo ago
from what I understand the goal for now is not to get the people to use it, but for enthusiasts to try it
- kstrauser 4mo ago
  What enthusiast worth getting feedback from is going to tinker with a locked up language?
  - melodyogonna 4mo ago
    You'd be surprised. Anyway, the compiler will be opened with 1.0 release, that's why reaching beta is exciting.
ainch 4mo ago
They've said they'll open source the compiler alongside the 1.0 release.
evertheylen 4mo ago
If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/ https://julialang.org/
- runarberg 4mo ago
  I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me. Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.

insumanth 4mo ago

I was excited when Mojo launched and thought it might grow big quick. I don't see much traction. The pitch is compelling. What could be the issue?

tweakimp 4mo ago
When it was announced it was not generally available for everyone to try out. There was a waitlist phase.
samuell 4mo ago
As someone who would have strong reasons to invest time in Modular (simple high performant language for implementing bioinformatics scripts), I would say primarily the worry that development might be too tied to Modular, the startup behind it, which eventually might pivot into other priorities. One would want to see either a strong community build up around it, or really hard evidence for a long-term commitment to the language from Modular. And the latter will take a long time to be assured of I think. Also, editing tools need to catch up before very wide adoption of a language with a lot of new syntax.
williamstein 4mo ago
Mojo is still NOT open source (the standard library is but not the compiler). Open source is table stakes for a modern programming language.
kstrauser 4mo ago
I have no time for or interest in proprietary compilers. The standard library is Apache 2, but the license link on their home page is to a long terms of service thing. I’d like to be wrong because it looks interesting. Until then, this doesn’t exist in my world. I bet that’s true for a great many people. There are too many wonderful FOSS languages to bother with one you can’t fix or adapt or share.
pjmlp 4mo ago
- Doesn't support Windows, which is what many companies give their employees, outside Silicon Valey like culture - The MLIR approach, which was also designed by Chris Lattner while at Google, has proven quite valuable to create Python JIT DSL - The Python ecosystem now being taken seriously by the main GPU vendors, thanks to MLIR, as all their proprietary compilers are based out of LLVM - Others remember Swift for Tensorflow

ainch 4mo ago

As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did `len(x)` (turns out they'd opted for more specific byte-vs-codepoint representations, but the docs contradicted the actual implementation). Hopefully they get Mojo to a good place for more general ML, but at the moment it still feels quite limited - they've actually deprecated some of the nice builtins they had for Tensors etc... For now I'll stick with JAX and check in periodically, fingers crossed.

coldtea 4mo ago
>As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
- Certhas 4mo ago
  This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...
  - _aavaa_ 4mo ago
    I don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.
  - pjmlp 4mo ago
    CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late. Doesn't matter if it was closed, when the alternatives were much worse.

noduerme 4mo ago

Am I old or remembering this wrong... didn't Zuck write the first iteration of Facebook in PHP, and then spend millions to hire people to write something that converted the code to C++?

dtj1123 4mo ago
https://en.wikipedia.org/wiki/Hack_(programming_language) https://en.wikipedia.org/wiki/Hack_(programming_language)
- CodeArtisan 4mo ago
  Hack came after. Noduerme is referring to https://en.wikipedia.org/wiki/HipHop_for_PHP https://en.wikipedia.org/wiki/HipHop_for_PHP
  - dtj1123 4mo ago
    Today I learned
  - brcmthrowaway 4mo ago
    Whoever made this probably got a gigantic bonus!

DeathArrow 4mo ago

>No more choosing between productivity and performance - Mojo gives you both. That's a very big claim.

runarberg 4mo ago

I am actually on a lookout for a low level language which compiles to web assembly to write a (relatively small) supervised learning model which I plan to be good enough for 5 year old phone CPUs. I have a working prototype in Julia and was planning on (eventually) rewrite it in Rust mostly for the web assembly target. I come from a high level language background so the thought of rewriting in rust is a little daunting. So I was excited to learn about Mojo and find out if they had a WebAssembly target in their compiler. But then I read this: > AI native > Mojo is built from the ground up to deliver the best performance on the diverse hardware that powers modern AI systems. As a compiled, statically-typed language, it's also ideal for agentic programming. Well, no thank you. I know the irony here but I want nothing to do with a language made for robots.

kstrauser 4mo ago
I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhere else. Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.
- pjmlp 4mo ago
  I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.
  - kibwen 4mo ago
    I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.

fibonacci112358 4mo ago

Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR). Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code. Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.

brcmthrowaway 4mo ago
Interesting, how big impact is CuTile?
melodyogonna 4mo ago
People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.
- pjmlp 4mo ago
  Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway. You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.
  - melodyogonna 4mo ago
    It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfaa4a066a07e40b2806d19/mojo/stdlib/std/gpu/memory/memory.mojo#L774 https://github.com/modular/modular/blob/9b9fc007378f16148cfa... Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular. You don't get this choice using vendor-specific libraries; you're locked into this or that.

thefounder 4mo ago

Does it have the indentation thing? That would be a no go for a lot of people

IceDane 4mo ago
Only incredibly inexperienced people think indentation in python is a problem.
- vga1 4mo ago
  I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.
  - tweakimp 4mo ago
    Use black as format on save and you will never have a problem with that. https://github.com/psf/black https://github.com/psf/black
    - deleted 4mo ago
      [deleted]
    - vga1 4mo ago
      Sure, black's pretty good and definitely better than nothing. Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.
- tasuki 4mo ago
  Yes, indeed, indentation is one of the very few things in Python which aren't problematic!
- Petersipoi 4mo ago
  How the fuck could you possibly even possibly begin to validate such a claim. Lol. Asshole.

smartmic 4mo ago

Advertising prominently with "AI native" seems necessary today, at least for some folks. To me, that's kind of off-putting, since it doesn't really say anything. Can anyone of the AI enthusiasts here explain, why, or, what is meant by > As a compiled, statically-typed language, it's also ideal for agentic programming.

rmnclmnt 4mo ago
Because a coding agent (when instructed well) will try to make a piece of code work in a loop. Static typing and compilation help in the process (no more undefined variables discovered at runtime for instance). But that’s not bullet proof at all as most of us know
jpnc 4mo ago
It's been really interesting to see all the desperation on hero pages for all these products and services ever since AI came into prominence. I think the funniest for me was opening IBM DB2 product page and seeing it labeled as 'AI database'. Hysterical. > why, or, what is meant by More errors caught at compile time means an agent can quickly check their work statically without unit and other tests.
Reubend 4mo ago
I don't know what they meant by it, and I share your opinion that "AI native" is somewhat meaningless for a programming language like this. Regarding compilation and static typing, it's extremely helpful to be able to detect issues at compile time when doing agentic programming. That way, you don't run into as many problems at runtime, which of course the agent has more difficulty addressing. Unit tests can help bridge the gap somewhat but not entirely. What's not stated on their website is that Mojo is likely a bad choice for agentic programming simply because there isn't much Mojo training data yet.
- boxed 4mo ago
  I've recently used Claude to write quite a bit of mojo (https://github.com/boxed/TurboKod https://github.com/boxed/TurboKod) and I can quite confidently say that Claude will write deprecated mojo syntax a lot, but the compiler tells it and it fixes it pretty fast too. The only reason I notice is that I look at Claude while it's working and I see the compilation warnings (and sometimes Claude is lazy and doesn't compile so I have to see it). But yea, to write mojo 1.0 code even after getting errors might take a new training round, so next or even next-next models.

Timot05 4mo ago

I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo. From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe. I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.

arikrahman 4mo ago
I'm in the same boat, this would've been in the family of the first language that neural nets and AI were created with back decades ago, Lisp. Coming from the awesome project of Swift, which to their credit, was a massive undertaking to convince Apple execs, I was still hoping for a functional language approach like Haskell with the practicality of Clojure.
Revanche1367 4mo ago
The vast majority of real world ML code today is written in languages like Python and C++. Relatively few people outside of academia and online forums are functional language enthusiasts. The industry is also looking like most actual coding is going to be done by LLMs going forward, so it makes little sense to design new languages with a niche potential user base since LLMs need a ton of training data. I’m think that was a factor in deciding to base mojo on Python along with the other reasons they state.
- Timot05 4mo ago
  agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.

armchairhacker 4mo ago

> We have committed to open-sourcing Mojo in Fall 2026. https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

jlundberg 4mo ago
Good catch in the noise. Thanks!
dismalaf 4mo ago
Nice. I'd love to see the source of an actual state of the art MLIR program.
- tkocmathla 4mo ago
  HEIR [1] is a homomorphic encryption compiler built on modern MLIR. IREE [2] is very actively developed ML compiler + runtime, also MLIR-based. [1] https://github.com/google/heir https://github.com/google/heir [2] https://github.com/iree-org/iree https://github.com/iree-org/iree
  - mathisfun123 4mo ago
    https://github.com/triton-lang/triton https://github.com/triton-lang/triton https://github.com/tenstorrent/tt-mlir https://github.com/tenstorrent/tt-mlir https://github.com/onnx/onnx-mlir https://github.com/onnx/onnx-mlir https://github.com/openxla/stablehlo https://github.com/openxla/stablehlo plenty more - just google

sriram_malhar 4mo ago

Doesn't anyone here have _one_ kind word to say about its features? Every one seems to be starting with "on the other hand".

pjmlp 4mo ago
Many of us were already around during Swift for Tensorflow.

pjmlp 4mo ago

Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. If Mojo will still arrive on time to gain wider adoption remains to be seen.

adev_ 4mo ago
> Python cuTile JIT compiler allows writing CUDA kernels in straight Python. It is currently not straight Python and will never be. All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface. They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues. Lets not lie to ourself: Python is inherently bad for efficiency and performance. And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency. The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse. Mojo is different. Mojo tries to start from a clean sheet instead of hacking the existing crap. And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old) And just for that, I wish them success.
- pjmlp 4mo ago
  I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language. As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,... Heck maybe someone could dig out StarLisp.

tveita 4mo ago

Is there any project that showcases Mojo for running neural network models on the GPU - like ideally something like llama.cpp that could run one or more existing models to showcase the readability and performance?

melodyogonna 4mo ago
Something like this https://github.com/tairov/llama2.mojo https://github.com/tairov/llama2.mojo?

DeathArrow 4mo ago

>As a compiled, statically-typed language, it's also ideal for agentic programming. Since there is not much Mojo code in the wild so the LLMs were trained on it, I wonder how it will work in practice. Probably the agents will make lots of mistakes and you will spend 10x the tokens compared to using a language the model are well versed in.

taylorallred 4mo ago

I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)

totalperspectiv 4mo ago
Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.
- simplyvibecode 4mo ago
  Full open source Mojo 1.0 coming this fall!
- momojo 4mo ago
  I work in bioimaging. What kind of bioinformatics are you doing that requires mojo level power?
  - totalperspectiv 4mo ago
    "requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU. Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there. I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding. Paper on the tool I wrote: https://doi.org/10.1093/bioadv/vbaf292 https://doi.org/10.1093/bioadv/vbaf292
    - momojo 4mo ago
      I might have to look into mojo. What's "alignment" in your context. In bioimaging it usually refers to aligning something to a reference atlas (like the Allen Reference Mouse Brain Atlas) or aligning two microscope channels (like the red channel and green channel)
    - 4mo ago

coppsilgold 4mo ago

Python is basically the master glue language at this point. If more than a few percent of execution time is spent in Python you are probably doing it wrong. Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages: <https://pypi.org/project/rustimport/ https://pypi.org/project/rustimport/> <https://pypi.org/project/import-zig/ https://pypi.org/project/import-zig/> Note that you can even start threads in those languages and use function calls as pseudo-RPC. All without an overly complex build system.

physicsguy 4mo ago
Cython and PyBind and Nanobind are good for wrapping an existing library written in C++ and crafting an interface that doesn’t feel like it’s a C++ one. They were a big step from ctypes and SWIG
- pjmlp 4mo ago
  Plus, even if it has a Perl like feeling to it, C++26 reflection will make this even easier. Already available on GCC 16.
MohamedMabrouk 4mo ago
Mojo aims to be this (other language) arguably with easier programming model that rust, familiar syntax to python devs, and a modern design in general. Its stated goal now, is the easiest way to extend python. it provides the same interface for zero-hassle import of .mojo files
sirfz 4mo ago
Cython is a no-brainer really. You write the same language with immense speedup (matching what the "other languages" can achieve at much less effort). Also tools like numba can beat them all at way less effort. Imho, dropping into other languages should be the last resort in any project.
fiedzia 4mo ago
> If more than a few percent of execution time is spent in Python you are probably doing it wrong. Every program that starts with 1% of Python writes more Python and gets to 20,40, 60 and than 99% of it.

totalperspectiv 4mo ago

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's open sourced later this year.

tapirl 4mo ago
> ..., comptime that is more powerful than Zig It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
- melodyogonna 4mo ago
  Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/ https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.
  - tapirl 4mo ago
    It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.
    - melodyogonna 4mo ago
      Well, it certainly allows you to encode invariants in a more precise manner.
    - totalperspectiv 4mo ago
      That's fair, I think I should have just said "comparable to Zig". The type'd ness is what I was thinking of, but having actually written some zig in the last few days to play with their Io model / see what passing around an allocator is like, Zig is pretty fantastic. I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.

AbuAssar 4mo ago

> AI native What’s that supposed to mean?

jjice 4mo ago
My guess is that they expose first party skills and maybe other agent friendly docs? Not positive though.

csvance 4mo ago

Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.

bobajeff 4mo ago

I've been keeping my eye on mojo. Honestly though the thing I least like about Python is it's syntax. Someone else here is bringing up Julia. Which I think is a fine language but the compiler error messages and the library documentation are not what I would want in a language as far along as it is. I'm also worried about the correctness issues I've read about in a blog awhile back. Also I don't feel like I can make the kind of Python module I want with it (because of binary size and time to first x) That being said I'm only hoping that Mojo can become an option. But I really like to use a REPL and I like the dynamicness of Python. So I might not ever get around to doing anything outside of maybe Numpy for performance.

Recurecur 4mo ago
I’m a big fan of Mojo’s design. It isn’t comparable to Julia since it has deterministic memory management. I also think Mojo is more focused on being an industrial strength language. I was shocked to see the first iteration of Julia ahead of time compilation did not provide file I/O.
archargelod 4mo ago
> the thing I least like about Python is it's syntax. For me it's the opposite - the only thing I like about Python is it's syntax. That's why I really like Nim - you get C speed, "comptime", metaprogramming, powerful type system, memory safety and code is often short and elegant. Mojo seems interesting too, but so far they're mostly focused on ML stuff and not general programming. And I believe compiler is still not open-source?

jadar 4mo ago

Congrats to Chris Lattner and crew! Seems like a neat project. I listened to him talk about Mojo on some podcast a while back and was really impressed. Swift was a runaway success, and I hope he can pull it off again with Mojo! :)

rienbdj 4mo ago

Does anyone know if Mojo is more suitable for functional programming that Python? Things like optimizing away object allocations, pure function inlining, tail call optimization?

andriamanitra 4mo ago

The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems. [1] https://mojolang.org/releases/v1.0.0b1/ https://mojolang.org/releases/v1.0.0b1/

maxloh 4mo ago

Modular is going to open source the entire mojo SDK later this year, including the compiler. > Mojo 1.0 will be finalized later this year, along with opening the compiler and providing language stability. https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-video-gen-and-more https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...

VerifiedReports 4mo ago

Is what?