First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.

Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.

[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.

It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.

I use a combination of a Claude Max subscription and local inference, including qwen3.8-27b, 4bit. I have found qwen to be absolutely useless at anything but very specific, surgical code changes. In my experience, for anything even remotely nuanced, a frontier model is required.

https://www.pbs.org/kenburns/the-west/

facepalm

The author describes Marc Andreessen's Gilded Age slash Roaring 20s lifestyle and attitudes, and then suggests that a hundred years ago, this person may have been referred to as "houseboy".

Marc Andreessen is the hypothetical person from a hundred years ago. It's a scathing criticism of Marc Andreessen.

https://docs.python.org/3/reference/lexical_analysis.html#re...

This has been in the specification since, at latest, Python 2.0, and perhaps earlier.

Any you see defined outside the Python data model are entirely historical, written in contradiction to the spec. Many of them also can't be changed because there is so much code in the wild that depends on them.

*Do not define your own dunder methods!*

Edit: I'm not saying Ansible is an appropriate substitute (it absolutely isn't), rather that `kubectl -f` is not a scalable solution.

Declarative configuration is wholly expressible by imperative languages. The converse is not true. Declarative configuration is appropriate for declaring state (i.e., values), and not for describing procedures.

Stop using half-baked YAML crap and start using real tools.

https://www.wsj.com/articles/stripe-cuts-internal-valuation-...

SQ 2021 Revenue: $17B

SQ 2021 cash and short term investments: $5.3B

Stripe 2021 Revenue: $12B

Similar businesses, operating in the same market, with the nearly the same number of employees (about 8000). Barring exceptional circumstances, we would expect their financial health to be roughly similar.

You said it yourself:

> the leaders have to... [deal] with investors

The economy is contracting and their share price is falling. They could afford to dip into cash and keep everyone on board but their investors are more concerned about propping up the valuation. They don't have two shits to give about the people they're letting go.

One thing in particular from the article that I found especially objectionable:

> For now, the theory is just that—a theory.

This is a conjecture. I expect better from science journalism.

With news of layoffs at Bolt, I wonder how many partners lost sales like mine.

My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language.

What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution.

Python needs a Typescript analogue, with a compiler that targets vanilla Python.

> As part of our automation setup, we continuously run integrity jobs to inspect our Jenkins nodes.

Why on earth would you self-host this in Jenkins? This is a monitoring and alerting problem.

> These jobs check system configurations and properties and look to see if any node is failing those checks.

What year is it? We've solved this with immutable infrastructure or system integrity monitoring. Or both.

> The checks automatically mark Jenkins nodes as offline when any of those checks fail and notifies our Mobile Build & Release team via a Slack message.

"Mark" offline? Why not just terminate it? And why do we care if build nodes come and go? These should be cattle, not pets. If they all die at once, that's bad. If they're cycling in and out, that's business as usual.

> When our Jenkins UI stopped working, we noticed two things:

> 1. We had recently upgraded Jenkins and all its plugins to a newer version

Did they just now learn what an awful idea this is? All of this at once, really?

This isn't so much a Jenkins problem (though let's be clear, Jenkins is a problem) as it is a remedial engineering problem. The top takeaways should be "choose appropriate tools for the task at hand" and "don't make reckless decisions with brittle systems".