The amount of effort and risk for a clean slate approach is huge.
We need to be pragmatic in our decisions and don’t solely base our decision on principles, but understand the complexity and technicalities of what such move implies, precedence and the engineering culture we want to establish.
Most of the proponent of the clean-slate approach seems to me have only a very partial understanding of the amount of code that needs to ported.
Pfs,multidevice, transit, datasync,discovery,whisper, wallet,multiaccounts, mailservers and more, really all of this in one go? From previous experience I have seen these kind of approaches failing spectacularly a few times, of course that’s not to say that it can’t be done, just that’s is really hard.
It is also worth mentioning that nim is a very young language, and I believe it’s fair to say that adds to the risk (as what happens if a library is not available for nim? we will have to re-implement in it), but that’s something that I don’t really know, as I am not familiar with the nim ecosystem, and I have nothing but respect for the language.
Not to mention that status-go will be a moving target, as we will have to likely make changes to it, which will complicate things.
Historically we have not been good at big-bang/clean slate approaches, many of the initiatives where this was tried have had mixed results (status-sdk, initial status-go move, new-protocol).
We had many discussions about this, and the overall company culture is that we prefer iterative approaches, for reason that should be well understood by now. Divide and conquer, integrate little.
Start with the minimum amount that can be verified, and move on from there (in this case it would be to integrate low level whisper api, make sure it works, and take it from there for example). There is of course a cost involved, compared to a clean slate, but risk is much better managed.
Basically all I am saying is that the clean slate approach should have rock solid arguments for it, and champions who understand the complexity of the effort, as we had many previous discussion on the matter, and both precedence and company culture are not inline with this approach, not to mention the high risk involved with this.