From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: adding pytest as a supported test framework |
Date: | 2024-06-16 21:04:41 |
Message-ID: | CA+TgmobEG8cCJdnn_OJaB71XL20HuSNXaosjRhbdE8So-f6F_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 15, 2024 at 6:00 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> > Those young-uns are also the same group who hold their nose when coding in C, and are always clamoring for rewriting Postgres in Rust. And before that, C++. And next year, some other popular language that is clearly better and more popular than C.
>
> Writing a new test framework in a popular language that makes it more
> likely that more people will write more tests and test infrastructure
> is such a completely different thing than suggesting we rewrite
> Postgres in Rust that I feel that this comparison is unfair and,
> frankly, a distraction from the discussion at hand.
I don't really agree with this. We have been told before that we would
attract more developers to our community if only we allowed backend
code to be written in C++ or Rust, and that is not altogether a
different thing than saying that we would attract more test developers
if only we allowed test code to be written in Python or whatever. The
difference is one of degree rather than of kind. We have a lot more
backend code than we do test code, I'm fairly sure, and our tests are
more self-contained: it's not *as* problematic if some tests are
written in one language and others in another as it would be if
different parts of the backend used different languages, and it
wouldn't be *as* hard if at some point we decided we wanted to convert
all remaining code to the new language. So, I have a much harder time
imagining that we would start allowing a new language for backend code
than that we would start allowing a new language for tests, but I
don't think the issues are fundamentally different.
But that said, I'm not sure the programming language is the real
issue. If I really wanted to participate in an open source project,
I'd probably be willing to learn a new programming language to do
that. Maybe some people wouldn't, but I had to learn a whole bunch of
them in college, and learning one more doesn't sound like the biggest
of deals. But, would I feel respected and valued as a participant in
that project? Would I have to use weird tools and follow arcane and
frustrating processes? If I did, *that* would make me give up. I don't
want to say that the choice of programming language doesn't matter at
all, but it seems to me that it might matter more because it's a
symptom of being unwilling to modernize things rather than for its own
sake.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-06-16 21:43:05 | Re: Using LibPq in TAP tests via FFI |
Previous Message | Alvaro Herrera | 2024-06-16 19:59:06 | Re: Remove distprep |