Can Bitcoin Core be rewritten in another language, let's say Rust, and could such an implementation supplant the current one in C++ without the users of Bitcoin experiencing some sort of reset/lost of funds?
Languages come and go and I was thinking that decades ahead the world may be in the similar situation with respect to C++ as it is today with respect to Fortran.
There are many implementations of the Bitcoin protocol written in other languages, e.g., Bcoin in JavaScript, btcd in Go, bitcoin-s in Scala, etc.
Bitcoin Core is widely considered as the "reference implementation" and it is certainly the most widely used implementation on the network. Without a written specification, the authoritative resource, if consensus diverges between implementations, would generally be considered the Bitcoin Core codebase.
In terms of Rust, there is a Bitcoin library called rust-bitcoin, but as it says in the rust-bitcoin README:
This library must not be used for consensus code (i.e. fully validating blockchain data). It technically supports doing this, but doing so is very ill-advised because there are many deviations, known and unknown, between this library and the Bitcoin Core reference implementation. In a consensus based cryptocurrency such as Bitcoin it is critical that all parties are using the same rules to validate data, and this library is simply unable to implement the same rules as Core.
Given the complexity of both C++ and Rust, it is unlikely that this will ever be fixed, and there are no plans to do so. Of course, patches to fix specific consensus incompatibilities are welcome.
There would be two possible ways a Rust implementation could "supplant" the C++ Bitcoin Core implementation (assuming supplanting is a healthy goal which is disputed).
One would be more and more users running a full node written in Rust, perhaps based on rust-bitcoin, until it became the most widely run implementation on the network. Arguably this would be a path to supplanting Bitcoin Core as the "reference implementation." (Some would argue that Bitcoin Core is the reference implementation because it is based on Satoshi's original client and a new implementation should never be considered the "reference implementation.")
The alternative would be Rust code is introduced into Bitcoin Core, gradually replacing the C++ code in Bitcoin Core. The latter has been discussed to a greater extent than the former although if this was to ever happen it would be a long term project.
There are arguments against introducing Rust code to the Bitcoin Core codebase and they were discussed in this Sydney Socratic Seminar in May 2020. With permission I include this quote from Rusty Russell:
I really like Rust. It is going from strength to strength and it has got definite merit. But you have got an existing expertise who have tooled up in a certain language. Some of that is self selected but whether that is true or not they exist. Now you are asking people to learn two languages. If you want to broadly read the codebase you have to know two languages and that is a significant burden. Perhaps in five years time when Rust is perhaps an obvious successor to C++ then that intersection… Arguing that we will get more contributors for Rust is probably not true. You might get some different contributors but C++ is pretty well known now. There is the sexy argument. “Work on this, it is in Rust” Unfortunately that will become less compelling too over time. As Rust gets bigger and more projects are using it and there are other cool things you could be doing with Rust anyway. It would be better to do stuff in Rust as far as security. I am cautiously hopeful that the size of bitcoind is going down not up. Stuff should be farmed out to the wallet etc with better RPCs and better library calls so it is not this monolithic project anymore. The argument that we are going to be introducing all these security holes if we don’t use Rust is probably weaker. As you said the last thing that will change is the consensus code. That said I like projects that stick to two languages. It is really common to have projects where you have to know multiple languages to deal with them. Working around the edges and reworking some of the tooling in Rust, building up those skills slowly is definitely the way forward. It will take longer than you want and you hope but it is a pretty clear direction to head in. But head in in terms of a decade we will be talking about finally rewriting the core in Rust. It is not going to happen overnight.
As Prayank says in an above comment, Bitcoin Core functional tests (not unit tests; they are in C++) are written in Python. So you already need to know C++ and Python to contribute to and review the entire Core codebase. If Rust was introduced that would be introducing a third language.
It is extremely difficult to write a specification for a complex format that is 100% watertight and has no poorly defined corner cases. Further even if the specification itself is watertight it's extremely difficult to implement it without making any mistakes. I can't find a link right now but I remember a study posted recently about differences in validation behavior between different implementations of a common signature scheme.
This leads to a problem in consensus-based protocols like bitcoin, if there are multiple implementations then they might disagree about whether a given block is valid, either because someone accidentally ran into a corner case or because a malicious actor is submitting blocks deliberately crafted to run into corner cases.
If a minority implementation accepts a block that the implementation used by the majority of miners rejects, then little harm is done, the "strongest chain" rules mean that everyone follows the rules set by the majority implementation.
But if the minority implementation rejects a block and the majority implementation accepts it then there will be a fork. Users of the minority implementation will stop seeing new blocks from the main chain and (if the minority implementation has mining support) may start to form their own chain with conflicting history.
So using a new implementation for "full validation" bitcoin chain processing is risky, even if the implementer has gone through the whole history so-far and checked it validates with their new implementation, users of that implementation could find themselves cut off from the rest of the network at any time.
pythonincluding tests: github.com/bitcoin/bitcoin/tree/master/test and tools: github.com/bitcoin/bitcoin/tree/master/contrib