totalperspectiv

This is really exciting. I've been using Mojo off and on for side projects over the last two years.

(copying from some previous Mojo threads) It's got an ownership system adjacent to Rust, comptime similar to Zig, and a first class dependent type system. Even more exciting, is that uses LLVM (to the best of my understanding) in some novel ways and for more optimizations.

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 in the realm of 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.

Carp has been slowly inching forward and ticking those boxes

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.

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.