11–20 of 124 posts
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. So it was comparing something that a) didn't do meaningful parsing against b) the full parsing rust implementation in a non…
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.
Besides people opting for closer to C speed had Rust, Go, Java, Swift, and other options to go to, all with more momentum and support, before going for a yet unproven Ruby clone.
>>> 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 1. Back to the rust vs mojo article that kicked this off... this isnt someone who is going to use rust. 2. Availably, portability, ease of use... These are the reasons python is winning. 3. I am baffled…
It's odd to read something that's pretty well-versed with some relatively complex CS concepts, i.e. it's not just a PhD with a blank text editor. But simultaneously, makes egregiously obvious mistakes that I wouldn't expect any college graduate to roll with.
There's a certain type, and I don't know what name to give it, especially because I certainly don't want to give it a condescending name. I call it "data scientist types" when I'm in person with someone who I trust to give me some verbal rope.
Software really feels like it ate everything and everyone. So you end up with insanely bright people who do software engineering as part of their job, but miss some pieces you expect from trad software engineering.
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.
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.
Well, for the domains Mojo targets, Python is king. So a faster-Python-like language would have more potential audiences. A fast Ruby-like language, not so much, as Ruby was never that special in those domains, or in most places outside web development, and even for that it kind of lost steam in the past 10 years. Besides people opting for closer to C speed had Rust, Go, Java, Swift, and other options to go to, all w…
>>> 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 1. Back to the rust vs mojo article that kicked this off... this isnt someone who is going to use rust. 2. Availably, portability, ease of use... These are the reasons python is winning. 3. I am baffled…
On the other hand, the fact that Mojo doesn't run on Windows and most Linux distros is a point in itself. And also, would the blog post really be substantially improved if I had gotten the number of milliseconds right for the Mojo implementation on my computer? Of course not. It should be clear that the implementations are incomparable, and that a similar Julia implementation is very fast which implies that the reason the original Mojo implementation allegedly beat Rust is not because Mojo is faster. It's just a different program.
Earlier quoted context omitted.
Well, for the domains Mojo targets, Python is king. So a faster-Python-like language would have more potential audiences. A fast Ruby-like language, not so much, as Ruby was never that special in those domains, or in most places outside web development, and even for that it kind of lost steam in the past 10 years. Besides people opting for closer to C speed had Rust, Go, Java, Swift, and other options to go to, all w…
I used to be quite sceptical given how Swift for Tensorflow went, however since NVidia decided to partner with Modular, alongside their ongoing CUDA JIT bindings for Python, I think Mojo might actually work out.
I felt like I learned more about the author than Mojo. - Never actually runs it. Seriously. - 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". - At the end, "Julia is faster!!!!" off a one-off run on their own machine, comparing it to be…
The point is that the original blogs claims of "Mojo is faster" isn't right - it's comparing different programs. That implementation in Mojo is faster than Needletail - but that doesn't say very much and I prove it by also beating Needletail in Julia by using the same algorithm as Mojo does. So it's the algorithm. Not Mojo. Not Julia.
Also, did you even read my discussion on how much a parser ought to validate? Your resume is completely missing the point.
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.
If this is not the way to remove workflow friction, what is?
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.
Bravo, Julia devs. Bravo.