Part (2/2):
Finally, I would be remiss if I didn't mention that there clearly _are_ some benefits to (modern) C++. First, if you choose C++, I would set a minimum version no earlier than C++17. It adds a lot of important and nice new features that make writing clean, expressive and efficient code easier. C++ wins over almost all other languages in terms of library availability. If there is a library to do something, then C++ almost certainly has a library for it. Of course, the burden is on you to vet the quality and dependability of that library, but you can, with care, avoid a lot of wheel re-inventing. Second, C++ is very widespread. If you pick an arbitrary developer from the population, the chances are _much_ higher that they will know some C++ (though perhaps not modern C++) than that they will know any Rust. This also means the community is bigger and so you'll find more resources accumulated over years of others learning and struggling with the language — and there will be extensive material online for even the darkest and most obscure crevices of the language (and the common build systems like CMake). Finally, though both Rust and C++ are proper "low-level" languages that give you tremendous control over exactly how your program does what it does and how it interacts with the hardware, C++ has accumulated a few more features over it's life than has Rust, and there are some capabilities that are mostly unique to C++ at this point. For example, developing software in Rust, one feature that we missed from C++ recently is the ability to templatize a function or class on a non-type template parameter (e.g. templatizing on an integral constant). This is useful, when (automatically) instantiating specialized implementations of a function for e.g. k-mers of a specific length. This type of genericization based on values rather than types is an artifact of the (largely unexpected) expressiveness of the C++ template system. It's worth noting that features like this, that are certainly useful (even if quite niche) have a tendency to eventually make their way into languages like Rust that are open to them. For example, there is a Rust issue tracking the development of const generics, that would provide such functionality. They've made a lot of progress and the feature is very likely to make it into the language soon. However, by virtue of the sheer size of C++, there are likely to be a number of such features like this that already exist in C++ but may not yet be (or ever be?) in Rust.
At the end of the day, it would obviously be great to learn both languages. There's almost never a down side to learning a new language, as it helps to improve your programming ability and the tools you have to think about different problems. The issue is that learning new things takes time, and so there is a cost associated with learning a new language. If your primary goal is to integrate with the libraries / tools of others, then C++ is a more common language and is likely to let you plug in, more immediately, to a large number of existing projects. However, if your primary goal is to build and maintain your own tools, then it's my opinion that, in 2020, Rust provides a much better developer experience and you don't have to give up on the efficiency that you get from a language like C++.
Golang assembly is annoying, but it's not that big a step over SIMD intrinsics. My employer has open-sourced a bunch of examples at https://github.com/grailbio/base/tree/master/simd and https://github.com/grailbio/bio/tree/master/biosimd .
Cool packages. Thanks for sharing.
Certain folks on Biostar slack are fans of
rust(@Rob Patro, @Wouter).c++will make you generally marketable (though you probably have enough skills not to need that).