MacOS and docker is asking for trouble.

That's a real problem! MacOS and Docker are extremely common for development, and a scripting language like Python should just work with them, not just at the language level (which is good enough) but in the ecosystem and tooling. The latter is what Astral is trying to improve.

I used it briefly when it first came out; otherwise no, my employers have used Slack.

The first part is confusing what "middleware" means. Rather than "duplicating" functionality, it connects libraries (I'm guessing this is what you meant). But that has nothing to do with a language being compiled versus "directly executed", because compilation doesn't connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of "middleware" between interpreted code and the operating system, but middleware typically doesn't describe anything so critical to a piece of software that the software can't run without it, so even that isn't really a correct use of the term.

The second part is just...completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. "Most original code" is in an actual systems language like C.

(As a side note, Python wasn't the first scripting language, and it didn't become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)

Hm, I'm not sure what you're looking for, then.

How are fish abbreviations different from nushell aliases for working on temporary machines? Surely your Windows sandboxes don't have fish installed?

It's so out of date that Deb and Ian are no longer together

(...this is actually true, not just a joke)

Extension modules can be, and are, written in Rust and C++. And PyPy has a compatibility layer to run extensions (such as numpy) that are written for CPython.

The reason extension modules are typically in C is of course the API is in C, but that's true of cffi as well (though you're right that cffi is more portable). And the reason the API is in C is more fundamental than "CPython is written in C".

If you think anything in software has worked "perfectly fine for the past two decades", you're probably not looking closely enough.

I exaggerate, but honestly, not much.

Did you read the linked Q&A?

What do you get if you run /bin/bash --version?

No, you leapt directly from what I said, which was relevant on its own, to an absurdly stronger claim.

I didn't say that humans and AI are the same. I think the original comment, that modern AI is "smart enough to be tricked", is essentially true: not in the sense that humans are conscious of being "tricked", but in a similar way to how humans can be misled or can misunderstand a rule they're supposed to be following. That's certainly a property of the complexity of system, and the comment below it, to which I originally responded, seemed to imply that being "too complicated to have precise guidelines" somehow demonstrates that AI are not "smart". But of course "smart" entities, such as humans, share that exact property of being "too complicated to have precise guidelines", which was my point!

Well, it's still true that mem::forget is safe, and Rust will almost certainly never change that. As noted in the blog post, this makes certain patterns unsound.

Not squashing before review, squashing on merge (i.e. after review). Squashed merges make these easy, regardless of whether the original commits in the pull request were messy:

• determining what changed between versions
• finding and reverting regressions

Win32 is the foundational Windows OS interface on which WinRT, C++/CX, MFC, etc are all built. It's not deprecated, it's just very low-level. https://en.m.wikipedia.org/wiki/Windows_API