totalperspectiv

Carp has been slowly inching forward and ticking those boxes

Per modular Twitter, the plan is still to open source the mojo compiler this year: https://x.com/Modular/status/2069787078032834635

I thought he stopped working on LuaJIT? Is it back in active development?

That's fair, I think I should have just said "comparable to Zig". The type'd ness is what I was thinking of, but having actually written some zig in the last few days to play with their Io model / see what passing around an allocator is like, Zig is pretty fantastic.

I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.

"requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU.

Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there.

I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding.

Paper on the tool I wrote: https://doi.org/10.1093/bioadv/vbaf292

Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc.

Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.

Very excited for Mojo once it's open sourced later this year.

The author works for Modular. He shared the write up on the Mojo Discord. I think Mojo users were the intended audience.

I've only tested this when writing my own parser where I could skip the record end checks, so idk if this improves perf on a existing parser. Excited to see what you find!

Removing the wrapping newline from the FASTA/FASTQ convention also dramatically improves parsing perf when you don't have to do as much lookahead to find record ends.

a testament to the massive gap in perceived vs actual programming ability of the average bioinformatician.

This is not really a fair statement. Literally all of software bears the weight of some early poor choice that then keeps moving forward via weight of momentum. FASTA and FASTQ formats are exceptionally dumb though.

Because I was originally writing some very CPU intensive SIMD stuff, which Mojo is also fantastic for. Once I got that working and running nicely I decided to try getting the same algo running on GPU since, at the time, they had just open sourced the GPU parts of the stdlib. It was really easy to get going with.

I have not used Triton/Cute/Cutlass though, so I can't compare against anything other than Cuda really.

I can confirm, it’s quite nice.

They allow you to write a kernel for Nvidia, or AMD, that can take full advantage of the Hardware of either one, then throw a compile time if-statement in there to switch which kernel to use based on the hardware available.

So, you can support either vendor with as-good-vendor-library performance. That’s not lock-in to me at least.

It’s not as good as the compiler being able to just magically produce optimized kernels for arbitrary hardware though, fully agree there. But it’s a big step forward from Cuda/HIP.

I have used Mojo quite a bit. It’s fantastic and lives up to every claim it makes. When the compiler becomes open source I fully expect it to really start taking off for data science.

Modular also has its paid platform for serving models called Max. I’ve not used that but heard good things.

I don’t follow your logic. Mojo can target multiple gpu vendors. What is the Modular specific lock in?

I can't speak to Gleam, but for Elixir I just used Burrito to create a single executable: https://github.com/burrito-elixir/burrito I think it works for just Erlang too.

I really wish Crystal had taken off a bit. I thought it had a chance in bfx with some good benchmarking and PR by lh3 in biofast.

I would rather write Groovy than YAML any day of the week.

Why did you rule out Nextflow or Snakemake? I believe they both work with k8 clusters.

Argo doesn’t look great from my standpoint as a workflow author.

NF Tower / Seqera would be the selling points. They offer a nice UX for managing pipelines and abstract over AWS.

Technically snakemake can do it all. But in practice NF seems to scale up a bit better.

That said, if you don’t need the UI for scientists, I’d stick to snakemake.

Cool seeing a workflow language pop up on HN!

Nextflow and Snakemake are the two most-used options in bioinformatics these days, with WDL trailing those two.

I really wish Nextflow was based on Scala and not Groovy, but so it goes.

There is a Draft up for dsl3 that adds static types to the channels that I’m very excited about. https://github.com/nf-core/fetchngs/pull/309

I think you hit the nail on the head with the mental model part. I really like this method of thinking about programming "Programming as Theory Building" https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f...

I don't mind when other programmers use AI, and use it myself. What I mind is the abdication of responsibility for the code or result. I don't think that we should be issuing a disclaimer when we use AI any more than when I used grep to do the log search. If we use it, we own the result of it as a tool and need to treat it as such. Extra important for generated code.

ish is a CLI tool for searching records using alignment methods. It’s record-type aware and supports lines, FASTA, and FASTQ. I was really pleased with the dev experience using Mojo. It’s still pre-1.0 and missing a few things, but overall it came together smoothly. Performance-wise, Mojo held up well. There's no direct apples-to-apples comparison for ish as a whole, but the core alignment algorithms are on par with the C++ reference (faster in one case, see preprint linked above). Writing and shipping a GPU kernel as part of a CLI was especially cool. This was my first time with GPU programming, and Mojo made it feel first-class, though I don't have much CUDA experience to compare. Excited to see where Mojo goes. Once the compiler is open-sourced, the possibilities look wide open.

ish is a CLI tool for searching records using alignment methods. It’s record-type aware and supports lines, FASTA, and FASTQ.

I was really pleased with the dev experience using Mojo. It’s still pre-1.0 and missing a few things, but overall it came together smoothly.

Performance-wise, Mojo held up well. There's no direct apples-to-apples comparison for ish as a whole, but the core alignment algorithms are on par with the C++ reference (faster in one case, see preprint linked in repo).

Writing and shipping a GPU kernel as part of a CLI was especially cool. This was my first time with GPU programming, and Mojo made it feel first-class, though I don't have much CUDA experience to compare.

Excited to see where Mojo goes. Once the compiler is open-sourced, the possibilities look wide open.

I’d also add that Mojo is new, and people are still feeling it out by trying to 1:1 things with Cuda.

In the coarse graining code, you use an @parameter-for. Doesn’t that lead to some pretty large code size unrolling that? Or is that less of an issue on GPU?

Great write up! I learned a lot!

My impression is that this is on purpose on their part. They’ve repeatedly stated that by 2026 they will open source the compiler, and I think they’ve wanted a slow adoption ramp in order to spend some more time getting it right first.

Possibly rose-tinted glasses on my part, but I’m optimistic for 2026. Chris Lattner has a pretty strong track record of getting these things right.

Well, switching from Firefox to Waterfox was a pretty easy switch.

A high level walkthrough of FNV Hash.

Bio-Rad Labs | Software Engineer | Full-time | Boulder, Colorado

This position for a small team in Boulder working on instrument development. You would help to build and maintain the data processing pipelines and internal tooling used by research and development for evaluating instrument performance. Portions of this architecture will eventually ship on the instrument itself.

Qualifications:

  * Experience building data processing pipelines / applications and managing data
  * Fluent in Python
  * Experience with relational databases
  * Experience with Docker
  * Comfortable at a command line
  * Comfortable in a Unix environment

Please note, the job req linked here has out of date qualifications, but is the link to apply through: https://careers.bio-rad.com/jobs/software-developer-ii-pytho...