feat: ✨ post on why to use Rust for making software

[lwjohnst86]

Description

This expands on why to use Rust for building e.g. CLI, web-apps and other "formal" software tools.

Closes #223

Needs a thorough review.

Checklist

• Ran just run-all

[martonvago]

I look forward to getting my hands dirty!

Just some typos.

[martonvago]

🎉

[joelostblom]

Looks good! I mostly have linguistic suggestions and a few other questions/comments.

[joelostblom]

Suggested change

	- Rust is known to have a steep learning curve, which means we need to invest
	time in learning it and will slow down our development speed. However, like
	learning any new skill, once learned, development will speed up.
	- We might become annoyed with the slower compilation times and higher local
	resource usage during development. But this is a tradeoff for the benefits for
	strictness and safety. Plus, there are many tools and techniques to mitigate
	this.

These two are basically a rehash of what is written in the general drawback section without any additional comments on how they would apply to us specifically, so I think they are fine to drop.

[joelostblom]

Suggested change

	- Because Rust isn't as common in research settings, we probably won't get as
	many contributions and external collaborators. However, this might not be an
	issue for us. For one, there's a strong trend for more Rust tools and
	libraries being used in research settings because of its benefits, so this may
	change in the future. For another, getting contributions is difficult for any
	language, and even more so in research settings, so even from the start we
	never expected many external contributions.
	- The potential of getting fewer external contributions and collaborators
	is not a major concern since we generally (sadly) expect this number to be
	close to zero for a new tool written in any language,
	particularly in a research setting like this.
	Likely, the biggest predictor for attracting collaborators to a project,
	is that the project brings value that allows it to reach a wide uptake.
	As such, selecting the tools that helps us build the best possible software,
	are more likely to generate contributors in the long run.
	In addition, there's a strong trend for more Rust tools and
	libraries being used in research settings because,
	so the potential contributor and collaborator pool
	is likely to grow notably over time.

This is a good example of what I'm referring to in my post above in terms of adding additional context about how a potential drawback applies or doesn't apply to us specifically.

[joelostblom]

Suggested change

	- It might be harder for us to build most of our software in Rust, but write
	code to process data in Python, which will require some context switching
	between languages. However, this is also good practice for us to learn how to
	work in multiple languages and to learn that we're capable of using the right
	tool for the right task, even if it isn't something we're familiar with or
	expertise in.
	- It might become difficult for us to build most software in Rust, while writing
	code to process data in Python, since this requires context switching
	between languages. However, this is also an opportunity for us to practice
	working in multiple languages and to learn that we're capable of using the right
	tool for the right task, even if it isn't something we're familiar with or
	have expertise in. Widening our expertise and learning about best practices
	in Rust could also bring about positive benefits for our Python coding habits.

[joelostblom]

Suggested change

	- There may be some functionality that we've developed in Python that we won't
	be able to use in Rust. This isn't a major issue, as most of our software so
	far has been built as command-line tools, rather than libraries with reusable
	functionality.
	- There may be some functionality that we've already developed in Python that we
	would like to also use in a Rust-based tool. This should not be a major issue
	as most of our software includes a CLI been built as command-line tools, rather than libraries with reusable
	functionality. If library code needs to be shared and we don't want to
	re-implement it in rust, we can use [PyO3](https://github.com/PyO3/pyo3) to
	call one language from the other.

[joelostblom]

Suggested change

	- Because of the smaller ecosystem, we may have to build more of our own tools
	and libraries.
	- Because of the smaller ecosystem, we may have to build more of our own tools
	and libraries. While this could become laborious, we believe that it will be a valuable asset for individual team members to learn and develop their value as software engineers.