Have follow-up benchmarks vs BioJulia been done since 2019? If I remember correctly at the time, the result was that BioJulia was faster once you consider that it did validation.
We haven't done too many comparisons with BioJulia since that paper, although we did address the (valid) issues they raised such as data validation (i.e. Seq now validates input data by default, but this can be optionally disabled). We did compare against them in our last paper in a sequence alignment benchmark: https://www.nature.com/articles/s41587-021-00985-6 (check the supplement).
I am a CS person who works with bioinformaticians every day as part of my job. I really like that Seq seems to have built-in some parallelization ability. I spend no small amount of time in my day job doing that manually in R with RcppParallel for loops that are totally independent across each iteration. Bioinformaticians are often educated to use a specific programming language and environment. They aren't usually l…
Very interesting! I noticed a similar phenomenon in the GIS space. All of my colleagues with formal training in GIS use ArcGIS and its Python API, but those without such background gravitate towards FLOSS solutions.
I am aware of only one case where a community migrated to other software. Many economists I know switched from Stata to R. Some of them later moved on to Python.
> Seq is a Python-compatible language, and the vast majority of Python programs should work without any modifications > Seq is able to outperform Python code by up to 160x. So ... a reimplementation of Python that can outperform cpython by over 100 times? I know literally nothing about this project, but I have to say that rings pretty false for me. Hell, even PyPy has trouble with many applications. (Plus they're cla…
Most newer languages will give you multiple orders of magnitude better performance than python.
Python’s main advantage was that it was easier than some of its competitors (C++/Java). But that is no longer the case with modern languages (Nim/Crystal/Julia/JavaScript) being both faster and comparably as easy (or easier).
It is now coasting off its momentum, mostly do to the vast amount of (usually poorly designed) open source libraries. That and Jupyter.
> Seq is a Python-compatible language, and the vast majority of Python programs should work without any modifications > Seq is able to outperform Python code by up to 160x. So ... a reimplementation of Python that can outperform cpython by over 100 times? I know literally nothing about this project, but I have to say that rings pretty false for me. Hell, even PyPy has trouble with many applications. (Plus they're cla…
I also know literally nothing about this particular project, but why not? If you support a small restricted subset of Python it's completely doable under certain conditions for specific types of programs . E.g., Numba can easily outperform Python 100-1000x in numerical applications (done it myself multiple times), simply because it jit-compiles the code by first translating it to LLVM IR.
(minor contributor) I’ve been following the project for a while and pleasantly surprised by the ability to manually convert Python programs to Seq without needing to make too many changes. Note, most of my experimentation has been with smallish programs I’ve written. I like that I can still think “Pythonically” and compose mostly correct Seq code using familiar idioms, e.g. list/set/dict comprehensions. The standard library is very readable and a source for “from import” type functionality. Some of the other features I’ve come to appreciate: pipeline operator |>, JIT compile or create an executable (seqc run, seqc build), match statements, and strong typing.
Typically, any high performance (low latency or high throughput) genomics/bioinformatics applicaiton is not going to be written in plain Python, except possibly for prototyping. Instead, nearly all codes today are written in C++ or Java, with some sort of command and control in Python or a DAG-based workflow scheduler. I don't expect the community will adopt other languages at a large scale. My hope, though, is that…
I recall that the group that created Spark had a bioinformatics project on Spark but I don't know what happened to it. All I could find now is a paper[1] hosted by databricks.