On Wed, 12 Jun 2024 at 15:49, FWS Neil <n...@fairwindsoft.com> wrote: > 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.
Agreed, which is why I said they'd be acceptable to me. But I think one important advantage of Python is that it's clear that many people in the community are willing to write tests in it. At PGConf.dev there were a lot of people in the unconference session about this. Also many people already wrote a Postgres testing framework for python, and are using it (see list of projects that Alexander shared). I haven't seen that level of willingness to write tests for any of those other languages (yet). > In addition, the language should scale well to > multiprocessors, because parallel testing is becoming more important every > day. > <snip> > Python is good for package depth and resource availability, but fails IMO in > the > other categories. You can easily pin packages or call a different function based on the version of the package, so I'm not sure what the problem is with package stability. Also chances are we'll pull in very little external packages and rely mostly on the stdlib (which is quite stable). Regarding parallelised running of tests, I agree that's very important. And indeed normally parallelism in python can be a pain (although async/await makes I/O parallelism a lot better at least). But running pytest tests in parallel is extremely easy by using pytest-xdist[1], so I don't really think there's an issue for this specific Python usecase. > 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. I'm assuming this is about spaces vs curly braces for blocks? Now that we have auto formatters for every modern programming language I indeed prefer curly braces myself too. But honestly that's pretty much a tabs vs spaces discussion. [1]: https://pypi.org/project/pytest-xdist/ On Wed, 12 Jun 2024 at 15:49, FWS Neil <n...@fairwindsoft.com> wrote: > > > > 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.
