I have mostly written workflow software in Go (SciPipe), not that much low-level algorithmic stuff. Based on my experiences though, if I'd go into algorithmic development, I'd:

1. Choose Go if I'd aim to create a library of components or functions, where I want to use the same language both for the component implementation, as well as for the "glue code" to build the pipeline consisting of many such components.
2. Consider Rust if I'd be implementing stand-alone tools that are supposed to be consumed via commandline, where the last ounce of performance might be critical.

The reason for this is that from my experience, Rust seems way too complex to be used as a "glue language" in a similar manner to how python can be used. Go fits much better into that category, while also being fast enough most of the time, to also implement algorithmic stuff in it.

Go actually has a number of things speaking for it in terms of performance too, although it won't probably ever compete with a language that can make away with a garbage collector completetly. One such thing is that the data structures (structs etc) in Go, are mapped pretty directly to how data is laid out in memory (struct fields will occur sequentially in memory, etc), which makes it easier to optimize performance than in some other langauges of similar complexity.

For getting the last ounces of performance, I'd still at least consider Rust though. I'd personally definitely consider Rust over C++, mainly because I think we BADLY need more reliability and robustness in research code, and I think we should do what we can to achieve that. I think the complexity and ease of shooting yourself in the foot in C++, does not align well with the idea of robust, verifiable, understandable and reliable code, which we need to tackle the reproducibility crisis in science.

My recent experience is that C and C++ are still king for performant one-person projects, but Golang is a better choice for new collaborative projects. Golang computational cost is roughly 1.5x that of similarly optimized C or C++ code; that's an acceptable price to pay for mutually comprehensible, mostly-footgun-free code that can more easily utilize all cores and machines you have access to.

I've had similar discussions with colleagues of mine. My feeling from browsing around this forum and GitHub etc, is that Go would be a good compromise between the speed of C, but with a little more user friendly-ness. My colleagues however don't particularly rate Go as an up and coming bioinformatics language, and many of them are leaning toward Rust (and a couple are on Nim).

I've been weighing up what language I learn next personally, and it would be wise for it to be something more performant that Python I think. It seemed like Go might be an easier transition than C.

For something heavy duty like an aligner, were every iota of performance could really count, I don't personally see Go replacing C variants any time soon.

Based on my colleagues input, I'm leaning toward Rust, as a moderate step down in ease from Python - though I have also been jumping in the deep end with C (but with a long, long way to go).

Hope that's of use!

Did you though also about Julia? It is more productive than C++ and has a comparable speed to C++ (No comparison here with C at all)

Note: This is an open ended discussion.

I have built some bioinformatics tools in Go, and my opinion is that it is very much worth learning. Probably the best thing about it that it truly follows the zen of Python principle that "There should be one-- and preferably only one --obvious way to do it." :) Hence it is a small language, but it offers everything you need for comfortable development. For somebody who already knows programming the barrier to entry is really low. With resources like effective Go, Go by example and tour of Go one can get up to speed in no time.