Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at the Mojo language for bioinformatics

viralinstruction.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: A look at the Mojo language for bioinformatics

#91

Post by skwb »

dr_kiszonka wrote: post #83

Folks using multiple languages, what is your workflow? 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. How do you make it work? Also, after so many years u…

Use python and write my results in a CSV that I quickly import into R and do my fancy stats.

Tbf python's stats implementations can be garbage; the last time I checked you can't do multiple levels for hierarchical regression.

Re: A look at the Mojo language for bioinformatics

#92

Post by eviks »

zer00eyz wrote: post #43
jakobnissen wrote: post #16

Earlier quoted context omitted.

Author here. I do know about VMs. Is it too lazy for me to write that article and not bother to install a VM with Mojo (and Rust and Julia, to benchmark in the same environment)? Maybe. If this was for my work I certainly would have felt compelled to. 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…

>> Is it too lazy for me to write that article and not bother to install a VM with Mojo Yes. Would you talk about a book you didn't read? Or a movie you didn't see? Not on any meaningful level.

But he did read the "book" (source code). But ignoring analogies, can you cite a specific benefit to running the benchmark when discussing parsing correctness?

Re: A look at the Mojo language for bioinformatics

#93

Post by pjmlp »

pests wrote: post #44
pjmlp wrote: post #15

Earlier quoted context omitted.

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.

Chris Lattner has made a few comments here about Mojo the last few months. https://news.ycombinator.com/threads?id=chrislattner Here's his comment on swift for tensorflow: https://news.ycombinator.com/item?id=37330031

In case you missed it, he was replying to me...

Re: A look at the Mojo language for bioinformatics

#94

Post by pjmlp »

coldtea wrote: post #42
pjmlp wrote: post #22

Earlier quoted context omitted.

Apparently it had Google's money backing, for what it is worth. I never believed into it, because Swift is as relevant as Objective-C outside NeXT/Apple's platforms, and not the kind of programming language that the research community cares about.

> Apparently it had Google's money backing, for what it is worth You mean they paid to have it created, like they pay for thousands of other things. But it was never really pushed, the way they push things they want to promote.

It certainly got more love than Dart 1.0.

Re: A look at the Mojo language for bioinformatics

#95

Post by _huayra_ »

dr_kiszonka wrote: post #83

Folks using multiple languages, what is your workflow? 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. How do you make it work? Also, after so many years u…

It's hard to learn a language for fun, so I'd pick something that fits your needs to build something (or even just your curiosity). Elixir and Prolog, although both cool, might not fit the bill because they really excel at one particular thing.

Golang is a popular answer, as you can start building stuff with it fairly quickly (especially compared to Rust). Java can also be useful if you haven't learned it and find a use case (although you will hear it bemoaned as the "New COBOL", there is still a lot of work done using it).

Re: A look at the Mojo language for bioinformatics

#96

Post by jakobnissen »

beanjuiceII wrote: post #50
jdiaz97 wrote: post #37

Earlier quoted context omitted.

True, but the title of the blog is about Bioinformatics, and like another comment said: > 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 Considering that, do you need AOT, memory ownership for doing plotting and statistics? I'd argue not, and that's why R and Python are so popular in Bio.

doesn't this make more sense to have a python like language then for speed? and python for all that other stuff. so learn one'ish language and get it all?

Yes. But the big problem is that all the things that make Python Python is also the things that make it slow. People have tried again and again to make a fast Python, and failed. And from my first impressions of Mojo, it's not very much like Python at all.

Re: A look at the Mojo language for bioinformatics

#97

Post by jakobnissen »

FridgeSeal wrote: post #46
adgjlsfhk1 wrote: post #41

Earlier quoted context omitted.

do you know why debug mode for rust is so slow? is it also compiling without any optimization by default? it's it checks for overflow?

The optimisation passes are expensive (not the largest source of compile time duration though). Debug mode is designed to build as-fast-as-possible while still being correct, so that you can run your binary (with debug symbols) ASAP. Overflow checks are present even in release mode, and some write-ups seem to indicate they have less overhead than you’d think. Rust lets your configure your cargo configs to apply some…

That's not right, Rust only checks for overflow in release mode for numbers where its value is known at compile time. In debug mode all operations are checked for overflow.

Re: A look at the Mojo language for bioinformatics

#98

Post by __MatrixMan__ »

getoffmycase wrote: post #79
__MatrixMan__ wrote: post #19

Earlier quoted context omitted.

As someone who is considering a switch from generic software engineering towards bioinformatics, what would you say the pain points are? If this is not the way to remove workflow friction, what is?

Honestly the major pain point is that the grad student that wrote the package you need is no longer maintaining it because they’ve graduated. Also the code they wrote sucks, but whatever. I’m wary of software engineers coming over the bioinformatics because they never have the domain expertise required to make meaningful contributions, and yet many think they know everything.

Yeah, I'm wary of being that guy too. My current approach is the slow one: first get a biochemistry degree.

Re: A look at the Mojo language for bioinformatics

#99

Post by pests »

pjmlp wrote: post #93
pests wrote: post #44

Earlier quoted context omitted.

Chris Lattner has made a few comments here about Mojo the last few months. https://news.ycombinator.com/threads?id=chrislattner Here's his comment on swift for tensorflow: https://news.ycombinator.com/item?id=37330031

In case you missed it, he was replying to me...

Haha, oops my bad. Thats funny though.

Re: A look at the Mojo language for bioinformatics

#100

Post by andyferris »

chaxor wrote: post #89
gandalfgeek wrote: post #76

> 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! Python is a juggernaut with total control of the ML space and is a huge part (even if less dominant) in modern scienti…

I was interested in trying our mojo. Then I looked at it booked out quick. No one will use a language that isn't free and open source. If mojo was free and open source (wasn't a company), and didn't just give out binaries with a 'trust me bro' stamp if approval, then I would have worked with it. But it's not, so I will never use it.

I get your viewpoint. However, in terms of numbers, I suspect >90% of the populace (even research populace) will care that it is free-as-in-beer and that's all. So from the VC's point of view...
Post reply on HN