On Tue, Jun 11, 2024 at 4:48 PM Noah Misch <n...@leadboat.com> wrote: > If we're going to test in a non-Perl language, I'd pick C over Python.
We already test in C, though? If the complaint is that those tests are driven by Perl, I agree that something like libcheck or GTest or whatever people are using nowadays would be nicer. But that can be added at any point; the activation energy for a new C-based test runner seems pretty small. IMO, there's no reason to pick it _over_ another language, when we already support C tests and agree that developers need to be fluent in C. > We'd need a library like today's Perl > PostgreSQL::Test to make C-language tests nice, but the same would apply to > any new language. I think the effort required in rebuilding end-to-end tests in C is going to be a lot different than in pretty much any other modern high-level language, so I don't agree that "the same would apply". For the five problem statements I put forward, I think C moves the needle for zero of them. It neither solves the problems we have nor gives us stronger tools to solve them ourselves. And for my personally motivating use case of OAuth, where I need to manipulate HTTP and JSON and TLS and so on and so forth, implementing all of that in C would be an absolute nightmare. Given that choice, I would rather use Perl -- and that's saying something, because I like C a lot more than I like Perl -- because it's the difference between being given a rusty but still functional table saw, and being given a box of Legos to build a "better" table saw, when all I want to do is cut a 2x4 in half and move on with my work. I will use the rusty saw if I have to. But I want to get a better saw -- that somebody else with experience in making saws has constructed, and other people are pretty happy with -- as opposed to building my own. > I also want the initial scope to be the new language coexisting with the > existing Perl tests. Strongly agreed. Thanks, --Jacob
