I couldn’t view this with Firefox or Gnome. ImageMagick to the rescue, though:

convert https://pub-be81109990da4727bc7cd35aa531e6b2.r2.dev/weofihweiof.jpg meme.jpg

There’s some even older UI bits buried around in there:

I’m too lazy to convert that by hand, but here’s what chatgpt converted that to for SQL, for the sake of discussion:

SELECT 
    a.id,
    a.artist_name -- or whatever the name column is in the 'artists' table
FROM artists a
JOIN albums al ON a.id = al.artist_id
JOIN nominations n ON al.id = n.album_id -- assuming nominations are for albums
WHERE al.release_date BETWEEN '1990-01-01' AND '1999-12-31'
AND n.award = 'MTV' -- assuming there's a column that specifies the award name
AND n.won = FALSE
GROUP BY a.id, a.artist_name -- or whatever the name column is in the 'artists' table
ORDER BY COUNT(DISTINCT n.id) DESC, a.artist_name -- ordering by the number of nominations, then by artist name
LIMIT 10;

I like Django’s ORM just fine, but that SQL isn’t too bad (it’s also slightly different than your version though, but works fine as an example). I also like PyPika sometimes for building queries when I’m not using Django or SQLAlchemy, and here’s that version:

q = (
    Query
    .from_(artists)
    .join(albums).on(artists.id == albums.artist_id)
    .join(nominations).on(albums.id == nominations.album_id)
    .select(artists.id, artists.artist_name)  # assuming the column is named artist_name
    .where(albums.release_date.between('1990-01-01', '1999-12-31'))
    .where(nominations.award == 'MTV')
    .where(nominations.won == False)
    .groupby(artists.id, artists.artist_name)
    .orderby(fn.Count(nominations.id).desc(), artists.artist_name)
    .limit(10)
)

I think PyPika answers your concerns about

What if one method wants the result of that but only wants the artists’ names, but another one wanted additional or other fields?

It’s just regular Python code, same as the Django ORM.

I’m pretty excited about PRQL. If anything has a shot at replacing SQL, it’s something like this (taken from their FAQ):

PRQL is open. It’s not designed for a specific database. PRQL will always be fully open-source. There will never be a commercial product.

There’s a long road ahead of it to get serious about replacing SQL. Many places won’t touch it until there’s an ANSI standard and all that. But something built with those goals in mind actually might just do it.

I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?

One interesting thing you could try if you really don’t want to cut back is to try having using an LLM to take your officially supported code and transliterate it to other languages. I haven’t tried it at this scale yet, but LLMs are generally pretty good at tasks like that. I suspect that would work better than whatever templating approach you’ve used before.

If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.