Oh no, it seems that I’m late again and didn’t see it until this thread was so active. I hope this comment will not cause disturb to other participants.
First of all, as a developer who mainly uses Python, it’s nice that someone can make OSM become like a python (just kidding (that’s another joke, why are you calling a crab)) It really makes it easy to attract developers to participate because python truly used more widely.
However, please note that for a project of such a large scale as OSM, any disruptive change is a disaster. Even if you reimplement the backend of the OSM API in any new language, you must ensure that it can be compared with the current one. projects are compatible, like LEGO bricks. This means that you’d better implement API0.6 first (in fact, my own python reading and writing library is also considering implementing support for multiple versions of the API (including the one that Jochen Topf is researching) by overloading classes, but the most important thing is It must be the one currently being used)
Sorry, I’ve seen your reply on GitHub, thank you for making stable transition an important part of the new backend.
(There may be some overly excited comments about MongoDB here, which have been deleted.)
After reading the reply on GitHub, I found that PgSQL support will still be considered, so I feel relieved. Please note that this does not mean that I expect to prevent all change
You can rest assured that OSM has a lot of room for improvement, both from the front end and the back end. The core bottleneck may be the lack of a reviewer with enough time and a person who has the time to write code and contribute.
Additionally, this is a good way for us to add more useful features to OSM, such as support and search of hashtags that sparked a very heated discussion in another thread
Finally, if you choose to reimplement an ancient backend in a modern language in the last few months of 2023, then why not consider trying Poetry, the most modern Python package manager currently available?