18 ms·

ML needs a new programming language – Interview with Chris Lattner

311 points by melodyogonna 1y ago

postflopclarity 1y ago
Julia could be a great language for ML. It needs more mindshare and developer attention though
- singularity2001 1y ago
  What's the current state of time to first plot and executable size? Last time it was several seconds to get a 200 MB hello world. I'm sure they are moving in the right direction the only questions is are they there yet?
  - moelf 1y ago
    with juliac.jl and --trim, hello world is now 1MB and compiles in a second. more realistic examples of compiling a Julia package into .so: https://indico.cern.ch/event/1515852/contributions/6599313/attachments/3104673/5502050/Jerry_Ling_StaticJulia.pdf https://indico.cern.ch/event/1515852/contributions/6599313/a...
  - postflopclarity 1y ago
    improving, slowly. 5 steps forward 3 steps back. 1.9 and 1.10 made huge gains in package precompilation and native code caching. then attentions shifted and there were some regressions in compile times due to unrelated things in 1.11 and the upcoming 1.12. but at the same time, 1.12 will contain an experimental new feature `--trim` as well as some further standardization around entry points to run packages as programs, which is a big step towards generating self-contained small binaries. also nearly all efforts in improving tooling are focused on providing static analysis and helping developers make their program more easily compilable. it's also important a bit to distinguish between a few similar but related needs. most of what I just described applies to generating binaries for arbitrary programs. but for the example you stated "time to first plot" of existing packages, this is already much improved in 1.10 and users (aka non-package-developers) should see sub-second TTFP, and TTFX for most packages they use that have been updated to use the precompilation goodies in recent versions
  - adgjlsfhk1 1y ago
    julia> @time begin using Plots display(plot(rand(8))) end 1.074321 seconds On Julia 1.12 (currently at release candidate stage), <1mb hello world is possible with juliac (although juliac in 1.12 is still marked experimental)
  - ModernMech 1y ago
    I recently looked into making Julia binaries, and it's not at all a good process. They say it's supported, but it's not exactly as easy as "cargo build" to get a Julia binary out. And the build process involves creating this minimal version of Julia you're expected to ship with your binary, so build times were terrible. I don't know if that gets amortized though. As far as the executable size, it was only 85kb in my test, a bouncing balls simulation. However, it required 300MB of Julia libraries to be shipped with it. About 2/3 of that is in libjulia-codegen.dll, libLLVM-16jl.dll. So you're shipping this chunky runtime and their LLVM backend. If you're willing to pay for that, you can ship a Julia executable. It's a better story than what Python offers, but it's not great if you want small, self-contained executables.
    - postflopclarity 1y ago
      note that as a few other commenters have pointed out, this situation will improve greatly in 1.12 (although still many rough edges)
      - ModernMech 1y ago
        Yeah, that's what I've been hearing about Julia for about 10 years now: "situation will improve greatly in the next version, but still many rough edges remain". I've been involved in a few programming language projects, so I'm sympathetic as to how much work goes into one and how long they can take. At the same time, it makes me wary of Julia, because it highlights that progress is very slow. I think Julia is trying to be too much at once. It's hard enough to be a dynamic, interactive language, but they also want to claim to be performant and compiled. That's a lot of complexity for a small team to handle and deliver on.
        adgjlsfhk1 1y ago
        Different things have been improving for the past 10 years. TTFX is in a good spot now, multithreading is in a pretty good spot now, GC issues for most people are basically solved. AOT compilation was pretty much the last big item that a lot of people wanted, and that has recently (within the last year) gotten to the point where the code exists, it's merged, and it will be releasing soon (and then spending the next year or two getting improved)
- numbers_guy 1y ago
  What makes Julia "great" for ML?
  - postflopclarity 1y ago
    I would use the term "potentially great" rather than plain "great" but all the normal marketing words: in my opinion it is fast, expressive, and has particularly good APIs for array manipulation
    - numbers_guy 1y ago
      Interesting. I am experimenting with different ML ecosystems and wasn't really considering Julia at all but I put it on the list now.
      - postflopclarity 1y ago
        Glad to hear. I've found it's a very welcoming community. I'll warn you that Julia's ML ecosystem has the most competitive advantage on "weird" types of ML, involving lots of custom gradients and kernels, integration with other pieces of a simulation or diffeq, etc. if you just want to throw some tensors around and train a MLP, you'll certainly end up finding more rough edges than you might in PyTorch
        salty_biscuits 1y ago
        Yes, my experience has been that it is great if you need to do something particularly weird, but less smooth to do something ordinary.
      - blurbleblurble 1y ago
        If I wanted to get into research ML, I'd pick Julia no doubt. It allows both conventional ML techniques where we throw tons of parameters at the problem, but additionally a more nimble style where we can train over ordinary functions. Combine that with all the cutting edge applied math packages often being automatically compatible with the autodiff and GPU array backends, even if the library authors didn't think about that... it's a recipe for a lot of interesting possibilities.
- mdaniel 1y ago
  I don't understand why in the world someone would go from one dynamically typed language to another. Even the kernels example cited below is "eh, the types are whatever you want them to be" https://cuda.juliagpu.org/stable/tutorials/introduction/#Writing-your-first-GPU-kernel https://cuda.juliagpu.org/stable/tutorials/introduction/#Wri... Then again, I am also open to the fact that I'm jammed up by the production use of dynamically typed languages, and maybe the "for ML" part means "I code in Jupyter notebooks" and thus give no shits about whether person #2 can understand what's happening
  - postflopclarity 1y ago
    It's very important that readers, writers, maintainers, etc. of code are able to easily understand what that code is doing. explicit and strict types on arguments to functions is one way, but certainly not the only way, nor probably the best way to effect that
    - mdaniel 1y ago
      I would actually be curious to hear your perspective on the "best way" that isn't typechecking. I literally cannot comprehend why someone would write such a thing I readily admit that I am biased in that I believe that having a computer check that every reference to every relationship does what it promises, all the time
      - postflopclarity 1y ago
        first and foremost great documentation & design docs cannot be surpassed as a tool to explain and understand code. and that is entirely language agnostic. more generally, the most important bits of a particular function to understand is * what should it be called with * what should it return * what side effects might it have and the "what" here refers to properties in a general sense. types are a good shortcut to signify certain named collections of properties (e.g., the `Int` type has arithmetic properties). but there are other ways to express traits, preconditions, postconditions, etc. besides types
- rvz 1y ago
  > It needs more mindshare and developer attention though That is the problem. Julia could not compete against Python's mindshare. A competitor to Python needs to be 100% compatible with its ecosystem.
MontyCarloHall 1y ago
The reason why Python dominates is that modern ML applications don't exist in a vacuum. They aren't the standalone C/FORTRAN/MATLAB scripts of yore that load in some simple, homogeneous data, crunch some numbers, and spit out a single result. Rather, they are complex applications with functionality extending far beyond the number crunching, which requires a robust preexisting software ecosystem. For example, a modern ML application might need an ETL pipeline to load and harmonize data of various types (text, images, video, etc., all in different formats) from various sources (local filesystem, cloud storage, HTTP, etc.) The actual computation then must leverage many different high-level functionalities, e.g. signal/image processing, optimization, statistics, etc. All of this computation might be too big for one machine, and so the application must dispatch jobs to a compute cluster or cloud. Finally, the end results might require sophisticated visualization and organization, with a GUI and database. There is no single language with a rich enough ecosystem that can provide literally all of the aforementioned functionality besides Python. Python's numerical computing libraries (NumPy/PyTorch/JAX etc.) all call out to C/C++/FORTRAN under the hood and are thus extremely high-performance, and for functionality they don't implement, Python's C/C++ FFIs (e.g. Python.h, NumPy C integration, PyTorch/Boost C++ integration) are not perfect, but are good enough that implementing the performance-critical portions of code in C/C++ is much easier compared to re-implementing entire ecosystems of packages in another language like Julia.
- Hizonner 1y ago
  This guy is worried about GPU kernels, which are never, ever written in Python. As you point out, Python is a glue language for ML. > There is no single language with a rich enough ecosystem that can provide literally all of the aforementioned functionality besides Python. That may be true, but some of us are still bitter that all that grew up around an at-least-averagely-annoying language rather than something nicer.
  - MontyCarloHall 1y ago
    >This guy is worried about GPU kernels Then the title should be "why GPU kernel programming needs a new programming language." I can get behind that; I've written CUDA C and it was not fun (though this was over a decade ago and things may have since improved, not to mention that the code I wrote then could today be replaced by a couple lines of PyTorch). That said, GPU kernel programming is fairly niche: for the vast majority of ML applications, the high-level API functions in PyTorch/TensorFlow/JAX/etc. provide optimal GPU performance. It's pretty rare that one would need to implement custom kernels. >which are never, ever written in Python. Not true! Triton is a Python API for writing kernels, which are JIT compiled.
theanonymousone 1y ago
https://xkcd.com/927/ https://xkcd.com/927/ Sorry, couldn't resist.
atbpaca 1y ago
Mojo looks like the perfect balance between readability (python-like syntax) and efficiency (rust-like performance).
dboreham 1y ago
ML is a programming language.
- a3w 1y ago
  Meta Language is shortened to ML. Great language, and even fathered further ML dialects. Machine Learning is shortened to ML, too. This posting is about "Why ML needed Mojo", but does not tell us why the license of Mojo is garbage. M. Learning as an example of compute intensive tasks could have been the Rails moment for Ruby here, but seems like Mojo is dead on arrival — it was trending here at hackernews when announced, but no one seems to talk about it now. --------------- (I like em-dashes, but not written wit any AI, except for language tools spellchecker)
dboreham 1y ago
ML *is* a programming language.
- jhbadger 1y ago
  It's even standard! (well, one version of it is called that) https://en.wikipedia.org/wiki/Standard_ML https://en.wikipedia.org/wiki/Standard_ML
chrislattner 1y ago
Thank you for all the great interest in the podcast and in Mojo. If you're interested in learning more, Mojo has a FAQ that covers many topics (including "why not make Julia better" :-) here: https://docs.modular.com/mojo/faq/ https://docs.modular.com/mojo/faq/ Mojo also has a bunch of documentation https://docs.modular.com/mojo/ https://docs.modular.com/mojo/ as well as hundreds of thousands of lines of open source code you can check out: https://github.com/modular/modular https://github.com/modular/modular The Mojo community is really great, please consider joining, either our discourse forum: https://forum.modular.com/ https://forum.modular.com/ or discord https://discord.com/invite/modular https://discord.com/invite/modular chat. -Chris Lattner
- bsaul 1y ago
  Fan here. I watched a lot of your talks about mojo, where you mention how mojo benefits from very advanced compiler technology. But i've never seen you give concret example of this advanced technology. Please, can you write a blog about that, going as deep and hardcore tech as you can ? As i'm not a compiler dev i'll probably understand 20% of it, but hopefully i'll start to get a sense of how advanced the whole thing is.
  - melodyogonna 1y ago
    They've given a talk abut this on the LLVM dev meeting: https://www.youtube.com/watch?v=SEwTjZvy8vw& https://www.youtube.com/watch?v=SEwTjZvy8vw& They have some fancy tech around compile-time interpreter, mojopkg, and their code generator. They also have a graph compiler (not mentioned in the talk) that can fuse kernels written in Mojo.
    - timmyd 1y ago
      You might also enjoy this series: https://www.modular.com/democratizing-ai-compute https://www.modular.com/democratizing-ai-compute which goes into a lot of the details.
    - bsaul 1y ago
      interesting talk. I thought mojo actually had innovations at the IR level as well, but it seems to rely on what chris built at google with MLIR. Chris mentioned pushing updates to MLIR while working at Mojo, i'd be curious to have a summary what those changes are, because i believe this is where the hard core innovations are happening.
JonChesterfield 1y ago
ML seems to be doing just fine with python and cuda.
- poly2it 1y ago
  Python and CUDA are not very well adapted for embedded ML.
- davidatbu 1y ago
  Yeah the rate of progress in AI definitely makes it seem like that from the outside for me too. But having never written cuda, I have to rely on authority to some extent for this question. And it seems to me like few are in a better position to opine on whether there's a better story to be had for the software-hardware boundary in ML than the person who wrote MLIR, Swift-for-Tensorflow (alongside with making that work on TPUs and GPUs), ran ML at Tesla for some time, was VP at SiFive, ... etc.
icanthulahoop 1y ago
stopped after the first line. isn't Vikram Adve also the creator of LLVM? I prefer terms like co-creator, co-invented, etc.
CyberDildonics 1y ago
I don't think ML does need a new programming language. You give up an extreme amount of progress in tools and libraries when you move to a new language. I haven't seen new languages that market themselves for specific features that couldn't be done just as easily through straight classes with operator overloading.
tony 1y ago
Chris Lattner also has a very good episode on Lex Fridman (Episode 381, June 2nd, 2023): - https://www.youtube.com/watch?v=pdJQ8iVTwj8 https://www.youtube.com/watch?v=pdJQ8iVTwj8 - https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI - https://podcasts.apple.com/us/podcast/381-chris-lattner-future-of-programming-and-ai/id1434243584?i=1000615472588 https://podcasts.apple.com/us/podcast/381-chris-lattner-futu... He has two other episodes on the show: - https://www.youtube.com/watch?v=nWTvXbQHwWs https://www.youtube.com/watch?v=nWTvXbQHwWs (Episode 131, October 18th, 2020) - https://www.youtube.com/watch?v=yCd3CzGSte8 https://www.youtube.com/watch?v=yCd3CzGSte8 (Episode 21, May 13th, 2019)
lordofgibbons 1y ago
I'm the primary target audiance for Mojo and was very interested in it, but I just wish they didn't keep Exceptions. This backwards compatibility with Python syntax is extremely overrated and not worth the cost of bringing language warts from the 90s. God, I hate exceptions so much. I have never seen anyone use exceptions correctly in either Java (at FAANG) or in any regular Python application. I'm much more in favor of explicit error handling like in Go, or the syntax sugar Rust provides.
- UncleEntity 1y ago
  Which kind of begs the question: what it the correct way to use exceptions? Like, python says to throw an exception when an iterator reaches the end so if my custom C iterator does that is it wrong? I do kind of want to be able to do the whole 'for i in whatever: do(stuff(i))' thing so...
  - rybosome 1y ago
    Not the OP, but I assume they mean that it's encoded in the type system. For example Rust gives you a `Result<Thing, ErrorType>`, which might be a `Thing` or might be one of the possible error types given by `ErrorType`. So when you get a function's return value, you have to deal with the fact that it might have failed with this specific error.
- chrislattner 1y ago
  Exceptions in Mojo are just syntax sugar for Result types. You don't have to use them if you don't want, and the overhead is not like C++ exceptions.
tree_enjoyer 1y ago
I know it's a bit of trope to say this on HN... but why not Lisp? If I make the assumption that future ML code will be written by ML algorithms (or at least 'transpiled' from natural language), and Lisp S-Expressions are basically the AST, it would make sense that it would be the most natural language for a machine to write in. As a side benefit, it's already the standard to have a very feature complete REPL, so as a replacement for Python it seems it would fit well
- layer8 1y ago
  LLMs have trouble counting parentheses accurately. ;)
  - trallnag 1y ago
    We need a lisp that is written in JSON. That should fix it
    - cjohnson318 1y ago
      It would REBOLutionize everything.
    - sorry_i_lisp 1y ago
      https://github.com/delaneyj/jackalope https://github.com/delaneyj/jackalope
- nextos 1y ago
  Yann LeCun and others created https://lush.sourceforge.net https://lush.sourceforge.net, which was a Lisp for ML. It was probably the best option during the 2000s, and only superseded when Theano (Python) and Torch (Lua) emerged. A Lisp comeback in this niche would be great. Python has fantastic libraries, but the language leaves a lot to be desired.
- pjmlp 1y ago
  Because it got burned in the last AI hype cycle, and many devs still think Emacs + SBCL is the only way, never even bothered to open the websites of LispWorks, Allegro Common Lisp or Clozure (not the JVM one).
seabrookmx 1y ago
The mojo faq talks about the language as if it's a strict superset (or aiming to be) of Python. Or that mojo "is" Python. Yet the roadmap says: > As Mojo matures through phase 3, we believe Mojo will become increasingly compatible with Python code and deeply familiar to Python users, except more efficient, powerful, coherent, and safe. Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't. This is incredibly confusing. If it's _not_ aiming for Python compatibility, why are we talking about Python at all? Also, is anyone actually considering using an emoji as a file extension?
- pansa2 1y ago
  AFAICT Mojo has (or plans to have) Python-like syntax and easy interop with Python. I’m not sure it’s any more Python-like than that - the similarity to Python seems to be heavily overstated for marketing reasons.
  - itsn0tm3 1y ago
    I‘m pretty sure in their early communications the stated very clearly that Mojo is going to be a clear superset of Python. Seems like they paddled back a bit in that regard.
    - davidatbu 1y ago
      Yeah this is slightly confusing for me as well. Even in this very podcast, being a superset of Python was mentioned as a goal (albeit a long term one).
- mmphosis 1y ago
  > Also, is anyone actually considering using an emoji as a file extension? Definitely.U+2615
curtisszmania 1y ago
[dead]
Mars008 1y ago
It's not clear about multithreading on CPU. Without it it's hard to use modern it efficiently. Something like TBB library in C++ would be nice.
whimsicalism 1y ago
I find the attempt behind Mojo bold, but unfortunately a proprietary language a la matlab is a non-starter for me and I assume many other people.
- davidatbu 1y ago
  Fwiw, Chris has detailed in many podcasts that Mojo will definitely be entirely open source in the future, and that the only reason it isn't now is that he learnt from his experience running Swift as an open source project that the open contribution and planning model is a bad fit, and basically counter productive, at this stage of a language's lifetime. That is why they opted to open source in stages (ie, the stdlib is open source right now, and they expect to open source the compiler soon).
  - procaryote 1y ago
    That's nice... once it's fully open source and forkable, it might be worth a look
monkeyelite 1y ago
If there is one thing Chris is good at, it’s promoting himself and his work.
- davidatbu 1y ago
  Just to make sure I understand you correctly, you're claiming that the person who started (and lead onto maturity) LLVM, Swift, and MLIR, writing millions of lines of c++ and leading dozens of engineers in the process, is primarily good at self promotion (as opposed to, say, language design, or compilers, or tackling really hard and long term software projects)?
  - monkeyelite 1y ago
    That’s right, and saying otherwise is actually robbing him of his rightful talent and ability. > really hard and long term software project That’s kind of what I mean. He commits to projects and gets groups of people talking about them and interested. Imagine how hard it was to convince everyone at apple to use his language - and how many other smart engineers projects were not chosen. It’s not even clear the engineering merits were there for that one.
    - davidatbu 1y ago
      So I think a demonstrative example of your claim would be if you knew someone who is as accomplished with regards to compilers, language design, tackling really hard long term projects, but not as good at self promotion, and elaborate on what the lack of that skill-set caused. The only other person I know of who has started and lead to maturity multiple massive and infrastructural software projects is Fabrice Bellard. I've never ran into him self promoting (podcasts, HN, etc), and yet his projects are widely used and foundational. It seems to me like the evidence points to "if you tackle really hard, long term, and foundational software projects successfully, people will use it, regardless of your ability to self promote."
      - monkeyelite 1y ago
seanmcdirmid 1y ago
This headline must really irk someone like Robert Harper. Unfortunate acronym collision, but ML (programming language) at least could be disambiguated that way.
defraudbah 1y ago
clankers are getting out of hand
typpilol 1y ago
How comes no one has mentioned the weird file extension
brainzap 1y ago
side note: we need a new syntax, to separate human comments from machine/compiler/llm/type comments
gradientsrneat 1y ago
It's a shame we can't repurpose open graphics standards like Vulkan and SpirV for general purpose GPU computing. Meanwhile OpenCL was a standard for that purpose, but vendors perferred their walled gardens.
torginus 1y ago
I think Mojo's cool and there's definitely a place for a modern applications programming language with C++ class(ish) performance, aka what Swift wanted to be but got trapped in the Apple ecosystem (designed by the same person as Mojo). The strong AI focus seems to be a sign of the times, and not actually something that makes sense imo.
- ModernMech 1y ago
  It makes a lot of sense when you look at how much money they have raised: https://techcrunch.com/2023/08/24/modular-raises-100m-for-ai-dev-tools/ https://techcrunch.com/2023/08/24/modular-raises-100m-for-ai... You don’t raise $130M at a $600M valuation to make boring old dev infrastructure that is sorely needed but won’t generate any revenue because no one is willing to pay for general purpose programming languages in 2025. You raise $130M to be the programming foundation of next Gen AI. VCs wrote some big friggen checks for that pitch.
- diggan 1y ago
  > The strong AI focus seems to be a sign of the times, and not actually something that makes sense imo. Are you sure about that? I think Mojo was always talked about as "The language for ML/AI", but I'm unsure if Mojo was announced before the current hype-cycle, must be 2-3 years at this point right?
  - torginus 1y ago
    According to wikipedia it was announced in May 2023
- tomovo 1y ago
  While I appreciate all his work on LLVM, Chris Lattner's Swift didn't work out so well for me, so I'm cautious about this. Swift has some nice features. However, the super slow compilation times and cryptic error messages really erase any gains in productivity for me. - "The compiler is unable to type-check this expression in reasonable time?" On an M3 Pro? What the hell!? - To find an error in SwiftUI code I sometimes need to comment everything out block by block to narrow it down and find the culprit. We're getting laughs from Kotlin devs.
_aavaa_ 1y ago
Yeah, except Mojo’s license is a non-starter.
- rs186 1y ago
  To my naive mind, any language that is controlled by a single company instead of a non profit is a non-starter. Just look at how many companies reacted when Java license change happened. You must be either an idiot or way too smart for me to understand to base your business on a language like Mojo instead of Python.
  - discreteevent 1y ago
    It's hard to think of a language for server side programming that I could go back and recommend to build their business on 20 or 30 years ago than java. I don't think aws or even Google regret it. Think of the amount of profitable requests being processed by the jvm all over the world for years by every kind of business.
    - _aavaa_ 1y ago
      Yeah, but whose JVM are they running on? I’d be surprised if they’re all paying the lawnmower.
    - const_cast 1y ago
      That's just because oracle are assholes but not that big of assholes. If OpenJDK did not or could not exist, we would all be mega fucked. Luckily alternative Java implementations exist, are performant, and are largely indistinguishable from the non-free stuff. Well, except whatever android has going on... That stuff is quirky. But if you look at dotnet, prior to opensourcing it, it was kind of a fucked up choice to go with. You were basically locked into Windows Server for your backend and your application would basically slowly rot over time as you relied on legacy windows subsystems that even Microsoft barely cared to support, like COM+. There were always alternative dotnet runtimes like Mono, but they were very not feature complete. Which, ironically, is why we saw so much Java. The CLR is arguably a better designed VM and C# a better language, but it doesn't matter.
Cynddl 1y ago
Anyone knows what Mojo is doing that Julia cannot do? I appreciate that Julia is currently limited by its ecosystem (although it does interface nicely with Python), but I don't see how Mojo is any better then.
- bobajeff 1y ago
  I've looked into making Python modules with Julia and it doesn't look like that is very well supported right now. Where as it's a core feature of Mojo.
  - dunefox 1y ago
    Shouldn't something like this work? https://github.com/JuliaPy/PythonCall.jl https://github.com/JuliaPy/PythonCall.jl
    - bobajeff 1y ago
      That might work but can't seem to find much information on using it to create a pip installable module though.
- jakobnissen 1y ago
  Mojo to me looks significantly lower level, with a much higher degree of control. Also, it appears to be more robust. Julia is notoriously fickle in both semantics and performance, making it unsuitable for foundational software the way Mojo strives for.
  - Archit3ch 1y ago
    > Also, it appears to be more robust. Sure, Mojo the language is more robust. Until its investors decide to 10x the licensing Danegeld.
- thetwentyone 1y ago
  Especially because Julia has pretty user friendly and robust GPU capabilities such as JuliaGPU and Reactant[2] among other generic-Julia-code to GPU options. 1: https://enzymead.github.io/Reactant.jl/dev/ https://enzymead.github.io/Reactant.jl/dev/ 2: https://enzymead.github.io/Reactant.jl/dev/ https://enzymead.github.io/Reactant.jl/dev/
nromiun 1y ago
Weird that there has been no significant adoption of Mojo. It has been quite some time since it got released and everyone is still using PyTorch. Maybe the license issue is a much bigger deal than people realize.
- singularity2001 1y ago
  Is it really released? Last time I checked it was not open sourced I don't want to rely on some proprietary vaporware stack.
  - melodyogonna 1y ago
    It is released but not open-source. Modular was aiming to open-source the compiler by Q4 2026; however, Chris now says they could be able to do that considerably faster, perhaps early 2026[1]. If you're interested, they think the language will be ready for open source after completing phase 1 of the roadmap[2]. 1.https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 2. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
- melodyogonna 1y ago
  It is not ready for general-purpose programming. Modular itself tried offering a Mojo api for their MAX engine, but had to give up because the language still evolved too rapidly for such an investment. As per the roadmap[1], I expect to start seeing more adoption once phase 1 is completed. 1. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
- raggi 1y ago
  I'm on the systems side, and I find some of what Chris and team are doing with Mojo pretty interesting and could be useful to eradicate a bunch of polyglot ffi mess across the board. I can't invest in it or even start discussions around using it until it's actually open.
  - bobajeff 1y ago
blizdiddy 1y ago
Mojo is the enshitification of programming. Learning a language is too much cognitive investment for VC rugpulls. You make the entire compiler and runtime GPL or you pound sand, that has been the bar for decades. If the new cohort of programmers can’t hold the line, we’ll all suffer.
- j2kun 1y ago
  What are you ranting about? Lattner has a strong track record of producing valuable, open source software artifacts (LLVM, Swift, MLIR) used across the industry.
  - deleted 1y ago
    [deleted]
- pjmlp 1y ago
  For decades, paying for compiler tools was a thing.
  - kuschkufan 1y ago
    And it sucked so hard that GNU and LLVM were born.
    - pjmlp 1y ago
      LLVM was a research project embraced by Apple to avoid GCC and anything GPL. Apple and Google have purged most GPL stuff out of their systems, after making clang shine.
  - const_cast 1y ago
    Yes and it sucked, and those companies who relied on that largely got conned into it and then saw their tooling slowly decay and their application becomes legacy garbage. Its not just that OS tooling is "free", it's also better and works for way longer. If you relied on proprietary Delphi-compatible tooling, well... you fucked up!
deleted 1y ago
[deleted]
threeducks 1y ago
When I was young, I enjoyed messing around with new languages, but as time went on, I realized that there is really very little to be gained through new languages that can not be obtained through a new library, without the massive downside of throwing away most of the ecosystem due to incompatibility. Also, CuPy, Triton and Numba already exist right now and are somewhat mature, at least compared to Mojo.
- dwattttt 1y ago
  If a learning a new language didn't change how you think about programming, it wasn't a language worth learning.
  - threeducks 1y ago
    Learning new languages did change how I think about programming. For example, Clojure's immutability and functional nature had a strong influence on how I write my (mostly Python) code these days. I learned how to write efficient code for CPUs with C and C++, and for GPUs with CUDA and OpenCL. I learned math with Matlab and Octave, and declarative programming with Prolog. With Mojo, on the other hand, I think a library (or improvements to an existing library) would have been a better approach. A new language needlessly forks the developer community and duplicates work. But I can see the monetary incentives that made the Mojo developers choose this path, so good for them.
  - gugagore 1y ago
    "A language that doesn't affect the way you think about programming is not worth knowing." ― Alan J. Perlis
- jakobnissen 1y ago
  Usually people create languages to address issues that cannot be addressed by a library because they have different semantics on a deeper level. Like, Rust could not be a C++ library, that does not make sense. Zig could not be a C library. Julia could not be a Python library. There is some superficial level of abstraction where all programming languages do is interchangeable computation and therefore everything can be achieved in every language. But that superficial sameness doesn't correspond to the reality of programming.
frou_dh 1y ago
Listening to this episode, I was quite surprised to hear that even now in Sept 2025, support for classes at all is considered a medium-term goal. The "superset of Python" angle was thrown around a lot in earlier discussions of Mojo 1-2 years ago, but at this rate of progress seems a bit of a pie-in-the-sky aspiration?
- adgjlsfhk1 1y ago
  superset of Python was never a goal. It was a talking point to try and build momentum that was quietly dropped once it served it's purpose of getting Mojo some early attention.
  - fwip 1y ago
    I tend to agree, which is why I can't recommend Mojo, despite thinking their tech is pretty innovative. If they're willing to lie about something that basic, I can't trust any of their other claims.
  - ModernMech 1y ago
    I hope that’s not what it was, that makes them seem very manipulative and dishonest. I was under the impression it was a goal, but they dropped it when it became apparent it was too hard. That’s much more reasonable to understand.
    - adgjlsfhk1 1y ago
      I'd agree with you if Mojo was a project by an inexperienced team, but it wasn't. Chris Latner alone has decades of PL experience and the issues with making Python fast are fundamental and well known. anyone who comes around with a sales pitch for making a portion implementation that's significantly faster than Pypy is either incredibly naive or lying
      - ModernMech 1y ago
        For me, it’s because Chris is part of the team I’m willing to give them the benefit of the doubt. I will assume ego-driven naïveté over malice. It’s not unheard of.
Shorel 1y ago
We have C++ :)
mitch_said 1y ago
[dead]

311 points by melodyogonna 1y ago

postflopclarity 1y ago

Julia could be a great language for ML. It needs more mindshare and developer attention though

singularity2001 1y ago
What's the current state of time to first plot and executable size? Last time it was several seconds to get a 200 MB hello world. I'm sure they are moving in the right direction the only questions is are they there yet?
- moelf 1y ago
  with juliac.jl and --trim, hello world is now 1MB and compiles in a second. more realistic examples of compiling a Julia package into .so: https://indico.cern.ch/event/1515852/contributions/6599313/attachments/3104673/5502050/Jerry_Ling_StaticJulia.pdf https://indico.cern.ch/event/1515852/contributions/6599313/a...
- postflopclarity 1y ago
  improving, slowly. 5 steps forward 3 steps back. 1.9 and 1.10 made huge gains in package precompilation and native code caching. then attentions shifted and there were some regressions in compile times due to unrelated things in 1.11 and the upcoming 1.12. but at the same time, 1.12 will contain an experimental new feature `--trim` as well as some further standardization around entry points to run packages as programs, which is a big step towards generating self-contained small binaries. also nearly all efforts in improving tooling are focused on providing static analysis and helping developers make their program more easily compilable. it's also important a bit to distinguish between a few similar but related needs. most of what I just described applies to generating binaries for arbitrary programs. but for the example you stated "time to first plot" of existing packages, this is already much improved in 1.10 and users (aka non-package-developers) should see sub-second TTFP, and TTFX for most packages they use that have been updated to use the precompilation goodies in recent versions
- adgjlsfhk1 1y ago
  julia> @time begin using Plots display(plot(rand(8))) end 1.074321 seconds On Julia 1.12 (currently at release candidate stage), <1mb hello world is possible with juliac (although juliac in 1.12 is still marked experimental)
- ModernMech 1y ago
  I recently looked into making Julia binaries, and it's not at all a good process. They say it's supported, but it's not exactly as easy as "cargo build" to get a Julia binary out. And the build process involves creating this minimal version of Julia you're expected to ship with your binary, so build times were terrible. I don't know if that gets amortized though. As far as the executable size, it was only 85kb in my test, a bouncing balls simulation. However, it required 300MB of Julia libraries to be shipped with it. About 2/3 of that is in libjulia-codegen.dll, libLLVM-16jl.dll. So you're shipping this chunky runtime and their LLVM backend. If you're willing to pay for that, you can ship a Julia executable. It's a better story than what Python offers, but it's not great if you want small, self-contained executables.
  - postflopclarity 1y ago
    note that as a few other commenters have pointed out, this situation will improve greatly in 1.12 (although still many rough edges)
    - ModernMech 1y ago
      Yeah, that's what I've been hearing about Julia for about 10 years now: "situation will improve greatly in the next version, but still many rough edges remain". I've been involved in a few programming language projects, so I'm sympathetic as to how much work goes into one and how long they can take. At the same time, it makes me wary of Julia, because it highlights that progress is very slow. I think Julia is trying to be too much at once. It's hard enough to be a dynamic, interactive language, but they also want to claim to be performant and compiled. That's a lot of complexity for a small team to handle and deliver on.
      - adgjlsfhk1 1y ago
        Different things have been improving for the past 10 years. TTFX is in a good spot now, multithreading is in a pretty good spot now, GC issues for most people are basically solved. AOT compilation was pretty much the last big item that a lot of people wanted, and that has recently (within the last year) gotten to the point where the code exists, it's merged, and it will be releasing soon (and then spending the next year or two getting improved)
numbers_guy 1y ago
What makes Julia "great" for ML?
- postflopclarity 1y ago
  I would use the term "potentially great" rather than plain "great" but all the normal marketing words: in my opinion it is fast, expressive, and has particularly good APIs for array manipulation
  - numbers_guy 1y ago
    Interesting. I am experimenting with different ML ecosystems and wasn't really considering Julia at all but I put it on the list now.
    - postflopclarity 1y ago
      Glad to hear. I've found it's a very welcoming community. I'll warn you that Julia's ML ecosystem has the most competitive advantage on "weird" types of ML, involving lots of custom gradients and kernels, integration with other pieces of a simulation or diffeq, etc. if you just want to throw some tensors around and train a MLP, you'll certainly end up finding more rough edges than you might in PyTorch
      - salty_biscuits 1y ago
        Yes, my experience has been that it is great if you need to do something particularly weird, but less smooth to do something ordinary.
    - blurbleblurble 1y ago
      If I wanted to get into research ML, I'd pick Julia no doubt. It allows both conventional ML techniques where we throw tons of parameters at the problem, but additionally a more nimble style where we can train over ordinary functions. Combine that with all the cutting edge applied math packages often being automatically compatible with the autodiff and GPU array backends, even if the library authors didn't think about that... it's a recipe for a lot of interesting possibilities.
mdaniel 1y ago
I don't understand why in the world someone would go from one dynamically typed language to another. Even the kernels example cited below is "eh, the types are whatever you want them to be" https://cuda.juliagpu.org/stable/tutorials/introduction/#Writing-your-first-GPU-kernel https://cuda.juliagpu.org/stable/tutorials/introduction/#Wri... Then again, I am also open to the fact that I'm jammed up by the production use of dynamically typed languages, and maybe the "for ML" part means "I code in Jupyter notebooks" and thus give no shits about whether person #2 can understand what's happening
- postflopclarity 1y ago
  It's very important that readers, writers, maintainers, etc. of code are able to easily understand what that code is doing. explicit and strict types on arguments to functions is one way, but certainly not the only way, nor probably the best way to effect that
  - mdaniel 1y ago
    I would actually be curious to hear your perspective on the "best way" that isn't typechecking. I literally cannot comprehend why someone would write such a thing I readily admit that I am biased in that I believe that having a computer check that every reference to every relationship does what it promises, all the time
    - postflopclarity 1y ago
      first and foremost great documentation & design docs cannot be surpassed as a tool to explain and understand code. and that is entirely language agnostic. more generally, the most important bits of a particular function to understand is * what should it be called with * what should it return * what side effects might it have and the "what" here refers to properties in a general sense. types are a good shortcut to signify certain named collections of properties (e.g., the `Int` type has arithmetic properties). but there are other ways to express traits, preconditions, postconditions, etc. besides types
rvz 1y ago
> It needs more mindshare and developer attention though That is the problem. Julia could not compete against Python's mindshare. A competitor to Python needs to be 100% compatible with its ecosystem.

MontyCarloHall 1y ago

The reason why Python dominates is that modern ML applications don't exist in a vacuum. They aren't the standalone C/FORTRAN/MATLAB scripts of yore that load in some simple, homogeneous data, crunch some numbers, and spit out a single result. Rather, they are complex applications with functionality extending far beyond the number crunching, which requires a robust preexisting software ecosystem. For example, a modern ML application might need an ETL pipeline to load and harmonize data of various types (text, images, video, etc., all in different formats) from various sources (local filesystem, cloud storage, HTTP, etc.) The actual computation then must leverage many different high-level functionalities, e.g. signal/image processing, optimization, statistics, etc. All of this computation might be too big for one machine, and so the application must dispatch jobs to a compute cluster or cloud. Finally, the end results might require sophisticated visualization and organization, with a GUI and database. There is no single language with a rich enough ecosystem that can provide literally all of the aforementioned functionality besides Python. Python's numerical computing libraries (NumPy/PyTorch/JAX etc.) all call out to C/C++/FORTRAN under the hood and are thus extremely high-performance, and for functionality they don't implement, Python's C/C++ FFIs (e.g. Python.h, NumPy C integration, PyTorch/Boost C++ integration) are not perfect, but are good enough that implementing the performance-critical portions of code in C/C++ is much easier compared to re-implementing entire ecosystems of packages in another language like Julia.

Hizonner 1y ago
This guy is worried about GPU kernels, which are never, ever written in Python. As you point out, Python is a glue language for ML. > There is no single language with a rich enough ecosystem that can provide literally all of the aforementioned functionality besides Python. That may be true, but some of us are still bitter that all that grew up around an at-least-averagely-annoying language rather than something nicer.
- MontyCarloHall 1y ago
  >This guy is worried about GPU kernels Then the title should be "why GPU kernel programming needs a new programming language." I can get behind that; I've written CUDA C and it was not fun (though this was over a decade ago and things may have since improved, not to mention that the code I wrote then could today be replaced by a couple lines of PyTorch). That said, GPU kernel programming is fairly niche: for the vast majority of ML applications, the high-level API functions in PyTorch/TensorFlow/JAX/etc. provide optimal GPU performance. It's pretty rare that one would need to implement custom kernels. >which are never, ever written in Python. Not true! Triton is a Python API for writing kernels, which are JIT compiled.

theanonymousone 1y ago

https://xkcd.com/927/ https://xkcd.com/927/ Sorry, couldn't resist.

atbpaca 1y ago

Mojo looks like the perfect balance between readability (python-like syntax) and efficiency (rust-like performance).

dboreham 1y ago

ML is a programming language.

a3w 1y ago
Meta Language is shortened to ML. Great language, and even fathered further ML dialects. Machine Learning is shortened to ML, too. This posting is about "Why ML needed Mojo", but does not tell us why the license of Mojo is garbage. M. Learning as an example of compute intensive tasks could have been the Rails moment for Ruby here, but seems like Mojo is dead on arrival — it was trending here at hackernews when announced, but no one seems to talk about it now. --------------- (I like em-dashes, but not written wit any AI, except for language tools spellchecker)

dboreham 1y ago

ML *is* a programming language.

jhbadger 1y ago
It's even standard! (well, one version of it is called that) https://en.wikipedia.org/wiki/Standard_ML https://en.wikipedia.org/wiki/Standard_ML

chrislattner 1y ago

Thank you for all the great interest in the podcast and in Mojo. If you're interested in learning more, Mojo has a FAQ that covers many topics (including "why not make Julia better" :-) here: https://docs.modular.com/mojo/faq/ https://docs.modular.com/mojo/faq/ Mojo also has a bunch of documentation https://docs.modular.com/mojo/ https://docs.modular.com/mojo/ as well as hundreds of thousands of lines of open source code you can check out: https://github.com/modular/modular https://github.com/modular/modular The Mojo community is really great, please consider joining, either our discourse forum: https://forum.modular.com/ https://forum.modular.com/ or discord https://discord.com/invite/modular https://discord.com/invite/modular chat. -Chris Lattner

bsaul 1y ago
Fan here. I watched a lot of your talks about mojo, where you mention how mojo benefits from very advanced compiler technology. But i've never seen you give concret example of this advanced technology. Please, can you write a blog about that, going as deep and hardcore tech as you can ? As i'm not a compiler dev i'll probably understand 20% of it, but hopefully i'll start to get a sense of how advanced the whole thing is.
- melodyogonna 1y ago
  They've given a talk abut this on the LLVM dev meeting: https://www.youtube.com/watch?v=SEwTjZvy8vw& https://www.youtube.com/watch?v=SEwTjZvy8vw& They have some fancy tech around compile-time interpreter, mojopkg, and their code generator. They also have a graph compiler (not mentioned in the talk) that can fuse kernels written in Mojo.
  - timmyd 1y ago
    You might also enjoy this series: https://www.modular.com/democratizing-ai-compute https://www.modular.com/democratizing-ai-compute which goes into a lot of the details.
  - bsaul 1y ago
    interesting talk. I thought mojo actually had innovations at the IR level as well, but it seems to rely on what chris built at google with MLIR. Chris mentioned pushing updates to MLIR while working at Mojo, i'd be curious to have a summary what those changes are, because i believe this is where the hard core innovations are happening.

JonChesterfield 1y ago

ML seems to be doing just fine with python and cuda.

poly2it 1y ago
Python and CUDA are not very well adapted for embedded ML.
davidatbu 1y ago
Yeah the rate of progress in AI definitely makes it seem like that from the outside for me too. But having never written cuda, I have to rely on authority to some extent for this question. And it seems to me like few are in a better position to opine on whether there's a better story to be had for the software-hardware boundary in ML than the person who wrote MLIR, Swift-for-Tensorflow (alongside with making that work on TPUs and GPUs), ran ML at Tesla for some time, was VP at SiFive, ... etc.

icanthulahoop 1y ago

stopped after the first line. isn't Vikram Adve also the creator of LLVM? I prefer terms like co-creator, co-invented, etc.

CyberDildonics 1y ago

I don't think ML does need a new programming language. You give up an extreme amount of progress in tools and libraries when you move to a new language. I haven't seen new languages that market themselves for specific features that couldn't be done just as easily through straight classes with operator overloading.

tony 1y ago

Chris Lattner also has a very good episode on Lex Fridman (Episode 381, June 2nd, 2023): - https://www.youtube.com/watch?v=pdJQ8iVTwj8 https://www.youtube.com/watch?v=pdJQ8iVTwj8 - https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI - https://podcasts.apple.com/us/podcast/381-chris-lattner-future-of-programming-and-ai/id1434243584?i=1000615472588 https://podcasts.apple.com/us/podcast/381-chris-lattner-futu... He has two other episodes on the show: - https://www.youtube.com/watch?v=nWTvXbQHwWs https://www.youtube.com/watch?v=nWTvXbQHwWs (Episode 131, October 18th, 2020) - https://www.youtube.com/watch?v=yCd3CzGSte8 https://www.youtube.com/watch?v=yCd3CzGSte8 (Episode 21, May 13th, 2019)

lordofgibbons 1y ago

I'm the primary target audiance for Mojo and was very interested in it, but I just wish they didn't keep Exceptions. This backwards compatibility with Python syntax is extremely overrated and not worth the cost of bringing language warts from the 90s. God, I hate exceptions so much. I have never seen anyone use exceptions correctly in either Java (at FAANG) or in any regular Python application. I'm much more in favor of explicit error handling like in Go, or the syntax sugar Rust provides.

UncleEntity 1y ago
Which kind of begs the question: what it the correct way to use exceptions? Like, python says to throw an exception when an iterator reaches the end so if my custom C iterator does that is it wrong? I do kind of want to be able to do the whole 'for i in whatever: do(stuff(i))' thing so...
- rybosome 1y ago
  Not the OP, but I assume they mean that it's encoded in the type system. For example Rust gives you a `Result<Thing, ErrorType>`, which might be a `Thing` or might be one of the possible error types given by `ErrorType`. So when you get a function's return value, you have to deal with the fact that it might have failed with this specific error.
chrislattner 1y ago
Exceptions in Mojo are just syntax sugar for Result types. You don't have to use them if you don't want, and the overhead is not like C++ exceptions.

tree_enjoyer 1y ago

I know it's a bit of trope to say this on HN... but why not Lisp? If I make the assumption that future ML code will be written by ML algorithms (or at least 'transpiled' from natural language), and Lisp S-Expressions are basically the AST, it would make sense that it would be the most natural language for a machine to write in. As a side benefit, it's already the standard to have a very feature complete REPL, so as a replacement for Python it seems it would fit well

layer8 1y ago
LLMs have trouble counting parentheses accurately. ;)
- trallnag 1y ago
  We need a lisp that is written in JSON. That should fix it
  - cjohnson318 1y ago
    It would REBOLutionize everything.
  - sorry_i_lisp 1y ago
    https://github.com/delaneyj/jackalope https://github.com/delaneyj/jackalope
nextos 1y ago
Yann LeCun and others created https://lush.sourceforge.net https://lush.sourceforge.net, which was a Lisp for ML. It was probably the best option during the 2000s, and only superseded when Theano (Python) and Torch (Lua) emerged. A Lisp comeback in this niche would be great. Python has fantastic libraries, but the language leaves a lot to be desired.
pjmlp 1y ago
Because it got burned in the last AI hype cycle, and many devs still think Emacs + SBCL is the only way, never even bothered to open the websites of LispWorks, Allegro Common Lisp or Clozure (not the JVM one).

seabrookmx 1y ago

The mojo faq talks about the language as if it's a strict superset (or aiming to be) of Python. Or that mojo "is" Python. Yet the roadmap says: > As Mojo matures through phase 3, we believe Mojo will become increasingly compatible with Python code and deeply familiar to Python users, except more efficient, powerful, coherent, and safe. Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't. This is incredibly confusing. If it's _not_ aiming for Python compatibility, why are we talking about Python at all? Also, is anyone actually considering using an emoji as a file extension?

pansa2 1y ago
AFAICT Mojo has (or plans to have) Python-like syntax and easy interop with Python. I’m not sure it’s any more Python-like than that - the similarity to Python seems to be heavily overstated for marketing reasons.
- itsn0tm3 1y ago
  I‘m pretty sure in their early communications the stated very clearly that Mojo is going to be a clear superset of Python. Seems like they paddled back a bit in that regard.
  - davidatbu 1y ago
    Yeah this is slightly confusing for me as well. Even in this very podcast, being a superset of Python was mentioned as a goal (albeit a long term one).
mmphosis 1y ago
> Also, is anyone actually considering using an emoji as a file extension? Definitely.U+2615

curtisszmania 1y ago

[dead]

Mars008 1y ago

It's not clear about multithreading on CPU. Without it it's hard to use modern it efficiently. Something like TBB library in C++ would be nice.

whimsicalism 1y ago

I find the attempt behind Mojo bold, but unfortunately a proprietary language a la matlab is a non-starter for me and I assume many other people.

davidatbu 1y ago
Fwiw, Chris has detailed in many podcasts that Mojo will definitely be entirely open source in the future, and that the only reason it isn't now is that he learnt from his experience running Swift as an open source project that the open contribution and planning model is a bad fit, and basically counter productive, at this stage of a language's lifetime. That is why they opted to open source in stages (ie, the stdlib is open source right now, and they expect to open source the compiler soon).
- procaryote 1y ago
  That's nice... once it's fully open source and forkable, it might be worth a look

monkeyelite 1y ago

If there is one thing Chris is good at, it’s promoting himself and his work.

davidatbu 1y ago
Just to make sure I understand you correctly, you're claiming that the person who started (and lead onto maturity) LLVM, Swift, and MLIR, writing millions of lines of c++ and leading dozens of engineers in the process, is primarily good at self promotion (as opposed to, say, language design, or compilers, or tackling really hard and long term software projects)?
- monkeyelite 1y ago
  That’s right, and saying otherwise is actually robbing him of his rightful talent and ability. > really hard and long term software project That’s kind of what I mean. He commits to projects and gets groups of people talking about them and interested. Imagine how hard it was to convince everyone at apple to use his language - and how many other smart engineers projects were not chosen. It’s not even clear the engineering merits were there for that one.
  - davidatbu 1y ago
    So I think a demonstrative example of your claim would be if you knew someone who is as accomplished with regards to compilers, language design, tackling really hard long term projects, but not as good at self promotion, and elaborate on what the lack of that skill-set caused. The only other person I know of who has started and lead to maturity multiple massive and infrastructural software projects is Fabrice Bellard. I've never ran into him self promoting (podcasts, HN, etc), and yet his projects are widely used and foundational. It seems to me like the evidence points to "if you tackle really hard, long term, and foundational software projects successfully, people will use it, regardless of your ability to self promote."
    - monkeyelite 1y ago

seanmcdirmid 1y ago

This headline must really irk someone like Robert Harper. Unfortunate acronym collision, but ML (programming language) at least could be disambiguated that way.

defraudbah 1y ago

clankers are getting out of hand

typpilol 1y ago

How comes no one has mentioned the weird file extension

brainzap 1y ago

side note: we need a new syntax, to separate human comments from machine/compiler/llm/type comments

gradientsrneat 1y ago

It's a shame we can't repurpose open graphics standards like Vulkan and SpirV for general purpose GPU computing. Meanwhile OpenCL was a standard for that purpose, but vendors perferred their walled gardens.

torginus 1y ago

I think Mojo's cool and there's definitely a place for a modern applications programming language with C++ class(ish) performance, aka what Swift wanted to be but got trapped in the Apple ecosystem (designed by the same person as Mojo). The strong AI focus seems to be a sign of the times, and not actually something that makes sense imo.

ModernMech 1y ago
It makes a lot of sense when you look at how much money they have raised: https://techcrunch.com/2023/08/24/modular-raises-100m-for-ai-dev-tools/ https://techcrunch.com/2023/08/24/modular-raises-100m-for-ai... You don’t raise $130M at a $600M valuation to make boring old dev infrastructure that is sorely needed but won’t generate any revenue because no one is willing to pay for general purpose programming languages in 2025. You raise $130M to be the programming foundation of next Gen AI. VCs wrote some big friggen checks for that pitch.
diggan 1y ago
> The strong AI focus seems to be a sign of the times, and not actually something that makes sense imo. Are you sure about that? I think Mojo was always talked about as "The language for ML/AI", but I'm unsure if Mojo was announced before the current hype-cycle, must be 2-3 years at this point right?
- torginus 1y ago
  According to wikipedia it was announced in May 2023
tomovo 1y ago
While I appreciate all his work on LLVM, Chris Lattner's Swift didn't work out so well for me, so I'm cautious about this. Swift has some nice features. However, the super slow compilation times and cryptic error messages really erase any gains in productivity for me. - "The compiler is unable to type-check this expression in reasonable time?" On an M3 Pro? What the hell!? - To find an error in SwiftUI code I sometimes need to comment everything out block by block to narrow it down and find the culprit. We're getting laughs from Kotlin devs.

_aavaa_ 1y ago

Yeah, except Mojo’s license is a non-starter.

rs186 1y ago
To my naive mind, any language that is controlled by a single company instead of a non profit is a non-starter. Just look at how many companies reacted when Java license change happened. You must be either an idiot or way too smart for me to understand to base your business on a language like Mojo instead of Python.
- discreteevent 1y ago
  It's hard to think of a language for server side programming that I could go back and recommend to build their business on 20 or 30 years ago than java. I don't think aws or even Google regret it. Think of the amount of profitable requests being processed by the jvm all over the world for years by every kind of business.
  - _aavaa_ 1y ago
    Yeah, but whose JVM are they running on? I’d be surprised if they’re all paying the lawnmower.
  - const_cast 1y ago
    That's just because oracle are assholes but not that big of assholes. If OpenJDK did not or could not exist, we would all be mega fucked. Luckily alternative Java implementations exist, are performant, and are largely indistinguishable from the non-free stuff. Well, except whatever android has going on... That stuff is quirky. But if you look at dotnet, prior to opensourcing it, it was kind of a fucked up choice to go with. You were basically locked into Windows Server for your backend and your application would basically slowly rot over time as you relied on legacy windows subsystems that even Microsoft barely cared to support, like COM+. There were always alternative dotnet runtimes like Mono, but they were very not feature complete. Which, ironically, is why we saw so much Java. The CLR is arguably a better designed VM and C# a better language, but it doesn't matter.

Cynddl 1y ago

Anyone knows what Mojo is doing that Julia cannot do? I appreciate that Julia is currently limited by its ecosystem (although it does interface nicely with Python), but I don't see how Mojo is any better then.

bobajeff 1y ago
I've looked into making Python modules with Julia and it doesn't look like that is very well supported right now. Where as it's a core feature of Mojo.
- dunefox 1y ago
  Shouldn't something like this work? https://github.com/JuliaPy/PythonCall.jl https://github.com/JuliaPy/PythonCall.jl
  - bobajeff 1y ago
    That might work but can't seem to find much information on using it to create a pip installable module though.
jakobnissen 1y ago
Mojo to me looks significantly lower level, with a much higher degree of control. Also, it appears to be more robust. Julia is notoriously fickle in both semantics and performance, making it unsuitable for foundational software the way Mojo strives for.
- Archit3ch 1y ago
  > Also, it appears to be more robust. Sure, Mojo the language is more robust. Until its investors decide to 10x the licensing Danegeld.
thetwentyone 1y ago
Especially because Julia has pretty user friendly and robust GPU capabilities such as JuliaGPU and Reactant[2] among other generic-Julia-code to GPU options. 1: https://enzymead.github.io/Reactant.jl/dev/ https://enzymead.github.io/Reactant.jl/dev/ 2: https://enzymead.github.io/Reactant.jl/dev/ https://enzymead.github.io/Reactant.jl/dev/

nromiun 1y ago

Weird that there has been no significant adoption of Mojo. It has been quite some time since it got released and everyone is still using PyTorch. Maybe the license issue is a much bigger deal than people realize.

singularity2001 1y ago
Is it really released? Last time I checked it was not open sourced I don't want to rely on some proprietary vaporware stack.
- melodyogonna 1y ago
  It is released but not open-source. Modular was aiming to open-source the compiler by Q4 2026; however, Chris now says they could be able to do that considerably faster, perhaps early 2026[1]. If you're interested, they think the language will be ready for open source after completing phase 1 of the roadmap[2]. 1.https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 2. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
melodyogonna 1y ago
It is not ready for general-purpose programming. Modular itself tried offering a Mojo api for their MAX engine, but had to give up because the language still evolved too rapidly for such an investment. As per the roadmap[1], I expect to start seeing more adoption once phase 1 is completed. 1. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
raggi 1y ago
I'm on the systems side, and I find some of what Chris and team are doing with Mojo pretty interesting and could be useful to eradicate a bunch of polyglot ffi mess across the board. I can't invest in it or even start discussions around using it until it's actually open.
- bobajeff 1y ago

blizdiddy 1y ago

Mojo is the enshitification of programming. Learning a language is too much cognitive investment for VC rugpulls. You make the entire compiler and runtime GPL or you pound sand, that has been the bar for decades. If the new cohort of programmers can’t hold the line, we’ll all suffer.

j2kun 1y ago
What are you ranting about? Lattner has a strong track record of producing valuable, open source software artifacts (LLVM, Swift, MLIR) used across the industry.
- deleted 1y ago
  [deleted]
pjmlp 1y ago
For decades, paying for compiler tools was a thing.
- kuschkufan 1y ago
  And it sucked so hard that GNU and LLVM were born.
  - pjmlp 1y ago
    LLVM was a research project embraced by Apple to avoid GCC and anything GPL. Apple and Google have purged most GPL stuff out of their systems, after making clang shine.
- const_cast 1y ago
  Yes and it sucked, and those companies who relied on that largely got conned into it and then saw their tooling slowly decay and their application becomes legacy garbage. Its not just that OS tooling is "free", it's also better and works for way longer. If you relied on proprietary Delphi-compatible tooling, well... you fucked up!

deleted 1y ago

[deleted]

threeducks 1y ago

When I was young, I enjoyed messing around with new languages, but as time went on, I realized that there is really very little to be gained through new languages that can not be obtained through a new library, without the massive downside of throwing away most of the ecosystem due to incompatibility. Also, CuPy, Triton and Numba already exist right now and are somewhat mature, at least compared to Mojo.

dwattttt 1y ago
If a learning a new language didn't change how you think about programming, it wasn't a language worth learning.
- threeducks 1y ago
  Learning new languages did change how I think about programming. For example, Clojure's immutability and functional nature had a strong influence on how I write my (mostly Python) code these days. I learned how to write efficient code for CPUs with C and C++, and for GPUs with CUDA and OpenCL. I learned math with Matlab and Octave, and declarative programming with Prolog. With Mojo, on the other hand, I think a library (or improvements to an existing library) would have been a better approach. A new language needlessly forks the developer community and duplicates work. But I can see the monetary incentives that made the Mojo developers choose this path, so good for them.
- gugagore 1y ago
  "A language that doesn't affect the way you think about programming is not worth knowing." ― Alan J. Perlis
jakobnissen 1y ago
Usually people create languages to address issues that cannot be addressed by a library because they have different semantics on a deeper level. Like, Rust could not be a C++ library, that does not make sense. Zig could not be a C library. Julia could not be a Python library. There is some superficial level of abstraction where all programming languages do is interchangeable computation and therefore everything can be achieved in every language. But that superficial sameness doesn't correspond to the reality of programming.

frou_dh 1y ago

Listening to this episode, I was quite surprised to hear that even now in Sept 2025, support for classes at all is considered a medium-term goal. The "superset of Python" angle was thrown around a lot in earlier discussions of Mojo 1-2 years ago, but at this rate of progress seems a bit of a pie-in-the-sky aspiration?

adgjlsfhk1 1y ago
superset of Python was never a goal. It was a talking point to try and build momentum that was quietly dropped once it served it's purpose of getting Mojo some early attention.
- fwip 1y ago
  I tend to agree, which is why I can't recommend Mojo, despite thinking their tech is pretty innovative. If they're willing to lie about something that basic, I can't trust any of their other claims.
- ModernMech 1y ago
  I hope that’s not what it was, that makes them seem very manipulative and dishonest. I was under the impression it was a goal, but they dropped it when it became apparent it was too hard. That’s much more reasonable to understand.
  - adgjlsfhk1 1y ago
    I'd agree with you if Mojo was a project by an inexperienced team, but it wasn't. Chris Latner alone has decades of PL experience and the issues with making Python fast are fundamental and well known. anyone who comes around with a sales pitch for making a portion implementation that's significantly faster than Pypy is either incredibly naive or lying
    - ModernMech 1y ago
      For me, it’s because Chris is part of the team I’m willing to give them the benefit of the doubt. I will assume ego-driven naïveté over malice. It’s not unheard of.

Shorel 1y ago

We have C++ :)

mitch_said 1y ago

[dead]