15 ms·

Mojo might be the biggest thing to happen in programming for decades

367 points by ZephyrBlu 3y ago

skybird 3y ago
[flagged]
mithrilskeleton 3y ago
How does Mojo deal with memory management? Does it have the same memory safety issues as C and C++?
- jph00 3y ago
  At the moment, you can handle memory manually with alloc/free (and there's stuff there to help with RAII), or you can use Python ref counting. Borrow-checking is currently under development, as discussed here: https://docs.modular.com/mojo/roadmap.html#ownership-and-lifetimes https://docs.modular.com/mojo/roadmap.html#ownership-and-lif...
- chrislattner 3y ago
  Mojo has a full ownership system that learned a lot from Rust and Swift and took the next step. Some details here if you're interested: https://docs.modular.com/mojo/programming-manual.html#argument-passing-control-and-memory-ownership https://docs.modular.com/mojo/programming-manual.html#argume...
sublinear 3y ago
It's a superset of python with a faster runtime. There exist dialects for other languages that seem analogous. The article introduces it with a video instead of just getting to the point and showing code. Yeah idk. Looks cool I guess.
- jph00 3y ago
  The video is a code walkthru. The code is here: https://docs.modular.com/mojo/notebooks/ https://docs.modular.com/mojo/notebooks/
jph00 3y ago
Jeremy here. Thank you for sharing my article on HN! I've used more programming languages than I can count since I started coding 40 years ago, and it's not often I've gotten really excited about a new language. So the fact I've written this should tell you how special I think Mojo is. It's early days of course - Mojo is still a prerelease, which means it's only available in an online playground and it's not open source yet (although that's planned). But for such a small team to create something like this so quickly gives me a lot of confidence for what's coming over the next few months. Let me know if you have any questions or comments.
- flufferstutter 3y ago
  [flagged]
  - rhogar 3y ago
    The broader context of the target audience of this language is very important here — it’s oriented towards the familiarity and needs of a community most comfortable with python
- tysam_and 3y ago
  Hi Jeremy, thanks for sharing this, hope it works out well. Also, thanks for doing the past work on Dawnbench&etc that y'all did. Really helped push an era of speedy deep learning to the forefront and helped stoke the flames of my passion for this particular subfield of research. FastAI really put out a ton of good work that inspired and helped me a lot. I'm generally stuck on the linear version of OneCycle, but I've referred a lot to y'all and the community over the years when building out my toolbox. In any case, you have more years under your belt than me in the software field, so I'm sure you have some of the standard skepticisms too, hopefully it works out really well. Will be keeping an eye on this software, it seems promising. Esp as I tend towards the more esoteric methods that tend to break the existing deep learning tooling out there.
  - jph00 3y ago
    I really appreciate you saying that! I'm glad it helped you.
tysam_and 3y ago
I'm pretty passionate about extremely fast deep learning tools. I like the idea, but as it goes with developers who've been burned before, I'm pretty skeptical and will probably wait and see if this ends up surviving the initial phase of testing and trying things out. I know the xkcd standards comic isn't blindly applicable to everything but still, it's not a bad prior. Peeps who know me know that I really have skin in the game too when it comes to neural network training speed and simplicity, it's something I'm quite passionate about. So something like this, if it actually works like it says it does on the tin and is usable, would be something that would be extremely useful. There's one or two kernels I'd really like to write to bump down speed records even further, and doing so directly in the language feels pretty promising to me. I really like the idea of that. And the promise of mmap-like operations too. We have pointers already in torch, they're just ad-hoc as index values, and still somehow unprotected because you have to reset your entire runtime when CUDA borks out on an out of bounds error (that only triggers the next time you try to access data.... :'( ). It would be nice if this was the real deal. I think time will tell. I hope it is.
latenightcoding 3y ago
This title is working overtime
fbdab103 3y ago
Seems like a brilliant approach. Every “better Python” language has the seemingly insurmountable bootstrapping problem of getting a critical number of libraries to get equivalently productive. Definitely going to be keeping an eye on this. If for no other reason to checkout the deployment story which is still painful after all of these years.
aledalgrande 3y ago
Is Chris the modern Dennis Ritchie? Thank you for your work Chris, insane track record!
cjbprime 3y ago
Anyone know whether the plans to open-source the language are the "in a few weeks" type of plan or the "maybe never" type of plan?
- chrisbrandow 3y ago
  The faq has similar language to the original open source plan for Swift. That was eventually open sourced. So the track record is certainly reasonable.
- chrislattner 3y ago
  Check out the FAQ: https://docs.modular.com/mojo/faq.html#distribution https://docs.modular.com/mojo/faq.html#distribution
owkman 3y ago
Jeremy has a lot of cache with me with his amazing work in education and his excitement on this is a great sign in Mojo's favor. Solving the two language problem would be pretty amazing.
- deleted 3y ago
  [deleted]
kshv_hft_abans 3y ago
This feels like a promotion/add to me, will never use it.
- miketery 3y ago
  This heuristic that ads / promotions are bad serves us well the majority of the time. In this case - yes it is a promotion (i.e. it's a blog post), but I recommend you watch the video, it seems pretty cool! Sometimes people release good products and somehow they have to communicate to us and promote it. The issue isn't the ads it's the signal to noise ratio and filter mechanisms at our disposal.
nwienert 3y ago
> 1. Mojo hasn’t actually achieved these things, and the snazzy demo hides disappointing real-life performance, or > Neither of these things are true. > The demo, in fact, was created in just a few days Not to detract from this, I'd trust anything Chris does, but anyone who follows similar projects (Truffle Ruby comes to mind) knows that it's very easy to implement a tiny subset of a highly dynamic language and make it fast, it's insanely hard to scale it all the way up to the most dynamic of behaviors. The lines above read to me as a bad sign that the author of the article isn't being very honest. It definitely is a snazzy demo hiding real life performance because one way to hide performance is to implement a very small subset and make it fast.
- chrislattner 3y ago
  Indeed, you're totally right about that. That's the trick with Mojo, our goal is not to make dynamic python magically fast. Yes, we are quite a bit faster at dynamic code (because we have compiler instead of an interpreter) but that isn't by relying on a 'sufficiently smart' compiler to remove the dynamism, it is just because "compilers" instead of "interpreters". The reason Mojo is way way faster than Python is because it give programmers control over static behavior and makes it super easy to adopt incrementally where it makes sense. The key payoff of this is that the compilation process is quite simple, there are no JITs required, you get predictable and controllable performance, and you still get dynamism where you ask for it. Mojo doesn't aim to magically make Python code faster with no work (though it does accidentally do that a little bit), Mojo gives you control so you can care about performance where you want to. 80/20 rule and all that. Mojo also has a more advanced ownership system than Rust or Swift, which is also pretty cool if you're into such things. Check out the programmer's manual here for more info: https://docs.modular.com/mojo/ https://docs.modular.com/mojo/ -Chris Lattner @ Modular
  - singularity2001 3y ago
    Since it's important to get important things right in the beginning: Please make Optional[T] as ergonomic as Swift and Kotlin with a simple '?'. Please use a general Vector pipeline instead of manual SIMD yuckness. Autotune was neat for the demo but should be hidden inside the compiler as quickly as possible. Please use 'import' to import python (and mojo dependencies with uppercase if necessary)
anylang 3y ago
It appears to be just another language. I don't see what's different about it. Anyway, it's not the languages themselves that make them big, it's the ecosystem around it that makes it big.
- MattRix 3y ago
  Isn’t that kind of the whole thing? It already has the whole python ecosystem available to it.
  - ModernMech 3y ago
    Well, we don't really know. The keynote claims it is a superset, but elsewhere they say they will strive to be a superset. So how much of a superset are they? Are there huge swaths missing? Really hard to tell at this stage from a tech demo. According to this post they've just been working on this for a short time, so a lot of their statements are defacto aspirational. Programming language lifetimes are measured in decades. They've got a long way to go.
    - MattRix 3y ago
      Ok but this is from the guy that created LLVM, Clang, and Swift… This is the real deal, he has no reason to exaggerate or lie.
      - whereuceylon 3y ago
        > but this is from the guy that created LLVM, Clang, and Swift… This is the real deal, Remember Ceylon? The language, which was supposed to be a better Java plus interoperable with Java? That was created by the guy who had created Hibernate and then Seam framework. Where is Ceylon now? People have different reasons and opinions for starting yet another language. Just because they have created something popular previously doesn't mean this is the next big thing.
        MattRix 3y ago
nielsbot 3y ago
I love this part: "The next step was to create a minimal Pythonic way to call MLIR directly. That wasn’t a big job at all, but it was all that was needed to then create all of Mojo on top of that – and work directly in Mojo for everything else. That meant that the Mojo devs were able to “dog-food” Mojo when writing Mojo, nearly from the very start. Any time they found something didn’t quite work great as they developed Mojo, they could add a needed feature to Mojo itself to make it easier for them to develop the next bit of Mojo! This is very similar to Julia, which was developed on a minimal LISP-like core that provides the Julia language elements, which are then bound to basic LLVM operations. Nearly everything in Julia is built on top of that, using Julia itself." I've always wanted to create a new language (probably visual) where the implementation of that language is open to be extended and changed right in the same context as where you use that language. A readily-accessible trap down to the next lower level of abstraction. I suspect this leads to more "expressivity" while being less code overall. Sounds like Julia (as mentioned) as proven this is true and perhaps Mojo too.
- amscanne 3y ago
  > I've always wanted to create a new language (probably visual) where the implementation of that language is open to be extended and changed right in the same context as where you use that language. A readily-accessible trap down to the next lower level of abstraction. I suspect this leads to more "expressivity" while being less code overall. It sounds like you would find Self [1] interesting (along with the visual programming environment). [1] https://en.wikipedia.org/wiki/Self_(programming_language) https://en.wikipedia.org/wiki/Self_(programming_language)
  - nielsbot 3y ago
    Yes, Self is very cool--I've read about it before.
zonkdefunk 3y ago
Nice article. However you mentioned in the other post that you are an advisor to Modular, so maybe it should be regarded an advertisement.
- jph00 3y ago
  I didn't get paid to write this article, and no-one at Modular asked me to write it, and I don't have any equity in Modular so there's no financial upside in me writing it. I agreed to become an advisor to Modular after I saw what they're working on and thought it looked great.
  - mpweiher 3y ago
    Still a massive conflict of interest that should be declared.
    - jack_riminton 3y ago
      He does. It says in the sidebar "I’m an advisor to Modular"
    - 55555 3y ago
      It’s declared in a footnote.
dmonitor 3y ago
unrelated to the contents of the article, but does anyone else struggle reading this light-grey text on white background?
- jph00 3y ago
  Oh yes you're right - I've just pushed a change to make it darker.
blueblimp 3y ago
It seems to me that right now is an especially awkward time to launch a new programming language competing with Python, because LLMs are great at writing Python, and presumably can't write your new language at all (since there's no data for it yet). The linked post does not seem to address this.
- dagmx 3y ago
  Mojo consumes python so it can build on that. However that assumes that LLMs are a significant part of new written code (unlikely), or a significant learning source (maybe) and can’t be adapted to mojo (they probably will be)
- singularity2001 3y ago
  Python Type notations are already part of the learning corpus and can probably be generalized to Mojo. many specifics are probably almost one short learning. LLMs can easily adopt new styles once the general model is 'understood'
- ModernMech 3y ago
  You'd think this, but ChatGPT is able to write code in my programming language after I feed it just a few examples. It's not perfect, but it knows enough about adjacent language that it can actually write pretty good code in my language. The problem is you have to keep reminding it about the language fundamentals, or it will start making things up as your prompts get further and further from the first examples.
- ezekiel68 3y ago
  I can't but respond that this seems like the very least compelling reason not to innovate on computer language design & implementation.
fuzzythinker 3y ago
"Maybe it’s better to say Mojo is Python++" I think this is a great analogy that will get more developers to make the connection. I've read all the "why" and all but this phrasing really sinks in for me.
ftxbro 3y ago
So is this more like Matlab or more like Python, in the legal and organizational ways? I don't know the right words for it so I'm not going to say "free" or "open source" but maybe you know what I mean.
vsskanth 3y ago
I think static compilation like C++ or rust is important to overcome the two language problem. That will be the biggest advantage over Julia. Unclear if Mojo can do this or if it is planned.
- jph00 3y ago
  It can do this.
  - vsskanth 3y ago
    Thanks for clarifying
andrewstuart 3y ago
The two biggest things that have happened in programming for decades are: 1: StackOverflow 2: ChatGPT Nothing else comes close. Certainly not any new language. WHY these two things are the biggest developments in programming is because they help developers solve problems and learn new things from a global accumulation of programmer knowledge. If there was a Nobel Prize for computing then both StackOverflow and ChatGPT would be deserving of it, or the people behind them anyway.
- echelon 3y ago
  StackOverflow is just expertsexchange without the dark patterns. An incremental improvement with an enormous impact.
  - MattPalmer1086 3y ago
    And without the unfortunate way to misread the word boundaries in expertsexchange!
    - davidjones332 3y ago
      [dead]
  - andrewstuart 3y ago
    And Google is just Alta vista a bit different
- tgma 3y ago
  This. I am actually super interested and positive about Mojo but I can't take the title seriously. Not even close. As is, it is basically a yet another new (completely distinct language from Python) that looks and feels kind of like Python and hopes to convert a bunch of users, but is not really Python, and embeds CPython in the same way that Swift (4TF) could already do (and a lot of random software also do to use Python as their scripting engine.)
- jph00 3y ago
nbittich 3y ago
Yet another (over hyped) llvm programming language. Remember when JavaScript framework fatigue was a thing?
sva_ 3y ago
I understand that there might be some benefit in developing Mojo in a small group. But I really wish there were some source code to compile, or at least binaries to execute. Currently it is locked behind a wait-list that might give access to executing code on a remote server... But if you make these big claims about hardware acceleration and performance, I really wish I could verify those claims on my own hardware. Really cool project, looking up to tinkering with some actual releases soon. I know the names behind this project are highly credible, but I'm reluctant to invest much brainpower into something that might be locked up to cloud usage.
- chrislattner 3y ago
  We're not in a rush here, we'd rather do things right than do things fast. Mojo is currently one day old :-) We are deliberately rolling things out in a slow way to learn as we go. We're also eager for it to go far and wide, but think it makes sense to be a bit deliberate about that. When we launched Swift 1.0 it was more like a 0.5 and that started things off on the wrong foot. Mojo is still early in development, not ready for widespread production use. -Chris Lattner @ Modular
novok 3y ago
After my experience with swift and the bone headed decisions made in lower level design items of the language to make it more 'ergonomic' at the expense of compile speed and debug-ability, I worry about chris latner making the same mistakes again. Swift literally took 10x more time to compile than equivalent objective-c code for not much benefit when it first came out, along with a debugger that to this day is significantly slower, unreliable and is still buggier than the objective-c one. It also does not scale linearly in compile time speed when you throw more cores to it, unlike c, c++ & objective-c, and linking is pretty much solved now with the mold linker. There are / were huge chokepoints in the compiling chain that caused many of these regressions, that when I learned the minor benefits they brought made me do a facepalm. So many literal expensive megayears of life wasted for so little benefit. %80 of the benefits of swift that were cheap to implement could've been ported over something equivalent to objective-c for little to no compile time penalties with the new ergonomic language syntax, such as strong nullables and enum ADT types. To this day, it's you still have to codegen mocks. It's frustrating. I would wait and see what benefits that mojo will actually bring, and I hope that chris and the team there has learned from their mistakes with swift, and chose compile speed over little features that many could live without. I also hope they use this as an opportunity to solve pythons horrible package management issue and copy ideas from rust's cargo liberally.
- chrislattner 3y ago
  I have literally the same experience about slow and overly complex type systems and too much sugar as you're pointing out. I've learned a lot from it, and the conclusion is "don't do it again". You can see a specific comment about this at the end of this section: https://docs.modular.com/mojo/notebooks/HelloMojo.html#overloaded-functions-methods https://docs.modular.com/mojo/notebooks/HelloMojo.html#overl... ``` Mojo doesn’t support overloading solely on result type, and doesn’t use result type or contextual type information for type inference, keeping things simple, fast, and predictable. Mojo will never produce an “expression too complex” error, because its type-checker is simple and fast by definition. ``` It's also interesting that Rust et al made similar (but also different) mistakes and have compile time issues scaling. Mojo has a ton of core compiler improvements as well addressing the "LLVM is slow" sorts of issues that "zero abstraction" languages have when expecting LLVM to do all the work for them. -Chris Lattner @ Modular
FileSorter 3y ago
I really hate python's lack of curly braces. It makes code so much more unreadable, copy+paste error prone, etc. Would be nice if this new language made them optional so new code could could be written with them.
- adql 3y ago
  I prefer "One way to format everything", it just cuts so much needless whining if everyone just uses same formatter with little to no settings. ... and having curly bracers instead of the whitespace nonsense. Using invisible characters as flow control was never good idea.
xyproto 3y ago
I wish the article would also mention Nim, a Python-like language that compiles to native, and compare it to Mojo. Also, this isn't quite correct: > There is also the approach taken by Go, which isn’t able to generate small applications like C, but instead incorporates a “runtime” into each packaged application. This approach is a compromise between Python and C, still requiring tens of megabytes for a binary, but providing for easier deployment than Python. Compiling Go with gccgo instead of the Go compiler, and with the right flags, results in a much smaller executable. It is also possible to further compress the executable with upx. This command should result in executables around 0.5 to 1.5 MiB in size, on Linux (depending on the size of the Go project): go build -mod=vendor -gccgoflags '-Os -s' -o prog && upx --best --lzma prog
- ziotom78 3y ago
  > I wish the article would also mention Nim, a Python-like language that compiles to native, and compare it to Mojo. I would not say that Nim is “a Python-like language”. The only significant similarity is in the usage of indentation instead of curly brackets. To me, it is much more similar to Pascal/Ada/Oberon, but less verbose.
  - xyproto 3y ago
    I have not programmed much in Nim, and I think you are mostly right, but Nim also have keywords and concepts not found in Pascal/Ada/Oberon that clearly comes from Python, like "yield" and iterators: iterator iota(n: int): int = for i in 0..<n: yield i
    - Erwin 3y ago
      I think the 1977 Icon language is where the generator concept originated. It had many other cool features I have not seen in other languages since: https://en.wikipedia.org/wiki/Icon_(programming_language)# https://en.wikipedia.org/wiki/Icon_(programming_language)#
esjeon 3y ago
The title is obviously too hyperbolic, as the article itself doesn't even try to back the claim. It's just a good introduction piece. (The official doc is a little bit too scattered to read through.) Although I like the basic concept, it feels awkward that the engine is bound to the language, which by itself is also bound to a specific domain. Unless Mojo becomes fully compatible with CPython, the language will be just another DSL, which won't get adopted widely. Worse, MLOps is already a huge mess, so I can't imagine migrating to a language with limited usages.
cavisne 3y ago
Is MLIR a “huge success?” Is it involved at all in the Python ->PyTorch -> nvidia gpu path that dominates ml today?
mpweiher 3y ago
Those who don't understand Objective-C are doomed to reinvent it. Badly. Not that Objective-C is perfect, far from it. But it had the right approach, and already does the things that are claimed as the huge innovation here "out of the box". Already did them in 1984. And without the millions of lines of compiler code and ridiculous compile times, bordering on the absurd.
- mcphage 3y ago
  > Those who don't understand Objective-C are doomed to reinvent it. Badly. I feel Chris Lattner can make a reasonable claim as to understanding Objective-C.
  - mpweiher 3y ago
    You would think so, yes, and given the circumstantial evidence, your feeling is a perfectly excusable mistake to make. Disclaimer: I worked with Chris at Apple and have the utmost respect for him both as a person and for his abilities as both an engineer and manager. And he wasn't the Apple engineering manager in charge of Objective-C who started a discussion we were going to have with the words: "Objective-C is a statically typesafe language and this is unarguable". Now one half of that sentence is true. The other is laughably wrong. I have a hard time thinking of a language that is less statically typesafe than Objective-C. We didn't have the discussion, because continuing the conversation after that tiny bombshell is pretty pointless. A lot of people at Apple did not understand Objective-C, many thought of Objective-C as at best a maladjusted Java. And it is. That is, if you make the wrong assumption that it is trying to be some sort of Java in the first place, or you misuse it that way. But it's not. It's a 1984 solution to the two-language problem. The component language being C and the composition language being Smalltalk. Jam them into one language and you've solved most of the boundary problems. Now you've obviously also created a bunch of problems, but you solved that one. When Swift came out, everything about it reeked of "we don't understand Objective-C", including the ridiculously wrong tag-line "Objective-C without the C". It's a better C++ that basically ignores the Smalltalk part in the hope that the larger-scale composition problems that the composition language tries to solve will just go away. And of course Smalltalk also wasn't really a good enough composition language either, because it's still essentially procedural. We need more flexibility in our composition languages [1]. And the composition language being so close to the component language probably led people to make those mistakes of treating them as a a maladjusted unitary language, using the composition part for component programming etc. Anyway, coming back to the understanding part: I've followed the Swift creators wherever they've talked or written about the language, the design rationales etc. And over time, what was only a sneaking suspicion became a grim certainty: they did not understand Objective-C, and did not even believe that understanding it was necessary. This did come as a bit of a shock to me, because despite that sneaking suspicion, it just didn't seem possible. [1] https://news.ycombinator.com/item?id=35318258 https://news.ycombinator.com/item?id=35318258 (linking to HN discussion, my domain is currently in transition)
pjmlp 3y ago
Lets see if this doesn't turn out to be yet another "Swift for Tensorflow", remember when fast.ai used to say the same about it?
- zengid 3y ago
  I agree that Jeremy was excited about Swift being a possible option for solving the "two languages" problem, but to be fair there weren't many options for ML programmers at the time. Also, I think "Swift for Tensorflow" was doomed from the start. Swift doesn't really exist outside of Apple's ecosystem, and it was competing with Python which is everywhere, and was a top 5 language even then. Making a superset of Python is a winning strategy because people can try it out and walk away if they don't like it without much effort. It worked for C-with-classes (which became C++) and Typescript, even though it took a little while for them to gain popularity and mass adoption.
ianpurton 3y ago
How does the MLIR that Mojo generates differ from https://openxla.github.io/iree/ https://openxla.github.io/iree/ Or does Mojo sit on top of iree? Will the inference engine support multi GPU setups?
krp 3y ago
This looks potentially really cool. Thanks Jeremy for the demo and Chris (et al?) for creating it.
devwastaken 3y ago
I was thinking about this idea the other day - python++, but with a diverse standard library for everything. I should never have to look up a function that turns a textual IP address into a form I can work with. I should not have to really even do a normal for loop to transform data. If it's something everyone would have to write a function for, why not pre make it.
poulpy123 3y ago
It's interesting to read but I'm not very convinced by the added value compared to using Cython, building modules in fortran or C, or using interop with rust or nim. Especially I think the need to manage memory manually and not be able to use a GC (or some other automatic memory managment) is a mistake. While I understand that you may need to manage the memory manually to squeeze the maximum performances in some cases, the performance degradation shown in benchmark by D, nim, Julia or C# shows that you can have a very good compromise between speed and easyness with autmatic memory management
ElfinTrousers 3y ago
"Python but with better performance" is a faster horse, not a car.
deleted 3y ago
[deleted]
faitswulff 3y ago
What’s the dependency story with Mojo, especially considering Python’s less than stellar dependency situation?
PurpleRamen 3y ago
So if the big trick is using optional strong typing, couldn't CPython just do the same? And syntax for type hints is stable enough now, that there would be only little changes necessary on the front. It will likely not give the same level of speedup as Mojos new runtime delivers, but could there be at least some significant boost possible which would make in impact?
- sicariusnoctis 3y ago
  I guess JIT type specialization / "monomorphization" might be one way to do it, but I expect that it would be bottlenecked by all the surrounding CPython interpreter stuff. /amateur_two_cents
antimora 3y ago
To get around Python's limitations and complexity of C++, here is a Rust based DL framework we are developing, called Burn: https://github.com/burn-rs/burn https://github.com/burn-rs/burn. The super cool thing about Burn is that you can swap backends easily.
- gautamcgoel 3y ago
  This is OT, but what does your username mean? I found this: https://en.wikipedia.org/wiki/Antimora https://en.wikipedia.org/wiki/Antimora Are you named after a species of cod?
deleted 3y ago
[deleted]
gavin_gee 3y ago
what are the benefits of Mojo over Apache TVM and OctoML?
stratigos 3y ago
Meanwhile, in the Erlang universe ... ;-)
jetzzz 3y ago
They are promoting tightly packed structs as fast. For high-performance language I would expect native struct-of-arrays support because structs are bad for CPU cache and SIMD.
zoogeny 3y ago
Mojo looks extremely promising. Lattner has some hits and misses but in general I find myself agreeing with him on principles. A brief skim of MLIR is interesting as well and I can understand it's goals and how it fits into the LLVM ecosystem. Python is is a pleasant language to use and it has a massive and growing ecosystem. This combination of a stellar tech leader, a clear defined technical goal built within and on top of an existing powerful compiler platform/framework, a popular and beautiful language foundation including a huge library of existing performant code, and impressive performance claims - this all adds up to something worth paying close attention to. Some random thoughts: After watching tutorials on PyTorch I've come to the conclusion that new programming languages must have syntax built in for dealing with tensors/matrices. The flexible array index syntax in Python allows for some nice ergonomics for this but I have a feeling that we are just scratching the surface. I understand that they don't have a public release nor a license - but I would like some more clarity on this before becoming more invested. Just saying "open source sometime soon" is a bit vague. I worry about the eventual divergence these kinds of projects make from their source. Inevitably there will be a day when Python moves in a new direction that won't be compatible with Mojo. Will they remain tethered to Python on that day or will they feel sufficiently independent to go it alone? I was very excited by Swift as a language. I was excited when Apple open sourced it. I was excited when Google was using it for TensorFlow. But it feels stalled out somehow. I don't understand the dynamics of language growth and adoption well enough to make predictions. If I were to start a new ML company today I don't know how comfortable I would be choosing Mojo over Python. Just having the current backing of a business will not guarantee success. Will this language offer enough to attract Python, C++, Rust, Julia, etc. devs over? They talk about deployment story ... but there is competition there as well in things like WASM. There are more ways to fail than there are to succeed - and I wish something like this would succeed but reality is so fickle.
zengid 3y ago
When a new language project like this drops I always feel like a kid on Christmas morning (or whatever your favorite gift-giving holiday is). I've wanted to see a general purpose language build on top of MLIR since it came out and I think this is a great way to do it, since Python is the main client for advances in ML accelerators. Treating the CPU as a target for acceleration is brilliant to. I deeply hope that this language will give general purpose programming languages a huge step forward in taking advantage of our current heterogenous-compute world. Bravo!
local_crmdgeon 3y ago
This statement isn't borne out by the article. The biggest advance in language design has been gradient typing, the biggest advance in tooling is LLMs. This is a reworking of Python.
interactivecode 3y ago
Honestly without a UI framework programming languages are kinda useless. Ecosystem is key to day to day usefulness compile time is secondary to that.
- anaganisk 3y ago
  Why do you want to write UIs with every programming language? I'm curious since, not every language is suited for it or not the use case at all.
doublejames 3y ago
[dead]
MR4D 3y ago
Looking forward to running flask on mojo some day. Would be neat to see it with the structs instead of classes, and fn's instead of def's.
terrycody 3y ago
Another good news for a python wanna-be newbie like me, another reason to choose Python, then later/future I can choose Mojo for performance related, ease to upgrade since its Python superset.
math_dandy 3y ago
Who's working on a Mojo equivalent for Javascript?

367 points by ZephyrBlu 3y ago

skybird 3y ago

[flagged]

mithrilskeleton 3y ago

How does Mojo deal with memory management? Does it have the same memory safety issues as C and C++?

jph00 3y ago
At the moment, you can handle memory manually with alloc/free (and there's stuff there to help with RAII), or you can use Python ref counting. Borrow-checking is currently under development, as discussed here: https://docs.modular.com/mojo/roadmap.html#ownership-and-lifetimes https://docs.modular.com/mojo/roadmap.html#ownership-and-lif...
chrislattner 3y ago
Mojo has a full ownership system that learned a lot from Rust and Swift and took the next step. Some details here if you're interested: https://docs.modular.com/mojo/programming-manual.html#argument-passing-control-and-memory-ownership https://docs.modular.com/mojo/programming-manual.html#argume...

sublinear 3y ago

It's a superset of python with a faster runtime. There exist dialects for other languages that seem analogous. The article introduces it with a video instead of just getting to the point and showing code. Yeah idk. Looks cool I guess.

jph00 3y ago
The video is a code walkthru. The code is here: https://docs.modular.com/mojo/notebooks/ https://docs.modular.com/mojo/notebooks/

jph00 3y ago

Jeremy here. Thank you for sharing my article on HN! I've used more programming languages than I can count since I started coding 40 years ago, and it's not often I've gotten really excited about a new language. So the fact I've written this should tell you how special I think Mojo is. It's early days of course - Mojo is still a prerelease, which means it's only available in an online playground and it's not open source yet (although that's planned). But for such a small team to create something like this so quickly gives me a lot of confidence for what's coming over the next few months. Let me know if you have any questions or comments.

flufferstutter 3y ago
[flagged]
- rhogar 3y ago
  The broader context of the target audience of this language is very important here — it’s oriented towards the familiarity and needs of a community most comfortable with python
tysam_and 3y ago
Hi Jeremy, thanks for sharing this, hope it works out well. Also, thanks for doing the past work on Dawnbench&etc that y'all did. Really helped push an era of speedy deep learning to the forefront and helped stoke the flames of my passion for this particular subfield of research. FastAI really put out a ton of good work that inspired and helped me a lot. I'm generally stuck on the linear version of OneCycle, but I've referred a lot to y'all and the community over the years when building out my toolbox. In any case, you have more years under your belt than me in the software field, so I'm sure you have some of the standard skepticisms too, hopefully it works out really well. Will be keeping an eye on this software, it seems promising. Esp as I tend towards the more esoteric methods that tend to break the existing deep learning tooling out there.
- jph00 3y ago
  I really appreciate you saying that! I'm glad it helped you.

tysam_and 3y ago

I'm pretty passionate about extremely fast deep learning tools. I like the idea, but as it goes with developers who've been burned before, I'm pretty skeptical and will probably wait and see if this ends up surviving the initial phase of testing and trying things out. I know the xkcd standards comic isn't blindly applicable to everything but still, it's not a bad prior. Peeps who know me know that I really have skin in the game too when it comes to neural network training speed and simplicity, it's something I'm quite passionate about. So something like this, if it actually works like it says it does on the tin and is usable, would be something that would be extremely useful. There's one or two kernels I'd really like to write to bump down speed records even further, and doing so directly in the language feels pretty promising to me. I really like the idea of that. And the promise of mmap-like operations too. We have pointers already in torch, they're just ad-hoc as index values, and still somehow unprotected because you have to reset your entire runtime when CUDA borks out on an out of bounds error (that only triggers the next time you try to access data.... :'( ). It would be nice if this was the real deal. I think time will tell. I hope it is.

latenightcoding 3y ago

This title is working overtime

fbdab103 3y ago

Seems like a brilliant approach. Every “better Python” language has the seemingly insurmountable bootstrapping problem of getting a critical number of libraries to get equivalently productive. Definitely going to be keeping an eye on this. If for no other reason to checkout the deployment story which is still painful after all of these years.

aledalgrande 3y ago

Is Chris the modern Dennis Ritchie? Thank you for your work Chris, insane track record!

cjbprime 3y ago

Anyone know whether the plans to open-source the language are the "in a few weeks" type of plan or the "maybe never" type of plan?

chrisbrandow 3y ago
The faq has similar language to the original open source plan for Swift. That was eventually open sourced. So the track record is certainly reasonable.
chrislattner 3y ago
Check out the FAQ: https://docs.modular.com/mojo/faq.html#distribution https://docs.modular.com/mojo/faq.html#distribution

owkman 3y ago

Jeremy has a lot of cache with me with his amazing work in education and his excitement on this is a great sign in Mojo's favor. Solving the two language problem would be pretty amazing.

deleted 3y ago
[deleted]

kshv_hft_abans 3y ago

This feels like a promotion/add to me, will never use it.

miketery 3y ago
This heuristic that ads / promotions are bad serves us well the majority of the time. In this case - yes it is a promotion (i.e. it's a blog post), but I recommend you watch the video, it seems pretty cool! Sometimes people release good products and somehow they have to communicate to us and promote it. The issue isn't the ads it's the signal to noise ratio and filter mechanisms at our disposal.

nwienert 3y ago

> 1. Mojo hasn’t actually achieved these things, and the snazzy demo hides disappointing real-life performance, or > Neither of these things are true. > The demo, in fact, was created in just a few days Not to detract from this, I'd trust anything Chris does, but anyone who follows similar projects (Truffle Ruby comes to mind) knows that it's very easy to implement a tiny subset of a highly dynamic language and make it fast, it's insanely hard to scale it all the way up to the most dynamic of behaviors. The lines above read to me as a bad sign that the author of the article isn't being very honest. It definitely is a snazzy demo hiding real life performance because one way to hide performance is to implement a very small subset and make it fast.

chrislattner 3y ago
Indeed, you're totally right about that. That's the trick with Mojo, our goal is not to make dynamic python magically fast. Yes, we are quite a bit faster at dynamic code (because we have compiler instead of an interpreter) but that isn't by relying on a 'sufficiently smart' compiler to remove the dynamism, it is just because "compilers" instead of "interpreters". The reason Mojo is way way faster than Python is because it give programmers control over static behavior and makes it super easy to adopt incrementally where it makes sense. The key payoff of this is that the compilation process is quite simple, there are no JITs required, you get predictable and controllable performance, and you still get dynamism where you ask for it. Mojo doesn't aim to magically make Python code faster with no work (though it does accidentally do that a little bit), Mojo gives you control so you can care about performance where you want to. 80/20 rule and all that. Mojo also has a more advanced ownership system than Rust or Swift, which is also pretty cool if you're into such things. Check out the programmer's manual here for more info: https://docs.modular.com/mojo/ https://docs.modular.com/mojo/ -Chris Lattner @ Modular
- singularity2001 3y ago
  Since it's important to get important things right in the beginning: Please make Optional[T] as ergonomic as Swift and Kotlin with a simple '?'. Please use a general Vector pipeline instead of manual SIMD yuckness. Autotune was neat for the demo but should be hidden inside the compiler as quickly as possible. Please use 'import' to import python (and mojo dependencies with uppercase if necessary)

anylang 3y ago

It appears to be just another language. I don't see what's different about it. Anyway, it's not the languages themselves that make them big, it's the ecosystem around it that makes it big.

MattRix 3y ago
Isn’t that kind of the whole thing? It already has the whole python ecosystem available to it.
- ModernMech 3y ago
  Well, we don't really know. The keynote claims it is a superset, but elsewhere they say they will strive to be a superset. So how much of a superset are they? Are there huge swaths missing? Really hard to tell at this stage from a tech demo. According to this post they've just been working on this for a short time, so a lot of their statements are defacto aspirational. Programming language lifetimes are measured in decades. They've got a long way to go.
  - MattRix 3y ago
    Ok but this is from the guy that created LLVM, Clang, and Swift… This is the real deal, he has no reason to exaggerate or lie.
    - whereuceylon 3y ago
      > but this is from the guy that created LLVM, Clang, and Swift… This is the real deal, Remember Ceylon? The language, which was supposed to be a better Java plus interoperable with Java? That was created by the guy who had created Hibernate and then Seam framework. Where is Ceylon now? People have different reasons and opinions for starting yet another language. Just because they have created something popular previously doesn't mean this is the next big thing.
      - MattRix 3y ago

nielsbot 3y ago

I love this part: "The next step was to create a minimal Pythonic way to call MLIR directly. That wasn’t a big job at all, but it was all that was needed to then create all of Mojo on top of that – and work directly in Mojo for everything else. That meant that the Mojo devs were able to “dog-food” Mojo when writing Mojo, nearly from the very start. Any time they found something didn’t quite work great as they developed Mojo, they could add a needed feature to Mojo itself to make it easier for them to develop the next bit of Mojo! This is very similar to Julia, which was developed on a minimal LISP-like core that provides the Julia language elements, which are then bound to basic LLVM operations. Nearly everything in Julia is built on top of that, using Julia itself." I've always wanted to create a new language (probably visual) where the implementation of that language is open to be extended and changed right in the same context as where you use that language. A readily-accessible trap down to the next lower level of abstraction. I suspect this leads to more "expressivity" while being less code overall. Sounds like Julia (as mentioned) as proven this is true and perhaps Mojo too.

amscanne 3y ago
> I've always wanted to create a new language (probably visual) where the implementation of that language is open to be extended and changed right in the same context as where you use that language. A readily-accessible trap down to the next lower level of abstraction. I suspect this leads to more "expressivity" while being less code overall. It sounds like you would find Self [1] interesting (along with the visual programming environment). [1] https://en.wikipedia.org/wiki/Self_(programming_language) https://en.wikipedia.org/wiki/Self_(programming_language)
- nielsbot 3y ago
  Yes, Self is very cool--I've read about it before.

zonkdefunk 3y ago

Nice article. However you mentioned in the other post that you are an advisor to Modular, so maybe it should be regarded an advertisement.

jph00 3y ago
I didn't get paid to write this article, and no-one at Modular asked me to write it, and I don't have any equity in Modular so there's no financial upside in me writing it. I agreed to become an advisor to Modular after I saw what they're working on and thought it looked great.
- mpweiher 3y ago
  Still a massive conflict of interest that should be declared.
  - jack_riminton 3y ago
    He does. It says in the sidebar "I’m an advisor to Modular"
  - 55555 3y ago
    It’s declared in a footnote.

dmonitor 3y ago

unrelated to the contents of the article, but does anyone else struggle reading this light-grey text on white background?

jph00 3y ago
Oh yes you're right - I've just pushed a change to make it darker.

blueblimp 3y ago

It seems to me that right now is an especially awkward time to launch a new programming language competing with Python, because LLMs are great at writing Python, and presumably can't write your new language at all (since there's no data for it yet). The linked post does not seem to address this.

dagmx 3y ago
Mojo consumes python so it can build on that. However that assumes that LLMs are a significant part of new written code (unlikely), or a significant learning source (maybe) and can’t be adapted to mojo (they probably will be)
singularity2001 3y ago
Python Type notations are already part of the learning corpus and can probably be generalized to Mojo. many specifics are probably almost one short learning. LLMs can easily adopt new styles once the general model is 'understood'
ModernMech 3y ago
You'd think this, but ChatGPT is able to write code in my programming language after I feed it just a few examples. It's not perfect, but it knows enough about adjacent language that it can actually write pretty good code in my language. The problem is you have to keep reminding it about the language fundamentals, or it will start making things up as your prompts get further and further from the first examples.
ezekiel68 3y ago
I can't but respond that this seems like the very least compelling reason not to innovate on computer language design & implementation.

fuzzythinker 3y ago

"Maybe it’s better to say Mojo is Python++" I think this is a great analogy that will get more developers to make the connection. I've read all the "why" and all but this phrasing really sinks in for me.

ftxbro 3y ago

So is this more like Matlab or more like Python, in the legal and organizational ways? I don't know the right words for it so I'm not going to say "free" or "open source" but maybe you know what I mean.

vsskanth 3y ago

I think static compilation like C++ or rust is important to overcome the two language problem. That will be the biggest advantage over Julia. Unclear if Mojo can do this or if it is planned.

jph00 3y ago
It can do this.
- vsskanth 3y ago
  Thanks for clarifying

andrewstuart 3y ago

The two biggest things that have happened in programming for decades are: 1: StackOverflow 2: ChatGPT Nothing else comes close. Certainly not any new language. WHY these two things are the biggest developments in programming is because they help developers solve problems and learn new things from a global accumulation of programmer knowledge. If there was a Nobel Prize for computing then both StackOverflow and ChatGPT would be deserving of it, or the people behind them anyway.

echelon 3y ago
StackOverflow is just expertsexchange without the dark patterns. An incremental improvement with an enormous impact.
- MattPalmer1086 3y ago
  And without the unfortunate way to misread the word boundaries in expertsexchange!
  - davidjones332 3y ago
    [dead]
- andrewstuart 3y ago
  And Google is just Alta vista a bit different
tgma 3y ago
This. I am actually super interested and positive about Mojo but I can't take the title seriously. Not even close. As is, it is basically a yet another new (completely distinct language from Python) that looks and feels kind of like Python and hopes to convert a bunch of users, but is not really Python, and embeds CPython in the same way that Swift (4TF) could already do (and a lot of random software also do to use Python as their scripting engine.)
jph00 3y ago

nbittich 3y ago

Yet another (over hyped) llvm programming language. Remember when JavaScript framework fatigue was a thing?

sva_ 3y ago

I understand that there might be some benefit in developing Mojo in a small group. But I really wish there were some source code to compile, or at least binaries to execute. Currently it is locked behind a wait-list that might give access to executing code on a remote server... But if you make these big claims about hardware acceleration and performance, I really wish I could verify those claims on my own hardware. Really cool project, looking up to tinkering with some actual releases soon. I know the names behind this project are highly credible, but I'm reluctant to invest much brainpower into something that might be locked up to cloud usage.

chrislattner 3y ago
We're not in a rush here, we'd rather do things right than do things fast. Mojo is currently one day old :-) We are deliberately rolling things out in a slow way to learn as we go. We're also eager for it to go far and wide, but think it makes sense to be a bit deliberate about that. When we launched Swift 1.0 it was more like a 0.5 and that started things off on the wrong foot. Mojo is still early in development, not ready for widespread production use. -Chris Lattner @ Modular

novok 3y ago

After my experience with swift and the bone headed decisions made in lower level design items of the language to make it more 'ergonomic' at the expense of compile speed and debug-ability, I worry about chris latner making the same mistakes again. Swift literally took 10x more time to compile than equivalent objective-c code for not much benefit when it first came out, along with a debugger that to this day is significantly slower, unreliable and is still buggier than the objective-c one. It also does not scale linearly in compile time speed when you throw more cores to it, unlike c, c++ & objective-c, and linking is pretty much solved now with the mold linker. There are / were huge chokepoints in the compiling chain that caused many of these regressions, that when I learned the minor benefits they brought made me do a facepalm. So many literal expensive megayears of life wasted for so little benefit. %80 of the benefits of swift that were cheap to implement could've been ported over something equivalent to objective-c for little to no compile time penalties with the new ergonomic language syntax, such as strong nullables and enum ADT types. To this day, it's you still have to codegen mocks. It's frustrating. I would wait and see what benefits that mojo will actually bring, and I hope that chris and the team there has learned from their mistakes with swift, and chose compile speed over little features that many could live without. I also hope they use this as an opportunity to solve pythons horrible package management issue and copy ideas from rust's cargo liberally.

chrislattner 3y ago
I have literally the same experience about slow and overly complex type systems and too much sugar as you're pointing out. I've learned a lot from it, and the conclusion is "don't do it again". You can see a specific comment about this at the end of this section: https://docs.modular.com/mojo/notebooks/HelloMojo.html#overloaded-functions-methods https://docs.modular.com/mojo/notebooks/HelloMojo.html#overl... ``` Mojo doesn’t support overloading solely on result type, and doesn’t use result type or contextual type information for type inference, keeping things simple, fast, and predictable. Mojo will never produce an “expression too complex” error, because its type-checker is simple and fast by definition. ``` It's also interesting that Rust et al made similar (but also different) mistakes and have compile time issues scaling. Mojo has a ton of core compiler improvements as well addressing the "LLVM is slow" sorts of issues that "zero abstraction" languages have when expecting LLVM to do all the work for them. -Chris Lattner @ Modular

FileSorter 3y ago

I really hate python's lack of curly braces. It makes code so much more unreadable, copy+paste error prone, etc. Would be nice if this new language made them optional so new code could could be written with them.

adql 3y ago
I prefer "One way to format everything", it just cuts so much needless whining if everyone just uses same formatter with little to no settings. ... and having curly bracers instead of the whitespace nonsense. Using invisible characters as flow control was never good idea.

xyproto 3y ago

I wish the article would also mention Nim, a Python-like language that compiles to native, and compare it to Mojo. Also, this isn't quite correct: > There is also the approach taken by Go, which isn’t able to generate small applications like C, but instead incorporates a “runtime” into each packaged application. This approach is a compromise between Python and C, still requiring tens of megabytes for a binary, but providing for easier deployment than Python. Compiling Go with gccgo instead of the Go compiler, and with the right flags, results in a much smaller executable. It is also possible to further compress the executable with upx. This command should result in executables around 0.5 to 1.5 MiB in size, on Linux (depending on the size of the Go project): go build -mod=vendor -gccgoflags '-Os -s' -o prog && upx --best --lzma prog

ziotom78 3y ago
> I wish the article would also mention Nim, a Python-like language that compiles to native, and compare it to Mojo. I would not say that Nim is “a Python-like language”. The only significant similarity is in the usage of indentation instead of curly brackets. To me, it is much more similar to Pascal/Ada/Oberon, but less verbose.
- xyproto 3y ago
  I have not programmed much in Nim, and I think you are mostly right, but Nim also have keywords and concepts not found in Pascal/Ada/Oberon that clearly comes from Python, like "yield" and iterators: iterator iota(n: int): int = for i in 0..<n: yield i
  - Erwin 3y ago
    I think the 1977 Icon language is where the generator concept originated. It had many other cool features I have not seen in other languages since: https://en.wikipedia.org/wiki/Icon_(programming_language)# https://en.wikipedia.org/wiki/Icon_(programming_language)#

esjeon 3y ago

The title is obviously too hyperbolic, as the article itself doesn't even try to back the claim. It's just a good introduction piece. (The official doc is a little bit too scattered to read through.) Although I like the basic concept, it feels awkward that the engine is bound to the language, which by itself is also bound to a specific domain. Unless Mojo becomes fully compatible with CPython, the language will be just another DSL, which won't get adopted widely. Worse, MLOps is already a huge mess, so I can't imagine migrating to a language with limited usages.

cavisne 3y ago

Is MLIR a “huge success?” Is it involved at all in the Python ->PyTorch -> nvidia gpu path that dominates ml today?

mpweiher 3y ago

Those who don't understand Objective-C are doomed to reinvent it. Badly. Not that Objective-C is perfect, far from it. But it had the right approach, and already does the things that are claimed as the huge innovation here "out of the box". Already did them in 1984. And without the millions of lines of compiler code and ridiculous compile times, bordering on the absurd.

mcphage 3y ago
> Those who don't understand Objective-C are doomed to reinvent it. Badly. I feel Chris Lattner can make a reasonable claim as to understanding Objective-C.
- mpweiher 3y ago
  You would think so, yes, and given the circumstantial evidence, your feeling is a perfectly excusable mistake to make. Disclaimer: I worked with Chris at Apple and have the utmost respect for him both as a person and for his abilities as both an engineer and manager. And he wasn't the Apple engineering manager in charge of Objective-C who started a discussion we were going to have with the words: "Objective-C is a statically typesafe language and this is unarguable". Now one half of that sentence is true. The other is laughably wrong. I have a hard time thinking of a language that is less statically typesafe than Objective-C. We didn't have the discussion, because continuing the conversation after that tiny bombshell is pretty pointless. A lot of people at Apple did not understand Objective-C, many thought of Objective-C as at best a maladjusted Java. And it is. That is, if you make the wrong assumption that it is trying to be some sort of Java in the first place, or you misuse it that way. But it's not. It's a 1984 solution to the two-language problem. The component language being C and the composition language being Smalltalk. Jam them into one language and you've solved most of the boundary problems. Now you've obviously also created a bunch of problems, but you solved that one. When Swift came out, everything about it reeked of "we don't understand Objective-C", including the ridiculously wrong tag-line "Objective-C without the C". It's a better C++ that basically ignores the Smalltalk part in the hope that the larger-scale composition problems that the composition language tries to solve will just go away. And of course Smalltalk also wasn't really a good enough composition language either, because it's still essentially procedural. We need more flexibility in our composition languages [1]. And the composition language being so close to the component language probably led people to make those mistakes of treating them as a a maladjusted unitary language, using the composition part for component programming etc. Anyway, coming back to the understanding part: I've followed the Swift creators wherever they've talked or written about the language, the design rationales etc. And over time, what was only a sneaking suspicion became a grim certainty: they did not understand Objective-C, and did not even believe that understanding it was necessary. This did come as a bit of a shock to me, because despite that sneaking suspicion, it just didn't seem possible. [1] https://news.ycombinator.com/item?id=35318258 https://news.ycombinator.com/item?id=35318258 (linking to HN discussion, my domain is currently in transition)

pjmlp 3y ago

Lets see if this doesn't turn out to be yet another "Swift for Tensorflow", remember when fast.ai used to say the same about it?

zengid 3y ago
I agree that Jeremy was excited about Swift being a possible option for solving the "two languages" problem, but to be fair there weren't many options for ML programmers at the time. Also, I think "Swift for Tensorflow" was doomed from the start. Swift doesn't really exist outside of Apple's ecosystem, and it was competing with Python which is everywhere, and was a top 5 language even then. Making a superset of Python is a winning strategy because people can try it out and walk away if they don't like it without much effort. It worked for C-with-classes (which became C++) and Typescript, even though it took a little while for them to gain popularity and mass adoption.

ianpurton 3y ago

How does the MLIR that Mojo generates differ from https://openxla.github.io/iree/ https://openxla.github.io/iree/ Or does Mojo sit on top of iree? Will the inference engine support multi GPU setups?

krp 3y ago

This looks potentially really cool. Thanks Jeremy for the demo and Chris (et al?) for creating it.

devwastaken 3y ago

I was thinking about this idea the other day - python++, but with a diverse standard library for everything. I should never have to look up a function that turns a textual IP address into a form I can work with. I should not have to really even do a normal for loop to transform data. If it's something everyone would have to write a function for, why not pre make it.

poulpy123 3y ago

It's interesting to read but I'm not very convinced by the added value compared to using Cython, building modules in fortran or C, or using interop with rust or nim. Especially I think the need to manage memory manually and not be able to use a GC (or some other automatic memory managment) is a mistake. While I understand that you may need to manage the memory manually to squeeze the maximum performances in some cases, the performance degradation shown in benchmark by D, nim, Julia or C# shows that you can have a very good compromise between speed and easyness with autmatic memory management

ElfinTrousers 3y ago

"Python but with better performance" is a faster horse, not a car.

deleted 3y ago

[deleted]

faitswulff 3y ago

What’s the dependency story with Mojo, especially considering Python’s less than stellar dependency situation?

PurpleRamen 3y ago

So if the big trick is using optional strong typing, couldn't CPython just do the same? And syntax for type hints is stable enough now, that there would be only little changes necessary on the front. It will likely not give the same level of speedup as Mojos new runtime delivers, but could there be at least some significant boost possible which would make in impact?

sicariusnoctis 3y ago
I guess JIT type specialization / "monomorphization" might be one way to do it, but I expect that it would be bottlenecked by all the surrounding CPython interpreter stuff. /amateur_two_cents

antimora 3y ago

To get around Python's limitations and complexity of C++, here is a Rust based DL framework we are developing, called Burn: https://github.com/burn-rs/burn https://github.com/burn-rs/burn. The super cool thing about Burn is that you can swap backends easily.

gautamcgoel 3y ago
This is OT, but what does your username mean? I found this: https://en.wikipedia.org/wiki/Antimora https://en.wikipedia.org/wiki/Antimora Are you named after a species of cod?

deleted 3y ago

[deleted]

gavin_gee 3y ago

what are the benefits of Mojo over Apache TVM and OctoML?

stratigos 3y ago

Meanwhile, in the Erlang universe ... ;-)

jetzzz 3y ago

They are promoting tightly packed structs as fast. For high-performance language I would expect native struct-of-arrays support because structs are bad for CPU cache and SIMD.

zoogeny 3y ago

Mojo looks extremely promising. Lattner has some hits and misses but in general I find myself agreeing with him on principles. A brief skim of MLIR is interesting as well and I can understand it's goals and how it fits into the LLVM ecosystem. Python is is a pleasant language to use and it has a massive and growing ecosystem. This combination of a stellar tech leader, a clear defined technical goal built within and on top of an existing powerful compiler platform/framework, a popular and beautiful language foundation including a huge library of existing performant code, and impressive performance claims - this all adds up to something worth paying close attention to. Some random thoughts: After watching tutorials on PyTorch I've come to the conclusion that new programming languages must have syntax built in for dealing with tensors/matrices. The flexible array index syntax in Python allows for some nice ergonomics for this but I have a feeling that we are just scratching the surface. I understand that they don't have a public release nor a license - but I would like some more clarity on this before becoming more invested. Just saying "open source sometime soon" is a bit vague. I worry about the eventual divergence these kinds of projects make from their source. Inevitably there will be a day when Python moves in a new direction that won't be compatible with Mojo. Will they remain tethered to Python on that day or will they feel sufficiently independent to go it alone? I was very excited by Swift as a language. I was excited when Apple open sourced it. I was excited when Google was using it for TensorFlow. But it feels stalled out somehow. I don't understand the dynamics of language growth and adoption well enough to make predictions. If I were to start a new ML company today I don't know how comfortable I would be choosing Mojo over Python. Just having the current backing of a business will not guarantee success. Will this language offer enough to attract Python, C++, Rust, Julia, etc. devs over? They talk about deployment story ... but there is competition there as well in things like WASM. There are more ways to fail than there are to succeed - and I wish something like this would succeed but reality is so fickle.

zengid 3y ago

When a new language project like this drops I always feel like a kid on Christmas morning (or whatever your favorite gift-giving holiday is). I've wanted to see a general purpose language build on top of MLIR since it came out and I think this is a great way to do it, since Python is the main client for advances in ML accelerators. Treating the CPU as a target for acceleration is brilliant to. I deeply hope that this language will give general purpose programming languages a huge step forward in taking advantage of our current heterogenous-compute world. Bravo!

local_crmdgeon 3y ago

This statement isn't borne out by the article. The biggest advance in language design has been gradient typing, the biggest advance in tooling is LLMs. This is a reworking of Python.

interactivecode 3y ago

Honestly without a UI framework programming languages are kinda useless. Ecosystem is key to day to day usefulness compile time is secondary to that.

anaganisk 3y ago
Why do you want to write UIs with every programming language? I'm curious since, not every language is suited for it or not the use case at all.

doublejames 3y ago

[dead]

MR4D 3y ago

Looking forward to running flask on mojo some day. Would be neat to see it with the structs instead of classes, and fn's instead of def's.

terrycody 3y ago

Another good news for a python wanna-be newbie like me, another reason to choose Python, then later/future I can choose Mojo for performance related, ease to upgrade since its Python superset.

math_dandy 3y ago

Who's working on a Mojo equivalent for Javascript?