Hi <!channel>! I'm pretty excited to launch two new projects today: RustQC 🦀 🧬 and rewrites.bio 🚀

👉🏻 TLDR: I'm trying to get this to go viral on HackerNews! Please give us a helping hand if you like what you see! 😆 hacker news https://news.ycombinator.com/item?id=47616595

This story started about a month ago, when I jokingly said (not for the first time) that I should just rewrite dupRadar in Rust after seeing it break some #CE8SSJV3N runs again. I kicked off Claude together with Seqera AI, and this time it… worked! Fast forward a weekend’s worth of building, then several weeks of validation and incremental fixes, and #C0AQYAFSSV7 was born. It replaces the entire #CE8SSJV3N QC subworkflow (dupRadar, featureCounts, 8 RSeQC modules, preseq, samtools stats, and Qualimap) - which together account for over 15 hours of run time. RustQC finishes in around 15 minutes, over 60x faster. I’ve designed RustQC to be a drop-in replacement for those tools, so it’s totally optional. Output files are near-identical, so MultiQC works out of the box. There’s a dedicated Nextflow validation pipeline that uses #C049MBCEW06 to compare outputs against the upstream tools to ensure parity. I released it on Bioconda earlier this afternoon and@Jonathan Manning is quick off the mark, there's already a PR to #CJRH30T6V to add it (a PR to #CE8SSJV3N shouldn't be far behind). What’s interesting is that my Rust rewrite story is far from unique. Three days into my effort, @Rob Patro independently published about doing the same thing with piscem. Then @Nils Homer at Fulcrum just released fgumi earlier this week.. Something has clearly shifted. I’m both extremely excited and a little bit terrified at what I expect to be a wave of tool rewrites in bioinformatics. After a lot of discussion, we decided that these AI-assisted rewrites are coming whether we like it or not. The best thing we can do is to try to get ahead of them and establish some best practices to avoid what we see as the worst risks. To that end, we are also announcing https://rewrites.bio - a set of best practice guidelines for anyone else wanting to use AI to improve on bioinformatics tooling. It’s common sense stuff: Credit the original authors, emulate output exactly, don't file AI-generated bug reports, that kind of thing. Hopefully it starts a discussion around this topic for some community consensus. Anyway - I hope folks like what we’ve made. Looking forward to the discussion that comes around it 😀 • hacker news Hacker News post! https://news.ycombinator.com/item?id=47616595 • seqera RustQC blog: https://seqera.io/blog/rustqc/ • seqera rewrites.bio blog: https://seqera.io/blog/rewrites-bio/ • https://rewrites.bio • https://seqeralabs.github.io/RustQC/

Never use AI-generated test cases as evidence

sigh...never never?

This is really great! Can you rewrite VEP in rust/C as well? I hate debugging in perl 😅

sigh...never never?

Well, at least take with a large pinch of salt 😅 That one came from a "bug" that Claude found in preseq. It wrote up a full GitHub issue for me to post, was super confident etc etc. I refused and eventually figured out it was an artefact of the test data I was working with and actually it was a RustQC bug this is fine fire LLMs can be very persuasive / convincing...

@Rike Hanssen and I second the VEP in rust

This is fascinating. Thanks, Phil! Are there upcoming plans to actually integrate rustQC into nf-core pipelines?

Hi Phil, I’m coming at this more from the applied genomics side, where I mostly use tools that are already peer-reviewed and well established in the field, because that makes them easier to justify and cite in a manuscript. . Rewrites like RustQC seem really useful, especially for speeding up iteration on large datasets, but they do not yet have the same publication history as the original tools they replace. How do you think users should approach that in manuscripts? Is strong validation and output parity enough, or do you think most people will still wait until the rewrite has its own peer-reviewed paper?

Would love to have a faster MarkDuplicates option too!

@David Carlson https://github.com/nf-core/modules/pull/11115

I've got a stealth #CE8SSJV3N pr on the go, will be there as soon as the module pr passes, then I'll release next week

@Kinley great question - I'd argue you can cite the original tools here, as the results should be pretty much 1:1 identical to if you'd used them (in some cases the md5 hashes even match)

For the folks hating on VEP (I’m one of them for the record): Ensembl’s busy writing a python port, but the progress seems quite slow

Why not default to forking the original project, implementing the rewrite, then opening a PR against the main branch? That way everything stays central to the project, the original authors get their credit, they can merge the changes if they're still maintaining the repo and appreciate the changes, and people can still find and use the improved branch if it's never merged.

That is amazing work, more efficient pipelines are always welcome! I am also looking forward to fgumi integration into rnaseq (which I already saw a couple of days ago), because umi-tools is simply too slow. Did you add some specific MCPs for Rust? Because about a month ago I asked Cursor to redo

umitransfer

in a faster way and it created a quite inefficient string conversion loop, so was clearly not yet capable of doing this without babysitting and I had already forgotten too much to fix it quickly. As far as I know, Rust was so far also not part of your skillset? PS: @David Carlson Faster duplicate marking is already being worked on.

rnaseq PR: https://github.com/nf-core/rnaseq/pull/1754

Can we do rewrite of RSEM? And please dont hate me for this but of nextflow itself? Why Groovy? There has to be better alternatives to write a DSL on?

Why not tackle GATK while we’re at it

Sarek?

lol...you might be joking, but +1 for GATK

For GATK argument would there is DRAGEN already out there which is more fast and accurate. Lets beat that with open source?

Yeah, I’m really not joking... 😅 DRAGEN is limited to FPGA’s so useless for folks without dedicated hardware

Agreed, but free, fast underperforming GATK will not be used in Clinics

I like deepvariant and deepsomatic as alternatives. Parabricks already accelerates them and is free to use

DRAGEN is limited to FPGA’s so useless for folks without dedicated hardware

Not anymore, or at least not much longer (GPU and commodity CPU support is en route). Still limited to just Illumina data, though, and now with a per-GB license fee so still a good argument to consider alternatives.

@Trevor Freeman great question:

Why not default to forking the original project?

This was my original intention with dupRadar. But in the course of the rewrite I immediately encompassed both dupRadar and featurecounts. Then rseqc. Then qualimap, preseq, etc etc. Contributing the rewrite back upstream only works if it's a 1:1 tool rewrite. And one of the primary gains of RustQC is the architectural choice to combine multiple tools. This means that the rewrite isn't a fork, it's a completely different beast. But in other cases a 1:1 rewrite of a tool may make more sense, in which case I totally agree that this path should be considered (after discussion with the original authors, ideally)

Put this on the Biostars post as well, but re-posting for discussion:

This work (along with edgePython, etc) have generated a lot of internal discussion. https://rewrites.bio/ spurred some passionate debate, particularly the 3.1 "think big" point, which was generally felt to encourage "shortcuts" rather than holistic ports that are more easily maintained and/or rolled in upstream in the original implementation.

We agreed it'd be better to avoid combinatorial merging of features, keeping a port a full reimplementation (perhaps with optional streamlining capabilities), and then building any additional tooling as a separate entity on top as needed. E.g., rewrites of dupRadar, featureCounts, etc, with RustQC then using those ports as it pleases. This would generally simplify maintenance and be more broadly useful in our opinion, though we recognize this is more work and a less direct route to the ultimate goal in this case. That said, we feel the rewrites.bio guidelines should consider reflecting a more holistic approach like that for the good of the community at large.

@Phil Ewels Thanks for the response!:

Interesting point @Jared Andrews ! I like the direction that you're going in here, but I suspect that in practice the combinatorial rewrite would find it difficult to use all those separate libraries. The shared parsing code would have to be virtually identical across the different rewrites, and my gut feeling is that it'd be a death by a thousand paper cuts and the combinatorial rewrite would end up being fairly stand-alone anyway. My thinking with the RustQC approach is that the code within RustQC doesn't actually matter that much. This kind of breaks my brain a bit, but when LLMs can generate and regenerate quality code so fast, the question of maintainance changes. Maybe the upstream tools live on as "reference implementations", effectively truth sets that a thousand custom rewrites can shape themselves around? Bit of a hot take I know 😅🌶️

I still think a performant reimplementation holds more flexible value. LLMs excel at generating thin wrappers around existing tools. I agree that "roll your own" wrappers for specific purposes and convenience/speed may become common-place, but I suspect significant token savings by having high-performant implementations ready to rock.

Maybe worth noting that RustQC uses rust-htslib for doing the heavy lifting. There's also noodles, and Oxbow. I guess that kind of aligns with what you're saying, just at a slightly lower level.

The shared parsing code would have to be virtually identical across the different rewrites, ...

If this leads to a dedicated, efficient, well-maintained (and tested) parsing library that would be used by all projects with a need for it, I would count that as a win. Of course, whether you can convince all project maintainers to actually use it is another question.

..., but when LLMs can generate and regenerate quality code so fast, the question of maintainance changes.

I see the temptation, but LLMs are a blackbox and can change their mind on a whim. I think they do their best work when they use (and recombine) ready-made and tested libraries, so at least some things will have to stay stable, or it will be very hard to figure out what went wrong when things inevitably break ...

I really like the rewrites.bio guidelines which are clearly thought out carefully, but I do feel this should still only be done with the consent of the original authors (unless the project is dead and nobody is responding to issues). It's still a fork, and it will be interesting if users report issues in the re-written repo or the original one. Though I can see how this would potentially slow the concept down too much.

I think if the rewrite has a distinct name (as RustQC does, for example), people will gravitate towards the rewrite repo. We’ve got some experience with this, as we maintain a fork (published, with extra features) of a CNV tool and we’re catching most of the issues

Yup, not easy points and I certainly don't have all the answers. Though after scratching around in sourceforge for this much longer than I'd like, I can confirm that not all projects are as easy to contribute back to as others 😅

I'm still very much on the sceptical side of AI-assisted coding (i.e. I still rather not touch it apart from some specific situations), but I can't deny that this is quite impressive. So congrats to all those involved! A few things to note: • Hackernews has been notoriously anti ai-assisted projects btw, just an fyi. And bio-related things generally don't do well there either, so this might not get picked up as easily there. • A 60x speed increase seems insane to me. How much of that is due to the differences between languages vs just generally non-optimized parts of the code? (skimming the blog post => parallellization + reducing copmression steps seem to be the main contributing factors?) • I also share some of the concerns mentioned by Thomas Danhorn; maintainability feels like it will be a problem. Even with guidelines and best practices (which I do quite like, even given my general concerns about ai) , this very much feels like a double-edged sword to me. Abandoned software has been a problem in bioinformatics before AI was a thing. Although one could argue that this allows those projects to be resurrected. I guess it boils down to whether or not comprehensive testing can be a substitute for understanding the (full) code base. I realise that the latter is not realistic in many cases (especially when you consider dependencies; bioinformaticians don't need to understand OS-level logic to write a python script), but it still doesn't feel right to me (as an irrational biological entity).

The gatk example was more of a joke and an example of a huge codebase in need of some serious upgrade 😅 Although I would really love a good reimplementation of the picard QC tools. Those have been a real bottleneck for us (e.g. one qc step takes a long as the rest of the entire pipeline). The case for rust rewrites wrt to python tools is you can incrementally rip out stuff and replace it with rust bindings. This ensures you keep an oversight of what is happening and it promotes a better understanding of the existing code. I can see a lot of project going that way in the future. Too bad performant rust can become quite complicated. I would’ve loved to have golang in that slot, but it never gained too much traction in the bioinformatics space

@Pieter Moris I guess the point with the "disposable code" paradigm is that you're not locked into anything. It's the specs and the test suite etc. that are the things that are maintained by Humans, and they're agnostic to how the rewrite was done. It's just another level of abstraction above the code layer. I'm not sure that I agree with this paradigm and I doubt that we will get to that extreme any time soon. But it's a fun thought experiment 😅

> you're now locked in a system that's largely entirely dependent on AI for future maintenance as well. And we must be honest observing that besides some enthusiasts, rust adoption is still behind expectations and the number of people capable to manage mid size codebase for efficient bug fixing is too low. BTW, bioinfo softwares often relies on internals for scientific computation (ie. boost library in c++). When I see in the rewrite.bio this > The goal is a faster tool that produces the same results This may be unreachable with implementations in different languages, and this could be related also to some library for random numbers. Take for example the ongoing reimplementation of STAR ( https://github.com/Psy-Fer/ruSTAR ) , where the author said > Unavoidable ties (~119 reads): Both tools find the same set of equally-scored alignments but choose different ones as primary due to internal processing order. Neither alignment is more correct than the other Personally, I'd say that each project must define what they define to be the acceptable distance within the original output results and, whenever possible, this must be defined together with the original author, in a similar way to what happened with the python rewriting of deseq2, where Love was involved into mostly as a "consultant" for correctness assessment.

> And we must be honest observing that besides some enthusiasts, rust adoption is still behind expectations and the number of people capable to manage mid size codebase for efficient bug fixing is too low. I can't tell whether according to you this implies that we need LLM-coding to be able to actually create and support these rewrites, or that we shouldn't do it because we lack the human capital for maintenance 🥲

LLMs reduce the cost of writing code but not the cost of owning it. In ecosystems with limited expertise such as rust in bioinformatics, reimplementation without a sustainability plan shifts risk from development to maintenance, likely resulting in fragile or abandoned systems despite initial productivity gains. I know this may sound skeptical, but everywhere in the software world we're seeing reimplementations in the last years dying as soon as they came out, and building support plan over time is not trivial and must be considered alongside release.

Absolutely agree 👍🏻 A big chunk of the rewrites.bio site is dedicated to exactly that topic for that reason (also the blog post). I see it as opportunity vs. risk. We've gotten to the point now where I see the opportunity as being too great to ignore / leave on the table. So the best we can do is attempt to mitigate risk as best we can. How we do that is exactly the discussion that I want to kick start here 👍🏻

First up, fascinating work. Big fan of your efforts @Phil Ewels I’m still digesting this but the approach seems focused on producing a more performant but functionally equivalent binary from a reference implementation. That’s valuable, and I would love to have my 15 hour pipeline down to an hour, It would improve my productivity immensely, but it feels like it may be missing what I’d consider the longer-term goal: extracting a specification, along with the tests required to validate an implementation. I’m not convinced the rewrite itself should be the primary goal, at least initially. That can come later, and likely plays to AI’s strengths once a robust specification exists. What seems most valuable is a versioned, peer-reviewed specification published as an independent artifact. Something domain experts could then iterate upon. If code is becoming just a fungible implementation detail, then perhaps the specification and its associated tests were the real goal all along? [edited with gpt]

Well that's kind of what we have already with

nextflow run nf-core/rnaseq -profile test

- that gives you all the upstream tool output files, from versioned containerised reproducible point in time. Then you can use nf-test to snapshot them for comparison. That's what makes it such a tractable problem.

Don't worry @Phil Ewels, I have just enough friends at the intersection of "bioinformatics" + "fanatical Rust nerds" that your post is about to go full pandemic 😄 This is really cool though, looking forward to trying it out!

@Phil Ewels great work! It would be nice if you could do a bytesize and go through your developer's experience through this process, i.e when you could let Claude run free, when you had to babysit it, when you needed to double check what it did.

Saw this today: https://github.com/Huang-lab/RastQC

Yeah, there's also fastqc-rs and BioFastq-a and probably 100 other FastQC rust rewrites 😅

lol

fastp

is already pretty fast, so to me FastQC replacements are of somewhat less interest than the tools covered by rustqc.

This is kind of what I was trying to get at re: thinking the preferred behavior should be forking "official" project repos and opening a PR with rewrites. Feels to me like it would centralize a lot of this stuff and give current project maintainer(s) (assuming there are any) a chance to review and officially support the rewrites that are faithful to the original project.

But yes, I agree. For a 1:1 tool rewrite I can't see any other way around it. Which I don't love, but..

Do we really need rewrites. Sometimes we have to rethink the goals of some of thes tools

And are the original authors fluent in the new language? Or able to use AI to continue maintainance?

Or willing to maintain/update multiple flavors each time the main implementation gets a new feature.

All valid concerns. But in this context the rewrite just works for many users. The science and usability of these tools is well established. Just their speed is a concern which rustQC fixes. Community is welcomed to rethink and write better tools. But for now, this just works. +1 from me.

Yes, we're rehashing some topics here (or maybe from other threads, apologies if so). • improvements make it a new tool, much more difficult to write + validate, and also much harder for others to switch to. I'm not suggesting that people shouldn't do that, it's just a different thing. • Original authors don't need to maintain the rewrites. That's the responsibility of the rewrite author(s) • The rewrite authors should update as needed. In our context that will presumably be as/when their upstream tools update (nf-test is helpful here). Most RustQC upstream tools haven't had updates in several years.

It'as awesome that you did such a thing! In the past few weeks I've been thinking of the exact same thing but for genome annotation tools like RepeatMasker, GeneMark , Braker, etc. which are so slow and buggy 🤯 I love the manifest in rewrites.bio

Can you rewrite VEP in rust/C as well? I hate debugging in perl

Not quite an exact rewrite, but it’s something https://github.com/Huang-lab/fastVEP

So that's Rike in Rust, so Riker, right?

lol

Fulcrum probably, since they will likely have clients in the future running them. Maintenance for academic tools is always an issue, since there is hardly a new paper to write about tiny optimizations and maintenance. Many of the original tools also have not seen updates in many years as e.g. Phil pointed out in the RustQC blog post. And regarding AI: AI is terrible at maintaining tools that humans have written as benchmarked with a couple of real-world Python projects. But the tools are improving (e.g. AI can discover and counteract specification drifts in Rust codebases with tools like tracey) and an AI rewrite will likely also be easier for an AI model to maintain because it uses familiar patterns.

I've tried reaching out to some (not all yet) authors of the upstream tools from RustQC. I've had a reply from the guy behind dupRadar (Sergi Sayols Puig), I'm sure he wouldn't mind me pasting some of what he wrote:

dupRadar (the tool) is simply an implementation of the method we devised during my PhD. A lot has happened since then, and as you'll appreciate, aside from a few bug fixes the tool has not evolved further. For that reason, I'm genuinely glad to see the method reimplemented within a unified QC framework for sequencing data.

The idea of running all these QC steps in a single pass through the BAM file is absolutely genius. It-s something that bothered me for years when looking at the running times of hundreds of pipelines with tens of gigabytes of BAM files read back and forth just to get past those QC. Cheers!

If we merge everything in one tool, that means less tools to maintain 😉

I think you mis-typed sarek

<http://github.com/nf-core/allthethings-rs|github.com/nf-core/allthethings-rs>

subs repos I fell for

But yes, future maintenance is absolutely a valid concern. I'm not sure it's new, but it is arguably going to be amplified along with other problems of scale (eg. knowing which tool to use, for example).

Yeah, I think it's about 'sunk costs'. If I spend 6 months writing a utility I'm unlikely to consign it to oblivion after the first release. A weekend of vibe coding? Not sure I care as much. Especially since I'll probably end up with dozens of such things.

@Phil Ewels I tried RustQC for Paired-end RNAseq data. Read counts produced by RustQC Featurecounts is almost double than subread featurecounts . Any idea why?

@Bhagwan Yadav could you submit us a bug report please, with the commands you used?

@Bhagwan Yadav - link is here: github.com/seqeralabs/RustQC/issues - or if you'd prefer please just describe in more detail over in the #C0AQYAFSSV7 channel. We haven't seen what you're describing in our tests, so if it's real I'd be very keen to track it down ASAP 🙂

"Almost double" sounds like counting each paired read separately (i.e. counting individual reads instead of fragments), which could be related to an option ...