> On Jun 12, 2024, at 6:40 AM, Jelte Fennema-Nio <postgres@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.