Go might have the advantage because it's easier to read outside the IDE
But then you have the major downside of 'writing' poor code.
Rust has a huge advantage here, in fact many popular Python libraries use Rust underneath.
Now if .NET was still not so embedded in the Windows ecosystem that would be very interesting to me to jump from TS. As it is I am learning Go instead.
Python is easier to interface with C/C++ libs.
This was why I was excited by Bun until recent events. A typescript runtime with a rich standard library, and fast. It looked like it would be a great sweet spot for many use cases.
Python is a general development language that can be used to build servers and web pages, but does a lot more besides.
They're not really comparable.
Having said that - I wouldn't be surprised if Python drifts towards stronger typing, although it will probably remain optional.
* Most applications run on the web nowadays. With TypeScript, you can write both the front end and the back end. * TypeScript shares many syntactic-sugar ideas with Python, but it is also statically typed. Whether that is good or bad is a hot topic, but it gives you a lot of confidence through compile-time checks. * Running Node for system tasks is as easy as running the Python interpreter. However, Python is still slightly ahead there.
I'm OK with Lisp output, but maybe that just shows how old I am. :-)
I wonder if it's possible (or wise) to have two different compilers for a language -- one that's optimized for such tight loops, and another that does thorough checking, etc. You know, kind of like -O, but at a much deeper level.
The compiler is indeed not particularly speedy, but the reason you were given is not entirely accurate. As measured in this blog post [0] different parts of the compilation pipeline will take different amounts of time depending on what you're doing (cargo check vs. incremental build vs. full build, building a library vs. binary, etc.), but generally speaking type/borrow checking take up relatively small portions of compilation time (~15% or less, based on eyeballing the charts [1, 2]) compared to everything else.
> one that's optimized for such tight loops, and another that does thorough checking
I think that would risk producing diverging language subsets, especially if the checks are essential for language semantics. For example, what exactly does it mean if a program passes the "relaxed" compiler but fails the "thorough" one? How close does that actually get you to a "real" working program?
[0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...
[1]: https://kobzol.github.io/assets/posts/compile-sections/binar...
[2]: https://kobzol.github.io/assets/posts/compile-sections/libra...
Anyway, I've played around with the idea a bit so far, and it seems that current agents/harnesses use way more tokens with that architecture.
I think "batteries included" is not a good thing to have in the future.
We'll want to be very explicit about what AI generated code can and can not do.
And so some form of effects based scripting language seems like a plausible choice: A language where by default "all batteries are removed".
More than one reply to my original comment is along the lines of "but humans cannot read/understand machine code effectively". Perhaps instead of starting my comment with "If we're not writing code by hand anymore anyway", I should have said "writing or reading", but it was implied.
Pinyin is a system for writing Mandarin Chinese sounds using the Latin alphabet. Pinyin is commonly used for learning Chinese pronunciation and for typing Chinese characters.
The article did explain, albeit near the end.
That's because Chinese characters are sred by all of the dialects of Chinese while Pinyin is based on the Mandarin pronunciation.
I do not think subpar means what you think. Or maybe you rewrote the sentence and forgot to change that word? Anyway, this does not make sense.
So that it's easy for humans to review it. Same reason as ever. Obviously Python isn't always the correct choice, but the overlap with cases where vibe coding is the correct choice is pretty high.
Also wtf is Pinyin?
From the article:
> Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
Can't say I've tried Rust, but my AI tooling has always been noticeably worse at doing comparable tasks in C++ instead of Python. Not just toy examples but real systems in prod with testing, maintenance, oncall, feature rollouts, etc.
> Can't say I've tried Rust
...
Well, I've actually tried both. The result is similar to what happens when humans code: for small programs the simplicity and terseness of Python helps, but in large programs that accumulate many more invariants that have to be upheld, strictness of Rust becomes an advantage, because it can catch subtler issues with ownership, lifetimes, thread safety.
Although ownership and lifetimes seem like a Rust-specific chore, they're used in APIs to represent all kinds of temporary and single-use objects, so ownership errors are often symptoms of logic bugs that would exist in C++ and even Python, like an event handler callback assuming the event will fire only once when it can fire n times.
You don't see as much improvement with C++, because C++ requires the programmer to get these things correctly, instead of correcting the programmer.
> '''Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.”'''
My understanding is that children in China learn many characters before pinyin. Characters are mapped to meanings first, and only later to sounds. Fwiw even in my Chinese-as-a-second-language course we were thrown into Chinese characters from the beginning.
Also, of course, Chinese characters have been around for thousands of years and sound-based writing for Chinese is very new. The techniques to get leverage and build up understanding of characters gradually are incredibly varied. Just as the ways we relate to code in the future are unlikely to be familiar or easy to predict.
Some against their will.
> In a world where all coding is agentic, and where we are asking the agents to produce Rust, we might ask a deep and more disturbing question: Why learn Python at all? What’s the point of learning a programming language that an increasingly small group of people will be writing and using?
All the same structure everywhere.
- Now with the AI
- (Not the future; the present)
- Everything is changing
- But colon points to potential problem:
You’re worried about the future of Python. But not programming?
Be a part of the problem or the solution. But no, the author will say, one can’t stop a tsunami.
> Python has a future. But in a world of agentic coding, it might be increasingly for teaching the basics of software engineering and providing AI with high-quality training data, rather than for direct coding of applications. It’s still worth learning and knowing Python — but it’s also worth doubling down on basic software-engineering principles, which we’ll increasingly be using to instruct and judge AI agents.
Remember to mention AI Era, Agentic Era, or some other statement that is on the one hand completely obvious in the author’s mind but bears repeating like a mantra.
Yeah Python will be used to teach arithmetic before we spend the rest of our lives with a calculator. The conclusion is as banal as all the other fluff thought pieces.
I still think learning to code, then learning engineering (i.e solving problems using rules of thumb) is crucial before any of agentic coding being sold these days. & lastly having taste - making sure you're not just accepting any library that the llm suggests