> On Jun 12, 2024, at 6:40 AM, Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > > I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable > choices for me (and possibly some more). They allow some type of > introspection, they have a garbage collector, and their general > tooling is quite good. >
Having used Python for 15+ years and then abandoned it for all projects I would say the single most important points for a long term project like Postgres is, not necessarily in order, package stability, package depth, semantic versioning, available resources, and multiprocessor support. The reason I abandoned Python was for the constant API breaks in packages. Yes, python is a great language to teach in school for a one-time class project, but that is not Postgres’s use-case. Remember that Fortran and Pascal were the darlings for teaching in school prior to Python and no-one uses them any more. Yes Python innovates fast and is fashionable. But again, not Postgres’s use-case. I believe that anyone coming out of school these days would have a relatively easy transition to any of Go, Rust, Kotlin, Swift, etc. In other words, any of the modern languages. In addition, the language should scale well to multiprocessors, because parallel testing is becoming more important every day. If the Postgres project is going to pick a new language for testing, it should pick a language for the next 50 years based on the projects needs. Python is good for package depth and resource availability, but fails IMO in the other categories. My experience with python where the program flow can change because of non-visible characters is a terrible way to write robust long term maintainable code. Because of this most of the modern languages are going to be closer in style to Postgres’s C code base than Python.
