Are you suggesting that AI-written code tends to be more secure than human-written code? Because there are many examples to the contrary, starting with MoltBook.
Tangent: Much like PHP, "modern" CF isn't actually that bad to work with these days. In particular the superset-of-html syntax has been superseded for pure logic by "CFScript" which is just an ECMAScript dialect.
There's even a package manager, test harness, etc. And of course it's JVM hosted so it's fairly easy to use Java stuff (stdlib of otherwise) if what you need doesn't exist in CF.
The linked article isn't describing a form of input sanitization, it's a complete separation between trusted and untrusted contexts. The trusted model has no access to untrusted input, and the untrusted model has no access to tools.
The HN zeitgeist has something of a love/hate relationship with the web, I've noticed. HN in general seems to skew a little older than a lot of online communities, so a lot of HN users were adults back in the early days of the web/Usenet/etc. There's a tendency to view those days with nostalgia, leading a lot of people to feel like the "good old days" of the web were "ruined" by the modern shift into more interactivity, fancier/prettier design, etc. And "web developers" are the ones proximately responsible for the shift, so they get the hate too.
I laugh every time I see someone on HN asserting that the web "shouldn't" be used for anything beyond "documents and lightly interactive content", which is not uncomment. There's some real old-man-yelling-at-clouds energy there.
I once managed to trigger what I think was a race condition in a microwave's beep routine. It was one of the type that does a single long beep rather than individual beeps, and like most it would cut the beep short when you opened the door. But one time, one single time, I managed to open the door PRECISELY as the timer finished, and the beep just didn't stop. I finally closed and opened the door after maybe 30 seconds, and that stopped it.
I was never able to trigger it again, so I have no idea whether it was a race condition or some other random one-in-a-million happenstance, but it makes a fun theory at least.
I've never used a Lisp either, but I get the impression that "forcing you to write the AST" is sort of the secret sauce. That is, if your source code is basically an AST to begin with, then transforming that AST programmatically (i.e. macros) is much more ergonomic. So you do, which means that Lisp ends up operating at a higher level of abstraction than most languages because you can basically create DSL on the fly for whatever you're doing.
That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.
Technically native selects do have a very rudimentary form of filtering: start typing text with the select focused and it will auto-select the first matching option.
E.g. if the select is a list of US states, type "N" and it will jump to Nebraska. Continue into "New" and you'll get New Hampshire, etc.
This is better than nothing (and I personally use it all the time) but not a patch on an actual proper select-with-filtering which, yes, you still need JS to implement properly.
That works if you're dealing with a known set of keys (i.e. what most statically-typed languages would call a struct). It falls down if you need something where the keys are unknowable until runtime, like a lookup table.
I do like dataclasses, though. I find them sneaking into my code more and more as time goes on. Having a declared set of properties is really useful, and it doesn't hurt either that they're syntactically nicer to use.
I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage.
Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience.
I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not?
As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.
Requests is a great example of my point, actually. Creating a brand-new Python venv and running `uv add requests` tells me that a total of 5 packages were added. By contrast, creating a new Rust project and running `cargo add reqwest` (which is morally equivalent to Python's `requests`) results in adding 160 packages, literally 30x as many.
I don't think languages should try to include _everything_ in their stdlib, and indeed trying to do so tends to result in a lot of legacy cruft clogging up the stdlib. But I think there's a sweet spot between having a _very narrow_ stdlib and having to depend on 160 different 3rd-party packages just to make a HTTP request, and having a stdlib with 10 different ways of doing everything because it took a bunch of tries to get it right. (cf. PHP and hacks like `mysql_real_escape_string`, for example.)
Maybe Python also has a historical advantage here. Since the Internet was still pretty nascent when Python got its start, it wasn't the default solution any time you needed a bit of code to solve a well-known problem (I imagine, at least; I was barely alive at that point). So Python could afford to wait and see what would actually make good additions to the stdlib before implementing them.
Compare to Rust which _immediately_ had to run gauntles like "what to do about async", with thousands of people clamoring for a solution _right now_ because they wanted to do async Rust. I can definitely sympathize with Rust's leadership wanted to do the absolute minimum required for async support while they waited for the paradigm to stabilize. And even so, they still get a lot of flak for the design being rushed, e.g. with `Pin`.
So it's obviously a difficult balance to strike, and maybe the solution isn't as simple as "do more in the stdlib". But I'd be curious to see it tried, at least.
I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own.
Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the size of the standard library. Rust and JS are both famous for having minimal standard libraries, and what do you know, they tend to have crazy-deep dependency graphs. On the other hand, Python is famous for being "batteries included", and if you look at Python project dependency graphs, they're much less crazy than JS or Rust. E.g. even a higher-level framework like FastAPI, that itself depends on lower-level frameworks, has only a dozen or so dependencies. A Python app that I maintain for work, which has over 20 top-level dependencies, only expands to ~100 once those 20 are fully resolved. I really think a lot of it comes down to the standard library backstopping the most common things that everybody needs.
So maybe it would improve the situation to just expand the standard library a bit? Maybe this would be hiding the problem more than solving it, since all that code would still have to be maintained and would still be vulnerable to getting pwned, but other languages manage somehow.
SPy looks really interesting! I've run across projects like MyPyc before, but as you say they kill a lot of the "joy" of Python by removing things like decorators and operator overloading.
One question, more out of curiosity than any genuine need: do you (or do you plan to) support any kind of trait/interface based polymorphism? E.g. it's a pretty common idiom to have a function that works on "any iterable type" and that sort of thing, which seems like it would be best modeled as an interface. I guess you could argue that's at odds with Python's tradition of "duck typing" but then again, so is static typing in general so I'm not sure.
Reader mode is based on a whole slew of heuristics including tag names, class names, things like link-to-text-content ratio, and other stuff I can't recall. IIRC it considers semantic tag names a stronger signal than e.g. class names, so having <article> in your page isn't necessary but helps a lot.
Seems unlikely to work given (if I understood correctly) the main direct consumer is Babel, another OSS project that is known to have had trouble with funding in the past. If he starts asking for license fees, Babel eill just be forced to make do with the latest OSS version, fork it or whatever, and the rest of the world will never know.