I think it actually is less of a risk because it requires less work in the short term, as explained in the blog post by listing the Gitea features that can be re-used by fedeproxy.
As time passes switching the language four months from now becomes a lot harder, primarily because:
- The code base grows and developers (including myself) naturally become more and more reluctant to abandon it, even for good reasons.
- As more features are implemented in fedeproxy which are redundant with what Gitea already has, not only is this effort wasted, it also lowers the incentive to reuse the Gitea codebase (why reuse something that’s already there?)
- fedeproxy will be deployed and have users: migrating the deployed servers and the users from a codebase to another is additional work and a significant one
Since swithcing to Go is currently less risky than sticking with the current codebase and that delaying the decision actually increases both risks and amount of work, I think it would be self defeating to delay. It could make sense to never switch to Go, but I can’t see any upside in delaying.
I studied the code and in my opinion it is not a good fit, although it has been a source of inspiration for the current implementation of fedeproxy. The primary reasons are:
- It is still in experimental stage (just as fedeproxy at the moment)
- It is not actively developped (last commit was five months ago)