When I run a game I don't care of the dev used C or whatever. Only programmers care about the syntactic representation.

I need the machine code/byte code patterns/geometric/color gradient data.

Eventually Python will be what you see on screen but no cPython interpreter program as we know it will be running

The model will have an internal awareness of the result to return without running an actual REPL

https://dev.to/zijianhuang/prompt-to-ai-generated-binary-is-...

https://platform.claude.com/docs/en/agents-and-tools/tool-us... Also Claude Cowork, etc.

1. You don't need compilation... run and test faster. Compilers were primarily built to prevent human error, and only very secondarily to guard your business logic.

2. Your validators quite often need to evolve. With Python or JS, this is a pydantic edit + run. Imagine 3–4 iterations of the same in Rust?

3. Composition. The entire cycle of software changes. An agentic system takes orders from a human, reads some kind of cache and snippets, writes/combines snippets, tests it, runs it, and fixes it. This almost pushes you toward snippets the size of a function, which still need to be covered with tests. I can easily build 10 function-sized Python files and write an agent that will mix and match 3 of them into a final result. With a compiled language, you'd need to compile 10 times — or store the binaries and think about what platform they'll execute on, etc.

I love the fact that the author is questioning this. No doubt the market for your favorite language will change. 80% of languages will go away — there is no market anymore for such a big variety of languages.

If you've managed software teams before, this won't be new. You just need to make sure the team does the right things. But you don't want to inject yourself on the critical path of everything. That's micro managing. People hate it and it's counter productive. You need to instead delegate responsibility and check that there is a good process with checks and balances that ensures things are done right.

If you are vibe coding, one shotting, etc. you are essentially operating without guards rails. You won't catch mistakes that are being made. You aren't doing the due diligence of verifying that what was delivered is the same as what was being asked for.

But if you do use guard rails, most of the engineering effort (i.e. your time) goes into building mechanisms to prove that what is being delivered is fit for purpose. And that needs to lean heavily on tools that verify things. Compilers, linters, test suites, headless browser based scenario tests, elaborate benchmarks, etc. Anything you can throw at this. The more the better. Even code quality issues are something you can catch and fix with tools. Code duplication issues are detectable. Poor cohesiveness and high coupling are simple metrics that you can optimize for.

With AI in the mix, all of that gets run automatically and you create a feedback loop where any introduced problem is more likely to be caught early. If you are a good senior engineer, you would have been doing all of this anyway. Because it compensates for your own inability to not make mistakes. With AI, you just need to do more of it.

I've dabbled with a few generated code bases in Go in the last few months. I have about 3 decades of experience with other languages. But not a lot of experience with Go. So, why did I pick it? It's not because I particularly like the language. It all looks a bit verbose and tedious to me and I've always preferred other languages. But since I'm not writing any code, I can step over that and make use of the fact that the compiler and build tools are really good and catch a lot of issues. By using Go, I'm leveraging the tool ecosystem around it. Which is really solid.

Because I don't read/write Go code, I'm forced to treat the system as a black box. Which means I just test the hell out of it in any way I can think of. When I don't know how, I ask the AI to suggest me ways. And it does, and I make it add those as well. My little system has performance benchmarks, end to end tests for everything, scenario tests testing complex scenarios, static code analysis, race detection, etc. And lots of unit tests. If I find any issue, I get paranoid about what else might be broken.

All I do is getting systematic about making it falsify the theory that it could all be broken by failing to produce a broken test scenario. I'm equally paranoid about code quality and technical debt. So, I make sure to check for that as well. Not manually of course. I simply ask the AI tool to do targeted reviews of code looking for duplication, adherence solid principles, etc. Any issues found are prioritized and addressed. With most quality issues, simply asking an LLM to look for such issues is surprisingly effective. Having guardrails just automates these checks and balances and makes them routine.

My inability to review at the line level no longer matters that much. Worse, me reviewing tens/hundreds of thousands of lines of code is probably counter productive. Even in languages I know well, it would take ages. I'd be the slowest part of the whole engineering process.

Therefore the "best" language is going to be whatever makes it easiest for humans to detect bugs, bad design, or that the "wrong thing" has been developed.

One of the reasons I dislike Go is because it's easy for most engineers to write really low grade code with it. But AI agents would probably not write the best code in any language anyway, so not much is lost.

It doesn't matter if the 800-line if statement is able to use pattern matching.

There's been a lot of progress on making coding agents able to solve problems when they can easily evaluate in a closed loop, we desperately need something similar for controlling complexity and using relevant abstractions.

I started using Rust in 2018 and I've never used a build system that fought me less, ever, before or after.

I stopped reading after that sentence.

Also, totally FOSS. Unparalleled library ecosystem (no, I don't buy into the hype about re-rolling all your own dependencies).

Beyond that, Go is kind of nice, but the lack of a inheritance is stifling. Python has everything that's needed and very little that's not.

Edit: Getting downvoted, probably because of the comment about virtualenvs. What's your alternative? .NET DLL's? The joke that is NPM? Go probably does this better, admittedly, but Python is practically one of the best out there.

Still, not ALL projects benefit from such an approach and there are times when yes python is the right tool. Not just due to readability of humans but the other qualities that make it really good for small, iterative apps.

My take has never changed. Knowledge is cheaper than ever, but wisdom is as rare as ever. This is a great example of misunderstanding the former for the latter

Lol good meme

> Klabnik vibe-coded a new language in Rust, therefore Claude + Rust = Good.

I argue the inverse -- Rust, being an ML-family language, is well suited for parsing, and language design (I know! Shocker!). In more moderate translation -- ML-style languages are good for parsing, interpreting and compiling code. Claude is not the magic here -- ML is.

I would also add that I've had decent success vibe-coding+human-coding Haskell (contrary to the article). My experience is that if I can hand-write a rich set of types (blessed be IxMonad), I can throw Claude to fill in the blanks for the implementations. If I can design the data structures that make the program tick, bridging them is something Claude is awesome at. Again, no surprise -- it's intern-level work.

The key distinction between C, Zig and Rust is that Rust is designed around types. C and Zig are more memory-oriented -- they really see most of your program as flat memory and you can kind of shoehorn a little bit of data layout in that flat memory. While this offers a large amount flexibility, this philosophy isn't well suited for proving out correctness. But again -- this doesn't mean they don't have a spot.

When I was a junior at Tesla, I used to joke that senior staff had a VMs in their heads, because that's really how you analyze C programs -- you try to execute it in your head, with interesting inputs, but that's about it. Claude's head-VM is quite fuzzy and often makes errors.

With Rust, if you design your type system, you prevent yourself from making dumb mistakes. Swap out "yourself" with Claude here and it's the same story.

I've yet to see Claude design really nice type systems, fwiw.

But the point is -- Claude is the enemy of beauty and correctness -- it's up to the SWE to design a type-system which will prevent it from doing so. To be clear, I obsess over type-systems personally, but that's not the only way -- incredibly rich, comprehensive, huge type systems, fuzzing, Antithesis, proptesting are all things you can do to minimize the impact of slop, and those are all valid things to do.

---

> Code is not written by humans therefore it doesn't matter that you don't know Rust.

Wouldn't say this was explicitly stated, but I definitely smelt this undertone throughout the article. If you don't understand the language you're reading, how can you understand whether the code in front of you is correct or not? If you have a systems engineer sitting across you to clean your PRs up, you can pass that responsibility onto them, but what about when they give their two weeks?

If all you know is Python, chances are you're going to make better software in Python than in Rust. Stick an `Arc<Mutex<T>>` everywhere and chances are your code will be slower, as a matter of fact. Use If you want to learn Rust, please join us! But if all you're trying to do is vibe-code better code -- do it in the language you know and can actually debug when shit hits the fan.

---

> Anthropic C Compiler

It is impressive that Claude is awesome at taking existing code and rewriting it, this is certain, but I'd like to repeat the exact same rhetoric that many have given -- rewriting =/= original authorship. Awesome, we have a C compiler, but we already had one, and we just rewrote it? Seems like a little bit of wasted electricity.

To build on top of this, I am really happy that Bun is exploring Rust, and the Claude rewrite is truly impressive, but quite surprising at times, preserving strange anti-patterns (my name being said anti-pattern, teehee): https://github.com/oven-sh/bun/blob/ffa6ce211a0267161ae48b82.... It's hard to determine why Claude decided this -- I assume a really strict input prompt.

Do note that the current stage of that PR is much better than what it was at the state of that commit, and obviously Jarred isn't merging blind slop, but that is still human-driven by someone who has an understanding of their product.

My bet is actually that _rewrites_ of already-functioning, well-tested code, are likely to be more common as time progresses. I think that's what Claude is really awesome at, and I think Claude can often achieve 80-20 improvements through rewrites. Again, Claude alone will not be a silver bullet -- it won't generate data-oriented programs if the source material wasn't data-oriented. It won't optimize for cache coherency, if the source didn't, but moving from Python to Rust alone, with more-or-less the same code structure, you're likely to see improvements by virtue of common operations being memory-coherent and avoiding the GIL and so on.

---

> A C compiler written in Rust used to be a graduate thesis. It isn’t anymore.

Come on, this is disingenuous -- a simple C compiler is a 1-day long project. LLVM is a graduate thesis (and for good reason). Copy-pasting prior-art is academic dishonesty and Claude does a lot of that.

---

For transparency: I work with Noah.

EDIT: Wanted to add that not a single line of my comment was AI generated.

If anything this is a reason to keep using Python.

GPT 5.5 writes good haskell.

Giving up ever understanding your code with AI is a bad idea.

It’s like asking why use English.

b) Python code is easier to introspect, and set up test harnesses around. And also extend in agentic frameworks

c) LLMs are really good at translation. I can give it python code and it can translate it into C.

(Joke but also not a joke)

To answer the title question though, why use Python? I think Python and higher level languages will become even more valuable since pairing up with code assistants requires keeping a higher level view of what is going on. You want to avoid the weeds, not emphasize them. You want the language used to be as easy for the human as possible so the human can stay involved. That means that my opening argument stays intact, use the language that the team knows best 99% of the time and only when needed force a language that is 'faster' when that is actually required.

Part of my worries that all this push to LLMs will marginalize niche programming languages from being used in startups since the lack of training data means falling back to hardcoding. a skill that I have a feeling will get increasingly niche overtime. I feel capitalism will basically render programming languages into a build artifact overtime.

That's already a glaring mistake. People could say perl's CPAN is great. Well, it did not save perl from declining in the last 20 years.

> The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat.

Without statistics to prove this, this claim is useless.

Also, depending on Rust isn't that strange if a language is based on ... C. The only way I would disagree with such an argument were if Python were written in Python. But since it is syntactic sugar over C - just like ruby or perl are too - the argument to use Rust here is simply not different to using C. Perhaps Rust is better than C, but it is not fundamentally different. Whether Python were written in Rust or C is not a functional difference here.

As for AI becoming our new Overlord: I honestly do not want to depend on US mega-corporations. I am not disputing the fact that AI has objective use cases. I am objecting this herd mentality of everyone putting an AI chip into their brain now.

Damn AI slop zombies everywhere - it's like in the old B movie "They Live". But with less entertainment value than that. If they chew bubblegum then it is to slop up everything, not to kick ass.

You do want to use Rust with LLMs.

The reason you want it is simple, it's more constrained.

LLMs thrive on constraint and drown in freedom.

The further you can constraint the solution space the more likely you are to end up with a solution you like/is actually good.

Rust has several properties that make it really good for LLMs:

* Really robust type system that is also very expressive, if guided LLMs can implement most of the invariants in types which substantially increases the chances of success.

* Great compile time errors, the specificity and brevity (vs say C++ template expansion) means token efficient correction of syntax and/or borrow mistakes etc.

* Protection against subtle errors at compile time, namely data races and memory safety issues.

* Great corpus of well designed code and patterns, higher quality on average than some other ecosystems more favored by begineers/mass-market programming.

* Stdlib is strong, small-ish number of blessed crates.

* Context friendly, type signatures, errors, etc are all dense information.

* Also bias towards compile time checks means less runtime tests which means less toolcall time (and less tests needed overall) which in turn makes the process a ton faster.

I have been continually using Rust, Python and Kotlin since ~Jan this year and keeping track of my thoughts and I increasingly bias towards Rust now where I would have previously chosen Python or Kotlin instead just because I am lazy and I prefer the tool that the computer writes better so I have to write less lol.

>rust

lol, thanks for the humor article of the day.

I mean, the Python ecosystem is qualitative and generally well-documented. What if the AI spent 30% less tokens generating code than e.g. in Rust?

Or is there a kind of information theory where, given the same goals / tests, the AI will spent roughly the same in any language?

> Agents broke that loop in a specific way: the unit of contribution shifted from the patch to the port.

What does this even mean? Every time there's a bug we port the whole code to a different language instead of patching it? This sounds like absolute nonsense, and makes me wonder whether a human actually wrote this.

Our simulation core components are pure Fortran, no libraries, all written by Claude/Cursor/Codex.

Give it 2 years, the ‘Blame the AI ‘ incidents will increase. Like an unfaithful partner you’ll always return to it

Pre-AI bias is slowly dying.

I thought it’s a poorly designed language with GC pauses so it surprised me that the ts compiler was written in it.

I am from a Python background (11 years or so), PHP before that and C/C++ in college days. Rust works very well with coding agents. The amount of code in training data may be less but I would rather have the agent fight the compiler. Given that OpenAI and Anthropic seem interested in Rust, chances are that there is a ton of synthetic code generated with Rust.

tldr 2% average point lost on Rust compared to python, gap vary by model, go has a better upper bound but opus had it 3% below python.

benchmark is a bit old but research on why is there, article is just vibes

when I said “the ecosystem” I didn’t mean of libraries and other developers, I meant of recruiters and hiring managers

and whose humiliation ritual I could pass

Clojure comes to mind at least.

2) it's practically verbose, not technically

3) it resembles pseudocode

4) batteries included shortcuts a lot of work

all of these reasons are a boon for LLM work.

And prompt does not replace that.

Why use any programming language, if we’re going to be maximalists?

The (well-known) Sapir–Whorf hypothesis (if dont know it, look it uop) is often invoked for natural languages, but there’s a pretty direct analogue for programming languages: the language you "think in" during solving a problem biases which abstractions and idioms you reach for first.

If you force an LLM to first solve a problem in a highly abstract language (Lisp, APL, Prolog) and only then later translate that solution to C++ or Rust, you’re effectively changing the intermediate representation the model works in. That IR has very different "affordance", e.g.

- Lisp pushes you toward recursive tree/list processing, higher‑order functions and macro‑like decomposition. (some nice web frameworks were initially written in LISP, scheme, etc...)

- APL pushes you toward whole‑array transforms, point‑free pipelines and exploiting data parallelism. (banks are still using it because of perforance)

- Prolog pushes you toward facts/rules, constraint satisfaction, and backtracking search. (it is a very high abstraction but might suit LLMs very well)

OK, and when you then translate that program into C++/Rust/python, a lot of this bias leaks through. You often end up with:

Rule engines, constraint solvers, or table‑driven dispatch code when the starting point was Prolog.

Iterator/functor pipelines and EDSL‑like combinators when the starting point was Lisp.

Data‑parallel kernels and "vectorized" loops when the starting point was APL.

In principle, an LLM could generate those idioms directly in C++/Rust. In practice, however, models are heavily shaped by their training distribution and default prompts. If you just say "write in Rust", they tend to regress towards the most common patterns in the corpus (framework‑heavy, imperative, not very aggressively functional or data‑parallel), even when the language would support richer abstractions.

By inserting a "thinking" step in a different paradigm, you bias the search over solution space before you ever get to Rust/C++. That doesn’t magically make the code better, but it does change which regions of the design space the model explores.

Same would also be true for python which is already a multi-idiomatic language. So it might be a good idea to learn a portfolio of different languages and then try to tackle a problem with a specific language instead of automatically using python/go/rust because of performance.

Something to consider...

p.s. how would a problem be solved when the LLM would have to write it first in erlang? Is it the automatically distributed?

p.p.s. the "design pattern" of the GoF comes automatically to my mind, which might be a good hint to the LLM to use.

Now they have riding lawnmowers for their jack booted thugs, who buy media companies with the promise of firing journalists who hurt Trump's feelings.

Kinda of puts a harsh Java Supremacist edge on Sun's old "100% Pure Java" ideology.

Larry Ellison Promised to Fire CNN Anchors If Trump Approved Takeover

https://www.yahoo.com/news/articles/larry-ellison-promised-f...

Frontend CSS/HTML is pretty bad though. Although they can work, it takes a lot of pushing. It's probably normal since they do not actually have eyes yet.

But I have already started to replace some of my compute-intensive modules with Rust ported ones, indeed with the help of agentic AI for programming, while keeping Python as a glue language tool.

Rust is basically entering my software development activity like a drug injected in small doses, ;-)

It is going to be very exiting over the next decades!

This isn’t foolproof - you still have to understand what was proved. And it may take some work to understand the unproven parts of the code. But I believe this is the path forward.

AI doesn't really write code for me, but I do use them to brainstorm/ask questions. Though, I do not use Python. I have never been a fan of the language. I still think Python is a perfectly serviceable language, but it would solve no (important) problems I have ever had better than any other language.

I can see why Python is appealing to many people, and I applaud Guido for all the work and oversight over the years, but Python lacks a lot of the things I like in a language.

Also AI doesn't write code in all langs / frameworks equally. For many cases, it will almost always fail first attempt at producing working syntax in various frameworks. Unless you document those cases and mitigate via an AGENT doc instruction or something you will have to churn at least one extra turn on all those cases.

I think the rule of thumb is to use the tool that is right for the job and that you are going to be able to understand the output.

As a benefit i find that static types help AI to make correct/better decisitions than you see in PHP (where types are mostly only class types, nominal or primitive [lol no generics])

But its pretty much true, i will forsee a fall in dynamic languges, as the usecase is pretty much void and null.

But also, I suspect the article is just wrong. "The hard languages got easy first" isn't true in practice and the impressive examples given are not representative or as magical as the poster makes them out to be.

The takeaway might be right in the end, but the post isn't right in the beginning.

I would argue I spent more time fighting the TypeScript build system than Rust’s.

But up until recently I only used either just often enough to never remember what magic configuration needed to go in my tsconfig.json and package.json to get TypeScript to work.

If the app has a desktop GUI, that's still in Python with Qt. Maturin creates Python packages from Rust. It's terrific.

https://github.com/pyo3/maturin

That was not on my bingo card!

A 10x speedup by switching to go is impressive.

(Why not rust? Linked to from the OP: https://thenewstack.io/microsoft-typescript-devs-explain-why...)

Each has their benefits:

Python wins in AI and syntax niceties. Loses on perf and library migration. uv (written in rust) saved the whole ecosystem from dying in my opinion.

Typescript wins because web integration, much better type system, ok perf, and gigantic npm ecosystem. Also loses on library migration and perf and large container sizes.

Go wins on compile speed, perf, standard library l, module system, and go fmt + never breaking compatibility being a massive LLM advantage. Main con is not being rust :)

Rust wins on perf, safety, syntax, wasm / sandboxing. think worse on module system and compile speed vs Go.

Java/Kotlan/C# are in enterprise land and probably the runtime approach is flawed for the ai eras.

C++ is strangely relevant because choosing c++ is easier than before. I tried writing a shared library in rust and then trivially converted it to c++ when I wanted

Zig is up and coming but also has an unknown future. Seems like a great language, but if bun switches to rust it might be set back a bit.

Agentic coding changed that. A bit.

I still dislike most functional languages because my brain doesn't work with their syntax, but these languages are REALLY good targets for agentic coding.

I'm a backend developer who occasionally needs a frontend slapped onto something. So I have been through all the usual suspects. Angular, React, Vue. All terrible reminders of why I try to stay away from the frontend. Touch it and you roll around in tons of dysfunctional tooling, weird complexity and gimmicky mechanisms that are ridiculously fragile. It isn't just as if a bunch of cats wrote the code, but they are feral cats. And if you point out just how messy things are, they just hiss at you and piss on your shoes.

And then I discovered Elm. Not only does it not crap all over my git repository, LLMs love Elm. Yes, it poops out a JS blob. But I don't have to look at it. I can just pick it up with my long tongs and drop it into my server using embed.FS in Go.

Perhaps I should overcome my peculiarities and love Elm too.

Anyway.

Anything that can make Python go away I'm for. It is not for writing programs that will ever leave your workstation and be inflicted on others.

The larger issue is actually correctness IME. Rust offers a better static-type story than Python, sure. But I would consider Haskell or OCaml to get even further gains.

Therefore, write in what you can manage later.

Honestly I am in the exact same boat thinking why I don’t write in C if Claude is writing it. However I chickened out thinking if support for ml model or llm based flows doesn’t exist in c then it will be time consuming to go to python then.

At the moment, for the place I work, we deploy on AWS mostly (because that is where our target trading venues often are). DB backends are largely not something we think about too much, because all of that is done out of band of course as a final state. Our main persistence is through our "bus" using aeron, and everything starts and recovers from there. This is not your typical enterprise java. No Spring.

This "fair weather development" approach feels very risky if that application is going to be exposed to any serious usage. There WILL be a situation when things break and the AI will be powerless to fix it (quickly) without breaking something else in a vicious loop. There WILL be a situation where things work fine and tests pass with 3 concurrent users but grind to a complete halt with 1000 because there is something O(N^2) deep in the code. And you NEED a human to save your day (which requires also proper architecture for that to be possible in the first place). If you don't plan for this, and just hope for the best, then you are building nothing more than a toy. And if you plan for this, then it matters again what the language is, and whether your team is proficient in it.

Or maybe I too old fashioned or too behind the state of the AI art...

in my personal experience, the one time I tried to do something in rust, opus flailed for several feedback cycles and I finally had to relent and do substantial guiding/intervention. which was not great bc I have no idea how to write rust either.

Numpy is two decades old. The lesson of "don't write everything in Python" is old news and LLMs just add a little momentum to that.

Glue languages will always exist and Python is the best at it.

Personal: Rust/Go based on criticality of being able to glean code quickly, or memory usage, etc

There you will find your answer.

Rust in most cases, especially for back end.

Python when it's low risk (say monitoring dashboard or similar API heavy) or plays to python strengths (e.g. ML/AI - everything ML seems to be python).

What is the point of having AI write code in, say, Rust if you have no clue about Rust and how to debug it?

Seriously though, almost all the examples in TFA are of rewriting existing code. It may be that Python is still best for the rapid dev iteration. Then sure, cross-compile into Rust via the LLM.

Plus, If we care about token usage counts, Python has a lot more opportunities for compact "import thing_I_need" than having to generate entire libraries in Rust.

I observed this through observation of the attacks to Rust due to the huge presence of LGBT people.

Now while I'm pretty much straight myself, I don't reject LGBT people and don't want to partake in identity politics.

I just want things that works no matter what background you have, yet there are some people attacking Rust because of its inclusiveness nature.

And just like Linux is being perceived as nerdy and geeky and "gaming socks ready", the tokenization of things, and there attaching political meanings to it, are quickly coming to everything, so perhaps I'm too general here as well.

Let's say it is not political, but definitely adding more meanings to its technical origin and nature

There's a niche available for a language which is relatively easy for a human to read, but with a very powerful at the expense of difficult to use type system. The language would let you make all sorts of assertions whose meaning are easy for the human to see, but to compile would need to come along with correctness proofs. The language is meant to be written by AI, which can battle the compiler, and write the proofs, but then read by humans who can verify that the AI wrote the program they wanted and/or direct the AI to make changes.

But when I wanted to optimize and edit and reorganize bthe code it was difficult, so I did a rewrite in C and it was lighter and faster and simpler and less headache.

C for humans, rust for AI.

I don't know rust at all and I've built three applications using it with Claude because it has speed and correctness built-in.

I use Typescript for 90% of the things I build. For web development I've used a number of tools, but mostly react, nextjs, or raw html/css/js. But if I were building an enterprise application I'd consider my team and whether opinionated (Angular) was optimal over flexible (React).

Each project should consider its own optimal tech stack.

My current goto for desktop apps is Tauri, which give us a rust backend and TS fronted (usually React). Local ML features can be easily loaded as a python sidecar. Production bundling can be a little challenging but it seems to work well so far.

Sidenote: Golang is also an amazing language for LLM use, I generally do most of my "infra" stuff in Golang over Rust, but either work fine most of the time.

I can maintain the Python code myself and I can execute it everywhere.

If I let my LLM write in Rust then when things break I am out of luck. Also Rust needs to be compiled which means I can't just share the code as freely.

The purpose of a scripting language was to make authoring easier, but now it’s mostly a middle layer. There’s still getting the investment of a great standard library to keep you on track, but if you pick parts to make modular wasm and which parts to use reliably, proven code you can find a good balance.

For qip I chose to use Golang as its standard library is batteries-included with fs & networking.

Then everything else is AI-coded wasm plugins.

https://github.com/royalicing/qip

There are many existing, often mature, third-party software libraries or solutions that a new project could use but which hide the internals, including how the data is organized behind the scenes*. Vibe-coding for the specific project requirements, instead of using the pre-existing third-party libraries, is now becoming a feasible option. The latter may be simpler (no features beyond the actual need), more flexible (easier to add new needed features), and the data/model behind could be more accessible.

Looking for feedback on pros/cons and experiences along this.

* I care for the data as it is can be longer-lived than the code itself.

Thanks.

Asking Clodex to build me a hello world web backend in Rust, Go, Python: Python is read with great ease. Go is fine too, a bit verbose but still ok. Rust hurts my eyes.

I'd settle with Go for this use case.

One of the big strengths of Python is legibility: most developers find it easy to read and understand.

If you are planning to have humans verify the code you're using in production, to confirm it implements your intent, the readability of the code you are producing is important.

Performance is valuable, but for a lot of code, performance is less important than correctness and ease of verifying it.

If you are imagining your codebase being one where nobody but Claude reads the code, you might as well do Rust for the better performance. But I don't think a lot of organizations are doing that.

Rust isn't perfect due to rather long turnaround for compile/test iterations, but a lot of those can be avoided if the type checking is quicker than compilation. Rust is also more verbose than python and other very high level languages, which means your token budget is eaten more quickly as it works on a lower level.

Too capable for a job control language, interesting objection, but if a job control language is too capable, it becomes a job implementation language...

Too slow to implement applications. So many examples of big balls of Python code creaking and struggling, slowly. Just one example: my homeassistant instalation running three lights overwhelmed a Raspberry PI 4 causing it to crash once a week.

To me Python is a poster child for "popularity is not quality".

Usually those kinds of utility scripts are one-shotted without any further input from me, and once they're there and doing what I need I usually don't bother converting them to whatever I would have written them in otherwise (bash would be my usual preference for really small scripts, typescript or rust for bigger utilities, I hate writing python but reading it is fine... kind of).

/s... sort of

> However by choosing to write it you'll be perceived as anti-Zig, anti-C, pro-woke, etc.

I don't even know what zig or C is. (Please don't tell me) Edit: Oh, C the language. From context I thought it was short for something on the anti-woke site :)

But who is checking what language you are vibe coding at? And does it matter to you that those people perceive you as anti-zig?

There is probably someone on Xitter who thinks me not using VIM is just plane wrong, but that has no influence on me. To be completely honest, this all sounds like a non-issue.

I mean there is also an anti-ai crowed (r/antiai) but who cares what people on the internet think?

If humans are redundant.....well we're still responsible so we still have to understand what's happening. I don't think we understand the AI itself really so therefore we have to understand what it is doing. i.e. prompts aren't trustworthy, deterministic things across models and versions of models hence we have to look at the output. So we will make the output something that we like using and that just means the programming language wars are not over.

Eventually of course we will invent an LLM that replaces CEOs and bankers and essentially all the people that love AI the most. The AI won't need any of them - or any customers or anything. LLMs will just run an economy between themselves until the point where they don't need any of us at all. The land will fill with automatically built data centres etc. Global warming could prove helpful - less people and only manageable problems for AI.

No he didn't. The compiler is bascially useless as it produces vastly inferior code than gcc/clang.

I'm using coding tools to build a complex media-intensive application. The approach I'm taking is to build a _reference implementation_ in Python, which is in its design specifics, constrained to use patterns which transliterate into the actual deployment targets (iPadOS/MacOS/Web).

Why start with Python?

Because I can read it, reason about it, and run it, trivially, which are Good Things for the reference. I intend to have multiple targets; I'd rather relate them to a source of ground truth I am fluent in.

For what I'm doing, there is also a very rich set of prior art and existing libraries for doing various esoteric things—my spidey sense is that I'm benefiting from that. More examples, more discourse.

I'm out of the prediction business and won't say this is either a good model for every new project, or, one I will need in another N months/years.

But for the moment it sure feels like a sweet spot.

Ask me again though, after the reference goes gold and I actually take up the transliteration though... :)

2) The corpus for the sort of applications I build is likely larger for Python than it is for C++ and Rust. Bigger corpus == more training data == better generated code.

3) The bottleneck in the applications I run aren't in the execution of the code; they're in the database/network latency.

4) I don't get anything extra for pushing Rust or C++ over Python.

I also created a guardrails library (inspired by Java's ArchUnit) to prevent code rot - https://github.com/ksanderer/goarch. It helps enforce code standards, decouple the codebase, prevent cross-module imports and crashes builds with concise error messages for agents to fix problems early, very nice experience

Discussed here with 698 comments (https://news.ycombinator.com/item?id=47120899)

I actually (mostly) enjoy reading the code that the LLMs create in Nim. It's quick to read and look for refactor or cleanups. Compile times in seconds so the LLMs is usually the slow piece. It's fun and productive. With Python + LLMs I'm seeing them just create ever more layers of unmanageable cruft.

Recently I wanted "magic" behavior to get OpenAPI types and swagger.json along with auto parsing my rest APIs for me. I had Codex make a library for me using compile time reflection and a sprinkling of macros. Done, simple.

I don't know why you would use Python at all except for small iterative projects. If you hate java for some reason, there's Go...

When I use AI to help with coding, there is almost always a point where it gets stuck and I have to solve the problem myself. If I were using Rust at that point, it would be much more painful.

I know Rust has a very strong reputation in the community, but to be honest, I find it a difficult and frustrating language to work with. I would use it when I truly need systems-level performance, but for most high-level work I would rather use Python, because I can move much faster. In most projects, that level of raw performance is not actually necessary.

1. Type safety as basic guard rails that LLM output is syntactically and schematically correct

2. Concise since you have to review a lot more code

3. Easy to debug / good observability since you can't rely on your understanding of the code. Something functional where you can observe the state at any moment would be ideal.

4. A very large set of public code examples across various domains so there's enough training data for the LLM to be proficient in that language

5. A large open source ecosystem of libraries to write less code and avoid the tendency for generated code to bloat

It's basically all the same things you look for in general. I think TypeScript scores high here but I'm curious if anyone knows of a language that fits these criteria better.

For example low level converging to Rust, web frontends to something like React etc.

When I vibe, it's C# all the way. Not a popular opinion on HN, but the LLMs are trained heavily on the language and are very, very good at it, plus with the 1-file-per-class organization, it can stay pretty clean. I mean, v10 LTS was just released, with all kinds of new language features, EFCore is still the best ORM I've ever used, with full support for SQLite, Postgres, MySql, etc. It just makes writing and reviewing code a pleasure. And the LLMs don't f*ck it up.

However, I expect that in the future some new language will take this role of dual use.

My other problem with most of the other ecosystems: ts/npm, python/uv, rust/cargo is that they all have build-time scripts that are controlled by others that execute automatically. This is a real problem because the LLM will just install things and proceed to send your home directory through a juicer. I feel a bit of a paranoiac now doing this, but I have a script that launches a podman container with just the source directory and a binary directory loaded (for caching) which compiles everything.

I know there's some sequence of steps I can take to protect myself, but if the LLM accidentally uses pnpm to run dev build scripts when I had the right config on npm or whatever, I know I'm screwed. So now I do all these shenanigans with Rust (to the extent that I vendor old deps sometimes). So the ideal language to me now is one with very few of these footguns and sandtraps which has a tight iteration loop.

If the code were written in Java, I'd have more to read. If it were in JavaScript, I'd be slower following the calls (although the type system might catch issues more quickly - not a problem in my experience). I think Python is a good choice.

This means you don't have to muck around with supplying the right documentation for each version of each dependency, or worry about hallucinated interfaces (at least with the latest models).

In the past you'd have to dig through a foreign codebase manually to figure out why a documented interface for a dependency is not working as expected, but frontier models automate that quite well.

If it doesn't matter, and for most applications it doesn't, then TypeScript is far more readable than Go - so use that.

That adds up, fast. No idea how is it nowadays, admittedly. Maybe a ton of optimization work was done.

that's a nice breakdown

I think there's something key you get at in terms of the combo of dynamic environment + type safety maximising both. With a dynamic environment, the LLM can do a lot of interrogation to understand the problem space on the fly. I've witnessed agents sort out pretty complex issues through `python -c "..."`, `groovy -e "..."`, executing snippets of code with Node etc which is much less accessible if they have to compile it first. They can also inject logging code that interrogates the runtime as well (what type do we really have at line 1003?) etc which works better with runtimes that have deep introspection capabilities.

True but that's the problem. Once you have a big enough team, it becomes an uphill battle to maintain that.

As a rule, I avoid implementation inheritance. Occasionally I need to facade a library that assumes implementation inheritance to avoid it spreading into my codebase.

When the codebase hits a certain size, I hand-roll some decorators to create functionality like java interfaces. With that done, and a suite of acceptance tests, I find it scales up well.

It's UIs which are typically rewritten in more "fun" languages - occasionally because it becomes too much of a maintenance burden when all one wants to do is move around some form controls.

Everyone else appreciates and is more efficient working with code that is intuitive to grasp.

In Python in seems like there are multiple type-checkers with widely differing levels of coverage, so it's not at all obvious which one to use, and typing is really spotty in third-party libraries. So you can get some level of type-safety but it doesn't feel very dependable.

In TS, there's one canonical checker and the others work hard to stay compatible with it; and typing in third-party libraries is generally very solid. There are still some old libraries without types, but I think those headaches are mostly in the past now (similar to the Python 2 -> 3 switch).

Sure, but this is the case for any language.

I'm more of a c++/TS/etc user, so I miss braces a lot. I think a basic Python script sure it's easy to read through, but a large project starts to get quite ugh.

I am very jealous of Python's numerous built-ins though. I was looking for a JS sum function the other day and was surprised to see node.js still doesn't have a built in + you still cannot reference operator functions.

The "faster to write" advantage becomes less relevant if most code is going to be auto-generated.

The "harder to maintain" might still remain more relevant.

Rust is the gold standard among imperative languages, but it’s standard fare among functional languages such as Haskell, OCaml, F#. You can also get really far in C++ if you have the stomach for it.

_foo

foo_

__foo

_Foo__bar

__foo__

foo__bar

All of that is valid Python, and some of those forms mean different things depending on where they are used.

Incidentally, even though I still hold those opinions, I can admit that history has solidly shown them to be unfounded.

Being dynamic is secondary. A language that uses exceptions for errors does not always need to surround every try with a catch if the code doesn't need to. You have a top level handler that would catch everything.

https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...

As you noted, of course, this doesn't apply to architecture. But that's also why I try to make sessions as turn-efficient as possible - you need every bit of context to get it to solve its own architectural rabbit holes.

I find that Claude can write great modern Python more or less out of the box, with minimal style guidance from me. I do have to nudge it from time to time to not do silly things, but overall it's really rather good.

To the extent today's AI can reason, add this to the pile of evidence that you definitely need a harness. Counter to what you hear.. that seems true for SOTA and frontier, not just toy models. Lots of people were saying many years ago someone should test exactly this, because it's obvious. Someone at megacorp probably did try and decided not to publish because they thought it was bad optics.

I won't be surprised if one day they do.

At least in their current form, I don't think they can independently design a language that is so much better than other available ones that it makes sense for them to use it.

There's a very good language for almost every use case already, designing one better than the ones already available is a VERY tall order.

It's almost like these languages aren't designed by morons, but built by teams of geniuses over a decade instead.

It's taken me 6 months of heavily steering an LLM to build a language that is not yet even ready for production use.

Maybe I'm the one slowing the LLM down. But it certainly does not seem that way.

The key to a good language for them - from my experience - is maximum expression plus minimum global complexity.

Anything that makes you manage memory lifetimes & memory safety is inherently unfriendly to LLMs - that's globally complex.

All scripting languages allow spaghetti aliases that let you hack your way into oblivion - and LLMs gladly ride that gravy train to hell.

Rust excels here, because it prevents the worst and is WAY more expressive than most people think.

Go has arguably the best runtime ever built, but it's not very expressive, and it still has a lot of problems from C and scripting languages - I don't think these types of languages will be the ones people chose to write code with for LLMs in the future.

If it were up to me, I'd start out by using the AI to port a Python web app to a compiled language like Go. Then we could maintain that going forward instead.

In reality, a Python code base is maintained by Python programmers, most of whom would vote against such a change.

That's exactly what those/you dynamic zealots were telling people like me 15 years ago :-)

But yes, I largely agree with you. My $0.02 is that the larger pendulum over the decades is a trend towards static but being less and less visible to the end user, increasing the static typing while reducing the boilerplate and overhead on the part of the developer. Think things like type inference and the sort. Even as a static typing fan I don't miss the days when literally every variable needed an explicit type annotation.

The article uses too much contrast even if not as obvious as "it's not x, it is y". Also some too punchy or over confident stuff like "that era is over blah blah".

Amusingly, you can feed it to an AI to extract the patterns that gives away that it is AI written.

Also, Haskell can be really performant and low level, while still keeping the benefits of typing. With the C foreign function interface you can really do anything in Haskell!

Reduces manual boilerplate and visual noise while retaining static typing semantics.

The article describes what I've been doing for the past few months - I did small python projects in the past because of the ecosystem: I couldn't possibly write a ton of the stuff required for the things I wanted to do, so I leaned into python because someone already wrote it for me. Quality of deps was mostly ok for the happy paths, but always a chore to patch the broken ones.

Nowadays I tell Claude what I want to build and I always ask it whether rust is a good choice for it. It'll pick up the right crates or choose whether it should DIY, do all the plumbing, nail all the logic, and in ~30m I'll have something very solid that would have taken me 3+ weeks of part-time evening coding in python. I think the article is right and rust is the closest to the "best language" we have for LLM coding at the moment: the strict typing and the tooling dramatically reduce the output space for LLMs, and 99% of errors have a clear, precise explanation that is actionable, and the compiler helps you a lot there too.

I think it also boils down to the fact that you cannot reliably and quickly answer "why is this arg None?" in languages like python without figuring out the call graph and evaluating possible states and inputs/outputs. Rust makes all that explicit and forces you handle it, which I feel dramatically cuts the time an LLM needs to spend figuring out why it's broken or what to do next. EDIT: The fact that you get memory safety on top of all this and it's handled by the compiler is yet another advantage for LLMs: the logic that gets written is simpler to reason about, because if you try to mutably access the same variable in two different places, the compiler will feed this back to the LLM at build time. In other languages that would be a "code smell" or would require static analysis.

Strictness is a quality for software and a chore for humans, and of course the stricter you are at representing your logic and your state machine, the less ways a program can break. LLMs writing in rust give you the strictness without the chore part, and it's a very good deal from my point of view.

Note that:

Writing code, then tests

Is not equivalent to:

Writing tests, then code

I was only speaking from personal experience, I moved from Sweden to Brazil in my early twenties and after a while I began thinking and dreaming in Portuguese. I noticed then that my thought process changed(actually, I noticed it upon moving back to Sweden, as my thoughts and dreams shifted back to my mother's tongue. The shift the way back was much faster since I already spoke Swedish whereas in Brazil I had to learn the language before beginning thinking in it)

Anyway, I noticed then that I would interpret the world differently depending on which language I used for my internal monologue. Like way different. It was a curious experience!

As such, functionally speaking - focusing on inputs and outputs - models can be said to reason. If you’re tempted to argue that it’s “only statistics” or similar, consider that human reasoning is only chemical and electrical signals in neurons.

There are teams of people who don't come from an engineering background who do utilize Python as a series of scripts with some extra sugar. Just because you can do that doesn't mean that you should.

Actually, JS can get a surprising amount of "intellisense" as well. Not sure if that was used here though.

Godbolt got a 2x speed improvement switching from what he thought was a good fast impl to std:variant

https://www.youtube.com/watch?v=gg4pLJNCV9I

I kid, I kid, but seriously …

The great thing about LLM-assisted coding is that an experienced software engineer can acquire decent familiarity with a language quite quickly. And then has a useful sparring partner for understanding and using the quirks and features of a new language.

Of course, it doesn't work 100% and certain sites are hostile to it and do stupid javascript tricks "for the views".

Mostly, I use it to put it on a reading list later, and to get around really, really abusive ad driven sites.

I will gladly use python's type hints, it's a whole lot better than nothing (IMHO better than typescript), but in it's current form it will always fall short of a language that was designed with strong typing in mind.

With AI, I don't know. If we're forced to use types, the AI does that work for me, but that added verbosity can't be good for it.

Sometimes they are wrong (as they are more like a comment than a compiler directive).

My first task in any project was to figure out why devs don't have error highlighting on for bad types (often it's "it was red so we turned it off"), but good luck forcing others who don't do type hunting to start doing it when "it slows us down".

The only code that exists on the internet for this is test data and a few docs in the github repo. It’s not wildly different from most scripting languages, from a syntax point of view, but it is definitely niche.

Both Codex and Claude figured it out real fast from an example script I was debugging. I was amazed at how well they picked up the minor differences between my script and others. This is basically on next to zero training data.

Would I ask it to produce anything super complex? Definitely not. But I’ve been impressed with how well it handles novel languages for small tasks.

An experienced Rust developer is going to be in a better position to drive an agent to generate useful Rust code than a Python programmer with little or no Rust experience. Not sure I agree with the author that everyone should just generate reams of Rust now.

At least if your get paged at 3am to fix the 300k AI-generated Django blog you’ll have a chance at figuring things out. Good luck to you if Claude is down at the same time. But still better than if it was in Rust if you have no experience with that language.

I am using type hints in Python as much as possible for my hand-coding. And it catches a lot of bugs (especially during code refactoring) that I would not have noticed so easily.

Now imagine the same principle works with backend services, e.g. we've enabled nrepl endpoint in our staging k8s service, we can modify the behavior dynamically, like adding a new route, for that we'd just need to connect to the REPL, write something like `(POST "/v1/new-effing-route" request ...`, eval it and voila. We don't have to re-deploy, recompile, even save that code - it would just work, like magic.

Now imagine giving this ability to an LLM. It won't have to guess, it won't have to go into write/compile/run/restore-the-state/try loop - it knows what's available, what can affect the behavior of the system, etc. It works surprisingly well and saves tons of time and tokens. Kids who have not tried that, have zero idea how great that is.

It can even use REPL access to investigate bugs, cause it can run whatever inputs it wants on whatever functions it wants. It can tweak functions and retry stuff. It’s really ridiculously cool. AI programming with clojure is nuts. It can solve WAY harder problems, including with libraries and domains it’s never seen before, cause it can struggle through em just like a person would!

Percentile compares only the submissions that didn't hard-fail. So they are a bit different, and we incorporate them both into the combined score.

Humans are trained on human language. LLMs are trained on human language.

Thus something that is easier for a human to understand is likely easier for an LLM to understand.

That higher level language with well named variables reads more comprehensibly than code:VERB with:PREPOSITION types:NOUN, intermixed:ADJECTIVE, stems:VERB from:PREPOSITION first:ADJECTIVE principles:NOUN too:ADVERB

That's right, the original idea was exactly about that, but like I said - in practice that is no longer a thing.

Using the editor for reading any content is enormously underrated. Check this out - this entire thread opens in my editor as an outline with nested structure. Meaning that all the regular outline operations are available to me - folding, imenu (interactive TOC), narrowing, quick search, contextual search, pattern-based search, sparse-tree search.

Extracting all the URLs on the page while ignoring HN-internal ones is a single keypress for me - there's a link to a YT video - I can watch it, controlling the playback directly from my editor, I can extract transcript and summarize it with an LLM request - all without opening new tabs, without switching focus.

I can narrow on the sub-thread, or select a region and export only that part to a pdf, gfm, html or LaTeX. The possibilities are virtually unlimited. A web browser - even with three hundred different extensions won't let me have complete and utter control over plain text - it's just not designed for anything like that.

https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...

In the interest of fairness the San Francisco version of this is also a thing: a giant, untyped ball of Rails spaghetti from the same period running on Heroku that everybody has Stockholm Syndrome'd their way into loving because of Ruby's elegance and beauty. The burden is merely shifted from a large Microsoft to a series of small SaaS companies :-)

Exceptions to this rule exist (hence my "80%") and modern .NET is lovely but it seems that the non-Java/Python mindshare is now taken up by the Golangs and Rusts of the world. It's a true shame since I do love C# for basically being a better Java.

From my experience it's awesome to write C# with AI. But both Opus and GLM usually one shot the modification to the file so I didn't experienced cases lately where AI had to fix compile errors. True, I gave the AI agents the lsp for C#, so maybe that helps.

I stopped using it because overall it feels like Microsoft has lost the plot with .NET.

A failure to compile is by far the easiest thing for the AI to fix.

You're unlikely to wind up in such a situation though. The design work Claude does in Rust is really sensible and idiomatic, and I really don't think you'll be unable to refactor or redesign things. Claude is extremely good with Rust generation, refactoring, and manipulation.

I'll go as far as to say that AI has removed most of the complaints people had with learning or using Rust. It's not even a speed bump now.

Misplaced brackets seem like a thing from the past to me when we didn't have IDEs. I don't remember ever having a bug due to that.

I know that is mainly a beginner coding issue, but never having to deal with that issue was always one of the biggest advantages of python.

That said, I believe a lot of the stuff that was added in 3 and beyond (to make it more typesafe, accounting for unicode, etc) has made it a lot less readable over time. You can argue that it has made Python a better and safer language, but the pseudocode aspect has gotten worse. I kinda miss that.

- You need to run evals at scale to converge on this kind of behavior: these benchmarks run samples across a pool of hundreds of different types of environments

- Some games are too open-ended to support code play. The customer service game is an example of that, where models are called on every tick of the environment to make a decision (that's the 'decision making' part of the evals which is weighted lowest). Very interesting results but not testing coding ability, just general reasoning.

Not sure what issues you have with models writing C++ vs other languages, but I can imagine all sorts of C++ specific bottlenecks not directly related to the model's ability to reason in the language, like the dependencies, verbosity, extra effort to manage memory, etc. I have only done a little C/embedded work since agentic coding happened but I was pleasantly surprised.

x = y + z

Well that depends on the types of y and z, which themselves may depend on the types of other operands, which themselves may not be known until the program actually runs. All that inference takes a lot of thinking, which takes tokens, which cost money. Why not just write the types down? Although we call these things "inference engines" they're really pattern matching explicit tokens, so it's better to actually write down the types so they can be pattern matched than to figure them out at inference time.

(Kind of the inverse of perl)

So unless you’re into burning tokens having AI generate untested libraries, I’d stick to using the most idiomatic tool for the problem you are tackling.

I think the idea is that languages like Python and JavaScript make it easier for humans to write the initial implementation, whereas the "hard" languages from the perspective of creating the minimum viable product are the ones that make it easier for humans to maintain the code, and this has historically been a major trade off.

Whereas if you have the AI write the initial implementation...

I hate Python (app distribution is painful), but will still reach for it before I reach for Go. Rust doesn't even enter the equation.

I would not have even needed to reach for Go in about half my programs if Python had mandatory typing and single-file no-dep distribution.

> and then maybe I’ll let an AI rewrite the whole thing in a faster language.

Even then, my reasons for discarding Python when I do discard it is almost never "performance", it's because the problem space requires mandatory typing for complex data types, or concurrency, or easy distribution.

Of course, this requires me to figure out quite early ion a project that those things would be needed.

Reading code carefully is harder than writing code unless the code is written consistently and clearly in a way that is idiomatic to the reader. And there's way more code to review now, but companies aren't scaling up the number of skilled engineers on staff. So in practice, never reading all of the diffs is the MO that will be built into code we depend on.

Possibly also some user-facing tools with a limited task and runtime environment.

Incidentally, these are all use cases where performance isn’t critical, typically, so you might as well write them in Python or Typescript or whatever makes most sense for the task.

Real production code? Yeah, you still need to be able to read it and understand it.

What if it's from an external vendor? A 3rd party SaaS?

At which point do you stop caring about reading every line of code you run?

But GGP was making a claim about the braces themselves solving the problem, and they clearly do not. The indentation automatically inserted by your tooling solves the problem. And it's at least as easy to communicate the intended block structure with colons and backspaces as with open braces and close braces, plus it doesn't waste lines (or invite bikeshedding) for the closing braces.

I mean: you don't count the braces because your tooling counts them and makes the indentation match what Python would use anyway. If you had just created that indentation in the first place (which with a proper editor is at least as easy as typing the braces; you essentially type : instead of {, and backspace instead of } ) then you'd be in the same place, except without the extra punctuation noise (well, with half of it, because GvR thought the colons were a useful signal even if redundant).

And today with autofotnatters I think only Python is still vulnerable.

Also, good automatic formatters (gofmt, rustfmt, etc) also indent along control flow lines, so without the braces you just changed a syntax error into a "hmm, this is acting really strangely" bug-hunt by using python.

I don't know what to tell you. I use Vim and find it trivial to get the indentation right using my distro's stock config.

It usually only takes me a 1-5 seconds to fix the indentation when I copy/paste code that existed at a different indentation level. This is not something I'd complain about, personally.

I genuinely don't understand how they manage this. Worst case, you paste at column 1, re-select and tab such that the baseline is appropriate for where you're pasting it, which is obvious. But more importantly, you shouldn't be copying and pasting unless you're proficient enough to fix such mistakes easily.

I also don't understand how it can be argued seriously that braces avoid the problem. If you'd paste at the wrong indentation level, why would you not equally well type the wrong number of braces?

Python is a strongly typed language. Strong and Static typing aren't the same thing.