Thank you for the answer!

I have not previously heard Meson described as a reinvention of Cmake or a CMake clone, nor that it was meant to be. I would think that Meson being as opinionated as it is, including for example the fact that it does not and will not support user-defined functions, precludes it from being a CMake clone. It seems instead to be a build-system with a rather different philosophy and feature-set compared to Cmake. But if that philosophy or that feature-set does not match your needs, then there's obviously no reason to pick it over CMake

Out of curiosity, why do you consider CMake to be the better choice compared to Meson?

Personally I landed on Meson a few years ago, from what I remember chiefly due to simply not liking CMake's DSL and finding Meson easier to work with, despite needing to target a pretty old version for the sake of compatibility. Though Meson is definitely not perfect either; it's highly opinionated, and for example only recently got support for custom build targets putting stuff in sub-directories (as I discovered while writing this comment), so I'll personally be stuck with my workarounds for a good while longer

If you have a couple of hours, and can stomach the AI art, then this video covers a lot of the niceties of C++:

https://www.youtube.com/watch?v=7fGB-hjc2Gc

As soon as uv provides an alternative implementation so you can just run uv run --but-fast I think it will become popular.

You can already do uv run -p pypy and uv run -p graalpy to automatically download and use those versions of Python.

For anyone curious about the number of bugs introduced in each kernel release, LWN.net has a plot of Bugs fixed and introduced in each kernel release.

However, it has the obvious limitation that recent releases will appear to have fewer commits introducing bugs, simply because kernel developers haven't had as much time to find and fix the bugs introduced in those releases. So it'll be a while before we can actually see the consequences (positive or negative) of more widespread LLM usage by kernel developers

I'm just doing my part to reduce global climate change. You're welcome

Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.

Python is dog slow, but if each of your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times

What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?

While Python's start-up time is a lot slower than a corresponding compiled program, in most cases it's not slow enough to matter even if the process itself is short-lived:

$ hyperfine 'python3 -c "pass"'
Benchmark 1: python3 -c "pass" (412 runs)
                mean     ±       σ          min     …     max
  Wall Time      7.1 ms  ±     0.2 ms       6.7 ms  …     8.4 ms
  Memory         9.4 MiB ±     0.1 MiB      9.1 MiB …     9.5 MiB

If you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article's thesis

But you really should be writing those tests regardless of whether or not you or an LLM ends up writing the actual code. That helps ensure that the code actually does what you think it does, and prevents bugs or unintended changes in behavior from sneaking in later when something changes

Granted, I’ve seen one or two articles saying that AI helped find real software bugs, but what’s the ratio there, 1:500 for useful/useless AI bug reports?

It's worth distinguishing between LLM generated bug-reports submitted by randos, and developers themselves using LLMs to look for bugs in their software.

My own experience, with my own code-bases, is that the LLM I use is extremely good at finding real flaws in my code. It'll also nitpick a lot, but it has has become better at triaging issues than it used to be, so that kind of thing is easy to ignore.

Because of that, having an LLM take a look at my code before I push it has become another QC step, along with running tests, linters, and formatters. The end result is higher quality software

It was announced back in February, with the reason being that they spend a lot of time simply preparing releases, rather than actually working on improvements to Mint:

Releasing often is important because it means we get a lot of feedback and bug reports when we introduce changes. We follow the same process over and over again. It’s a process that works very well and it produces these incremental improvements release after release. But it takes a lot of time, and it caps our ambition when it comes to development. With a release every six months plus LMDE, we spend more time testing, fixing, and releasing than developing. https://blog.linuxmint.com/?p=4991

The latest blog-post suggests that their new schedule is already paying off:

Going from a 6-month release schedule to a yearly one was a tough decision to make, but we’re really starting to see it pay off. We’re taking on projects and implementing changes which would previously have been considered too large or ambitious. We’ve got time. We don’t feel rushed. Development feels solid and the OS keeps getting better. https://blog.linuxmint.com/?p=5086

I haven't read the paper in dept, but these are deeply unserious reasons for disparaging it.

Bad research is still bad. The main paper is 9 pages with wide margins, outside of references. This was a few college students publishing their CS research assignment

The length of this paper entirely within the norm for scientific publications. In fact, depending on the type of paper, they can be much shorter. For example, Nature expects submissions at around 2500 words or around 4300 words, depending on the format, while this paper is around 4800 words long (excluding references and SI).

The authors also obviously not "a few college students publishing their CS research assignment": Gloaguen, Mündler, Raychev, Müller, and Vechev.

The “Limitations” section is rather telling:

Another interesting avenue opened by this work is how to improve the automatic generation of useful context files.

Okay, so they already admitted that they started with useless context files, which sabotages their own test.

You know how you fix useless context files? You iterate until they are useful context files!

The entire point of the study was to see what kind of context files were useful and which were useless, which according to the authors was not something that had been done before:

A widespread practice in software development is to tailor coding agents to repositories using context files, such as AGENTS.md. Although this practice is strongly encouraged by agent developers, there is currently no rigorous investigation into whether such context files are actually effective for real-world tasks. In this work, we study this question and evaluate coding agents’ task completion performance in two complementary settings

They found that,

while instructions in the context files are well followed by coding agents, repository overviews, although popular and recommended by model providers, are not helpful.

So when you say that they "admitted that they started with useless context files", you are referring to the results of the study. Complaining that they didn't base their study on the conclusions of that very study is just absurd