For what it's worth, I couldn't reproduce the benchmarks cited in the post, which claimed a 50% speedup over Rust on M1. The rust implementation was consistently about two to three times as fast as Mojo with the provided test scripts and datasets. It's possible I was compiling the Mojo program suboptimally, though.<p><pre><code> hyperfine -N --warmup 5 test/test_fastq_record
'needletail_test/target/release/rust_parser data/fastq_test.fastq'
Benchmark 1: test/test_fastq_record
Time (mean ± σ): 1.936 s ± 0.086 s [User: 0.171 s, System: 1.386 s]
Range (min … max): 1.836 s … 2.139 s 10 runs
Benchmark 2: needletail_test/target/release/rust_parser data/fastq_test.fastq
Time (mean ± σ): 838.8 ms ± 4.4 ms [User: 578.2 ms, System: 254.3 ms]
Range (min … max): 833.7 ms … 848.2 ms 10 runs
Summary
needletail_test/target/release/rust_parser data/fastq_test.fastq ran
2.31 ± 0.10 times faster than test/test_fastq_record
</code></pre>
(Edit: I built the Rust version with `cargo build --release` on Rust 1.74, and Mojo with `mojo build` on Mojo 0.7.0.)
The language is far from stable, but I have had a LOT of fun writing Mojo code. I was surprised by that! The only promising new languages for low-level numerical coding that can dislodge C/C++/Fortran somewhat, in my opinion, have been Julia/Rust. I feel like I can update that last list to be Julia/Rust/Mojo now.<p>But, for my work, C++/Fortran reign supreme. I really wish Julia had easy AOT compilation and no GC, that would be perfect, but beggars can't be choosers. I am just glad that there are alternatives to C++/Fortran now.<p>Rust has been great, but I have noticed something: there isn't much of a community of numerical/scientific/ML library writers in Rust. That's not a big problem, BUT, the new libraries being written by the communities in Julia/C++ have made me question the free time I have spent, writing Rust code for my domain. When it comes time to get serious about heterogeneous compute, you have to drop Rust and go back to C++/CUDA, when you try to replicate some of the C++/CUDA infrastructure for your own needs in Rust: you really feel alone! I don't like that feeling ... of constantly being "one of the few" interested in scientific/numerical code in Rust community discussions ...<p>Mojo seems to be betting heavy on a world where deep heterogeneous compute abilities are table stakes, it seems the language is really a frontend for MLIR, that is very exciting to me, as someone who works at the intersection of systems programming and numerical programming.<p>I don't feel like Mojo will cause any issues for Julia, I think that Mojo provides an alternative that complements Julia. After toiling away for years with C/C++/Fortran, I feel great about a future where I have the option of using Julia, Mojo, or Rust for my projects.
Great post. I think Mojo's claims like the speedup over Rust are a problem, like the 65000x speedup over Python. How can we differentiate between good new tech and Silicon Valley shenanigans when they use claims like that? They do nice titles and slogans but are shady in substance
Great post, but I think the author missed a few advantages of Mojo:<p>* Mojo provides first-class support for AoT compilation of standalone binaries [1]. Julia provides second-class support at best.<p>* Mojo aims to provide first-class support for traits and a modern Rust-like memory ownership model. Julia has second-class support for traits ("Tim Holy trait trick") and uses a garbage collector.<p>To be clear, I really like Julia and have been gravitating back to it over time. Julia has a very talented community and a massive head start on its package ecosystem. There are plenty of other strengths I could list as well.<p>But I'm still keeping my eye on Mojo. There's nothing wrong with having two powerful languages learning from each other's innovations.<p>[1]: <a href="https://docs.modular.com/mojo/manual/get-started/hello-world.html#build-an-executable-binary" rel="nofollow">https://docs.modular.com/mojo/manual/get-started/hello-world...</a>
Another point of clarification that is of great importance to the results, and is a common Rust newcomer error: The benchmarks for the Rust implementation (in the original post that got all the traction) were run with a /debug/ build of rust, i.e. not an optimized binary compiled with --release.<p>So it was comparing something that a) didn't do meaningful parsing against b) the full parsing rust implementation in a non-optimized debug build.
> If I include the time for Julia to start up and compile the script, my implementation takes 354 ms total, on the same level as Mojo's.<p>I don’t think the article mentions it explicitly, but I suppose the timing is from Julia 1.10: as far as I can remember, this kind of execution time would have been impossible in Julia 1.8 even to run a simple script.<p>Bravo, Julia devs. Bravo.
Folks using multiple languages, what is your workflow?<p>I do most DS/ML work in Python but move to R for stats, and publication-ready plots and tables (gt is really great). I often switch between them frequently, which is a hassle in the EDA and prototyping stages, especially when using notebooks. I enjoy Quarto in RStudio, but the VS Code version is not that great.<p>How do you make it work?<p>Also, after so many years using Python and R, I would love to learn a new language, even if only for just a couple of use cases. I considered Elixir for parallel processing and because it has a nice syntax, but ultimately decided against it because it can be a little slow and isn't used much in my area (sadly!). Rust seems to require too much time to get decent at it. Any recommendations? (Prolog?)
As someone who practices bioinformatics, it doesn’t seem appealing. Bioinformatics is like 0.1% dealing with FASTQ files and the rest is using the ecosystem of libraries for statistics and plotting. Many of them in R, by the way.
> It does grate me then, when someone else manages to raise 100M dollars on the premise of reinventing the wheel to solve the exact same problem, but from a worse starting point because they start from zero and they want to retain Python compatibility. Think of what money like that could do to Julia!<p>Python is a juggernaut with total control of the ML space and is a huge part (even if less dominant) in modern scientific computing.<p>A VC has way better chances of success building solutions compatible with Python rather than replacing it.
I’m really excited about Mojo’s potential. But I don’t think it’s ready for real use outside it’s AI niche yet. Being able to call Mojo functions from Python is the sentinel capability I’m waiting for before considering its use for general purpose code.
I felt like I learned more about the author than Mojo.<p>- Never actually runs it. Seriously.<p>- Wants us to know it's definitely not a real parser as compared to Needlepoint...then 1000 words later, "real parser" means "handles \r\n...and validates 1st & 3rd lines begin with @ and +...seq and qual lines have the same length".<p>- At the end, "Julia is faster!!!!" off a one-off run on their own machine, comparing it to benchmark times on the Mojo website<p>It reads as an elaborate way to indicate they don't like that the Mojo website says it's faster, coupled to a entry-level explanation of why it is faster, coupled to disturbingly poor attempts to benchmark without running Mojo code
How does a software engineer transition into bioinformatics or computational biology? I've taken some online courses on bioinformatics and have some experience in large distributed jobs but these jobs seem few and far in between and generally want M.S/PhDs in bioinformatics. Is it really a field that's not viable to enter without an MS?
Crystal was never able to find traction as a Ruby clone that could compete with C speeds. Why would a Python clone have any better luck? I don’t think anyone would accuse Python of being dramatically more usable than Ruby.
>>> As a bioinformatician who is obsessed with high-performance, high-level programming, that's right in my wheelhouse!... Mojo currently only runs on Ubuntu and MacOS, and I run neither. So, I can't run any Mojo code<p>1. Back to the rust vs mojo article that kicked this off... this isnt someone who is going to use rust.<p>2. Availably, portability, ease of use... These are the reasons python is winning.<p>3. I am baffled that this person has to write code as part of their job, and does not know what a VM is! Note: This isnt a slight against the author, I doubt they are an isolated case. I think this is my own cognitive dissonance showing.