Our great sponsors
-
salmon
🐟 🍣 🍱 Highly-accurate & wicked fast transcript-level quantification from RNA-seq reads using selective alignment (by COMBINE-lab)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Rust makes distribution and maintenance near trivial. My lab develops a fairly widely-used tool, salmon, for the quantification of transcript expression from RNA-seq data. This tool is written in C++14, and has a substantial number of dependencies. The process of updating the tool (e.g. bumping dependencies) and cutting a new release is painful. To maintain widespread availability, we distribute this tool using bioconda which uses it's own CI and setup to build new releases for (in our case) Linux and MacOS. Things break all the time. For example, recently, they bumped the compiler used to build packages. This changed some default "implementation defined" behavior, causing previously functioning code to fail. We didn't find this locally, because we didn't test that specific compiler version. When we tried to release a new version, we had to go back and fix things etc. This is not just because different compilers exist, but because the C++ specification is soooo complicated and the set of undefined and implementation defined behavior is sooo broad that it's very brittle and it's easy for things to "break" via bitrot. However, the stability provided by Rust has been phenomenal so far. In our code, we only use stable Rust features, and we have benefited tremendously from the empirical guarantee that valid Rust code (except in exceptional cases like latent bugs in the language) will remain valid. While not all crates follow it religiously, there is a reasonable respect for semantic versioning. Thus, cutting a new release of one of our Rust tools is often as simple as just updating the Cargo.toml (and Cargo.lock in the case of applications), tagging a new release in GitHub, and letting the bioconda CI do it's business with the tagged artifacts. The build "scripts" are almost always trivial because the builds just work, across platforms, across CIs, etc. Now, new projects like cargo dist look like they make this process even simpler.
Rust makes distribution and maintenance near trivial. My lab develops a fairly widely-used tool, salmon, for the quantification of transcript expression from RNA-seq data. This tool is written in C++14, and has a substantial number of dependencies. The process of updating the tool (e.g. bumping dependencies) and cutting a new release is painful. To maintain widespread availability, we distribute this tool using bioconda which uses it's own CI and setup to build new releases for (in our case) Linux and MacOS. Things break all the time. For example, recently, they bumped the compiler used to build packages. This changed some default "implementation defined" behavior, causing previously functioning code to fail. We didn't find this locally, because we didn't test that specific compiler version. When we tried to release a new version, we had to go back and fix things etc. This is not just because different compilers exist, but because the C++ specification is soooo complicated and the set of undefined and implementation defined behavior is sooo broad that it's very brittle and it's easy for things to "break" via bitrot. However, the stability provided by Rust has been phenomenal so far. In our code, we only use stable Rust features, and we have benefited tremendously from the empirical guarantee that valid Rust code (except in exceptional cases like latent bugs in the language) will remain valid. While not all crates follow it religiously, there is a reasonable respect for semantic versioning. Thus, cutting a new release of one of our Rust tools is often as simple as just updating the Cargo.toml (and Cargo.lock in the case of applications), tagging a new release in GitHub, and letting the bioconda CI do it's business with the tagged artifacts. The build "scripts" are almost always trivial because the builds just work, across platforms, across CIs, etc. Now, new projects like cargo dist look like they make this process even simpler.
Perhaps MPI?