What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?

Or the fact that you can't do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?

"languages are just tools" and "use the right tool for the job" were already stupid catch phrases. Pretending languages don't matter is a big further step into this shallow faux-intellectualism masquerading as wisdom.

And we didn't even get to low level stuff yet.

I wrote a draft of a service that would take hours to complete. when I optimized it for multithreaded operation instead of taking hours it took around 60 seconds.

write software like you write research papers. first draft > second draft > final draft > publication

yeah, sometimes it feels like the same people complaining about python speed are the ones writing "C" code in python.

I wrote a program in Python to read some huge Json files. It took forever to finish. Turned out I could optimize it with some simple changes, which reduced 10 minutes to 10 seconds (not literally, just figurative) and made a difference in huge files only. Later I rewrote the program in Rust. And you know what happened? It was slower than the Python version. Only after understanding what I was doing and making right changes made the Rust version faster.

Most of the time its the design of the code or libraries that slows down. The language might play a huge role in performance, but it depends on what type of code and application it is.

I actually wanted write a blog post about this... if I still have the project data I might explain what happened. BTW this had nothing to do with Ai.

I'd argue a combination of bad design and/or bad implementation, which i would consider different things.

It's a difference that becomes more pronounced the larger the team grows.

A somewhat reasonable design can be absolutely destroyed by a poor implementation of that design

SQLite > pgsql

Disagree. Different tools for different jobs.

I always wonder who is the target audience of such shallow fallacy-filled pretend-insightful faux-wisdom. But then I remember that most people waste a lot of time following aggregator/discussion sites are young impressionable enthusiasts who don't know much.

If you think about it, this was also true in the 80s, but because the hardware sucked. Good thing we learned better design so we can have things like AI

Compare frameworks more than languages.

Hyper > Gin > FastAPI > NextJS > Laravel > Drupal

Qt > GTK > Tauri > Fyne > Wails > Electron > React Native

Sqlite ~ Pgsql > mariadb

One docker container > ten micro services

Environment variables > ini > database config table

Edit: voters have spoken sqlite and pg are now on equal footing.

I respectfully disagree on all three points. You might be right about salary if only because more can be done with fewer devs. I think there is a huge limit on what can be done with vibe coding. The spec must exist and either you do it or the ai guesses and even the best models guess poorly. The code looks right because you aren't aware of the decisions made and the code holds together based on decisions you don't know about. Only later you realize the agent chose poorly.

In my experience. I'm actually really excited about ai, but I'm very aware of the limitations.

But you still have to know what to do.

Today, sure. Kinda. I do tell the AI exactly what to do and I correct its bad decisions sometimes. But...

1. If I didn't do that, I think the results would still be reasonable. Just not quite as good, but I am a perfectionist. Probably most people wouldn't care.

2. The skill required to guide AI is obviously way lower than the skill required to actually program. Salaries will drop, even if we don't actually lose our jobs.

3. We're talking about today. Vibe coding has only really worked well for a couple of months. The puck is moving.

I kinda buy the 70% claim, mostly because lots of old CMS systems are built using PHP some of which are still extremely popular like wordpress.

This is TypeScript, diesel is Rust.

It passes full PostgreSQL test suite. I'm trying to put it on a solid foundation.

To be honest, I didn't have much faith in vibe-coded projects either, but my belief has grown stronger as I've seen more potential projects.

Also, don't assume I'm completely unfamiliar with the code. I've done the planning, chosen the project structure, and reviewed a significant portion (though perhaps superficially) of what I considered important.

If you’re using quotes around your own terms and preemptively closing any discussion about it, then you’ve already lost.

This is exactly what the article is trying to argue, in the authors own words, he wants a "meaningful conversation". As for the quotes, it's challenging the claim that "coding is largely solved", as made by Boris Cherny at Anthropic, by dissecting what is meant by both "coding" and "solved".

Which list? I searched the Multi Ultimate Full list and it wasn't there.

Step 5. you inject poison in your burger and send it back. Causing the cook to die and you take over as the owner of the restaurant

I don't understand what this post is trying to achieve.

Dam, I guess I was a programmer at KFC, and I didn't even know it...

CSS didn't do shit wrong:

http://bettermotherfuckingwebsite.com/

Code is a tool, not a problem.

If you're using quotes around your own terms and preemptively closing any discussion about it, then you've already lost.

Stop feeding the grift with this nonsense.

I agree. I recently chatted with an ex-dev manager who tasked two of his devs with coding a new feature entirely through AI. They succeeded, but lamented that they had pages and pages of prompt to get it right. "You guys have rediscovered the concept of a 'design doc'," he told them.

It's vaguely the same, though. We are abstracting technical language via natural language, but the details still have to be provided in some way. Leaving it to the AI to infer only works for very tiny things where ambiguity is low. For big things you have this ocean of slop because the AI still needs every detail specified else it will make shit decisions based on shit inferences.

I think a dev harness such as the one my company is trying to create is nothing more than trying to get the AI to make zero decisions and ask about even the slightest ambiguity — as it should.

So you wind up with an excruciatingly long detailed natural language spec that consumes boatloads of tokens and is impossible for a human to read through only to produce the exact same thing translated into code.

From that perspective, it's just an abstraction layer. A very sloppy one.

I used this https://github.com/hagezi/dns-blocklists#listlookup and searched https://motherfuckingwebsite.com

If you search the closed github issues, you'll see more details for the url

It’s just so they can get dependencies out in the wild and then they add malicious code. This is why we should all learn to code… simply so we can stop being lazy and write our own is_even functions.