6 ms·
Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
- colemannerd 2y agoI REALLY want to use mojo...but they still don't have basic backwards compatibility features like lambda done. I worry mojo won't get off the ground because they're too focused on hardware performance and aren't building enough features to justify the switch... to get that hardware performance.
- fl0ki 2y agoIt's fashionable to hate on Mojo, but I actually hope they succeed. I started my career by writing fast, production-grade replacements for Python programs written by scientists. Without someone like me, they were squandering government-funded compute resources and wasting time on the critical path to delivering their scientific contributions. Any technological advancement that gets them more efficiency and leverage without the bottleneck of working with a software engineer would both empower scientists and free up software engineers for other problems. It remains to be seen whether it will actually deliver on this potential. I think a lot has been promised before it's been proven. But I do think something like this is worth attempting and thoughtful work is being applied to the attempt.
- CoreyFieldens 2y agoAs someone who has been playing around with (and enjoying) Mojo, I have my doubts about how useful Mojo will end up being for your average scientist. You can't get performant code out of Mojo if you're not willing to learn some deeper programming concepts like SIMD or tiling. I don't have the exact quote on hand, but in the Mojo Discord, Chris Latner explicitly said he wants no "compiler magic" in Mojo. With that idea in mind, Mojo makes it a lot easier to do optimizations like SIMD vectorization by hand, but you will still have to do it manually. My guess is that many scientists who don't like programming would find it annoying to hand-write those kinds of optimizations. If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option. These are the docs for some of Mojo's higher order functions that implement vectorization, parallelization, tiling, loop switching, etc. https://docs.modular.com/mojo/stdlib/algorithm/functional https://docs.modular.com/mojo/stdlib/algorithm/functional I do think they are a good idea and relatively easy to use; I'm just not convinced that the non-programmer scientist will like them.
- madspindel 2y agoTrue, but don't you think AI Copilots can optimize the code in the future? Write the code in Python, then tell Copilot to optimize it with Mojo.
- likium 2y agoWon't the right abstractions like NumPy make it possible for researchers to obtain generally performant code, and lower the bar to write specialized, optimized code without having to drop all the way down to CUDA?
- CoreyFieldens 2y agoI think I would agree with you. In my opinion, that already exists and is decently mature. CuPy [0] for Python and CUDA.jl [1] for Julia are both excellent ways to interface with GPU that don't require you to get into the nitty gritty of CUDA. Both do their best to keep you at the Array-level abstraction until you actually need to start writing kernels yourself and even then, it's pretty simple. They took a complete GPU novice like me and let me to write pretty performant kernels without having to ever touch raw CUDA. [0] https://cupy.dev/ https://cupy.dev/ [1] https://cuda.juliagpu.org/stable/ https://cuda.juliagpu.org/stable/
- dunefox 2y ago> If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option. If Julia hasn't taken off yet (which I am very sad about), I'm not sure why Mojo would. I'd rather have more resources invested into Julia.
- 0cf8612b2e1e 2y agoJulia has to bootstrap an ecosystem. If mojo can borrow all of the successful Python libraries, that is worth a lot. Still an enormous uphill battle, but slightly more tractable. Regardless, it is a rough place to be - for a staggering number of uses, Python is fast enough. The organizations who absolutely require top tier performance already have the ability to use FFI. Instagram runs on Django and I believe is still used for YouTube.
- sidkshatriya 2y agoHeard some positive things about Mojo. But my curiousity waned after I learnt it was not open source currently. In 2024 why should I be interested in a language that is not open source ? Perhaps I'm missing something ?
- jopamer 2y agoThe standard library is open source, you can find it here: https://github.com/modularml/mojo/tree/nightly/stdlib https://github.com/modularml/mojo/tree/nightly/stdlib We'll be opening up more over time - stay tuned!
- NegatioN 2y agoJust in case you're in the know: I was really really close to trying to spin up something at work using the Max Engine. However, I see that it collects telemetry [1], and we can't really allow that. Do you know if there are plans to be able to turn this entirely off at some point? It's nice to know if I should keep it on my radar, or if I can't consider it without changing jobs :) [1]: https://docs.modular.com/engine/faq#does-the-max-sdk-collect-telemetry https://docs.modular.com/engine/faq#does-the-max-sdk-collect...
- catoc 2y agoThere’s nothing bad about telemetry per se. In fact it should be considered bad to not be paying attention to how anything you build works in the real world. (Then comes Meta c.s. and everyone rightly distrusts anything reported back from their computer) This just to say, that yes, the majority of companies cannot be trusted, but there’s still good guys out there collecting useful metrics completely devoid of secondary malicious purposes.
- 0cf8612b2e1e 2y agoIntentions be damned. Some industries take IP/security very seriously (eg regulated medical). Tools which phone home “for my user experience” are a complete deal breaker.
- Apocryphon 2y agoSo how is Mojo comparing with Hylo (formerly Val), the other former Swift creator created new language?
- jshier 2y agoCompletely different goals. Mojo seeks to replace / supplement Python in the compute space, Hylo (Val) is an experiment in a value-first semantic language, inspired by Swift.
- fooker 2y agoMojo feels like a language that's trying to be everything for everyone.
- WeatherBrier 2y agoI feel the opposite, they really are focused on being a language that's great for AI and heterogeneous compute, since that's what Modular is focused on. But the features are attractive for other use cases, it has access to MLIR, compile time metaprogramming, easy and ergonomic SIMD, and soon GPU support.
- fooker 2y agoOkay great. Why does AI and heterogeneous compute need ownership and lifetime checks again? These are really needed for low level pointer heavy code.
- mirekrusin 2y agoSo they can optimize code. The main theme is addressing two-language problem (single high & low level language). They want uniform language for cpu/gpu/whatever-pu. They can't have garbage collection. They need strict dataflow analysis with precise destruction points.
- fooker 2y agoDo you see my point that they are trying to do everything?
- mirekrusin 2y agoThey're not trying to do everything. They don't care about stuff like Hindley–Milner inference, logic programming, relational algebra integration, tsx like html integration, functional purity, algebraic effects and dozens of other concepts. They just care about extending python so you don't need to use ffi to jump into c++/cuda for performance because language already supports high performance constructs.
- WeatherBrier 2y agoI am really enjoying the language, the level of improvement over the last few months has been amazing. At work all our heterogeneous compute needs are implemented using C++/CUDA. I've been exploring new languages for the type of work we do on and off over the last few years: Julia, Rust, D, Chapel, and Mojo. It seems the only new languages serious about native heterogeneous compute are: Julia, Chapel, and Mojo. Of those languages I can say Mojo and Chapel were the most impressive. But Mojo is just so fun to write, I've ported a bunch of my "hobby numerical code" to Mojo. I am practically all in on Mojo since it'll give me access to MLIR. I have always wondered though, why does Chapel get no love online???
- pjmlp 2y agoMost likely because HPC isn't cool for TikTok videos, by language influencers. As CERN alumni, and language nerd, I find Chapel quite cool.
- tialaramex 2y agoAbout 11 minutes in as an aside they look at an example where they're initially mutating a growable array (Rust's Vec, Mojo's List) and now they want to replace it instead. The narrator (rather than Chris) shows that Mojo makes this fairly easy - we were never promising only to mutate the container, so if we replace it instead that's fine. And they (presumably correctly, I am not a Python expert) say that Python just can't do this. But they also claim Rust can't do it either, and propose a fairly serious surgery to adjust the function signature instead to write a function which takes and returns ownership. But you don't need to do that in Rust. We have a mutable reference, Rust doesn't mind us changing what it refers to, it's mutable after all, we just can't move it because it's not ours to move. This is where core::mem::swap, core::mem::take and core::mem::replace enter the picture, they allow us to easily use this capability. For the example they're explaining you can just core::mem::replace(v, vec![8, 8]); and you're done, the signature doesn't change at all.