DEV Community: ehsan mokhtary

Python Won’t Die. Its Biggest Selling Point Might.

ehsan mokhtary — Thu, 08 Oct 2026 05:44:22 +0000

If AI writes the code, “easy to write” becomes a strange reason to choose a programming language.

Here’s a prediction that will annoy developers: we may be approaching the end of choosing programming languages primarily for the convenience of the person typing them.

For years, we’ve celebrated languages that let us express more with less effort. Cleaner syntax. Less boilerplate. Faster prototypes. Fewer things to remember.

Those advantages mattered when turning an idea into code consumed a large part of our attention.

But what happens if AI handles much of that translation?

If a machine can produce the verbose version, the convenience of writing the short version loses some of its value.

That doesn’t mean Python is dead. It means “Python is easy to write” could become a much weaker argument.

Your favourite syntax may be solving yesterday’s problem

Imagine choosing between two languages.

One is pleasant to write but leaves more mistakes to be discovered while the program runs. The other requires more explicit structure but catches more mistakes before deployment.

When humans write every line, that extra structure can feel expensive.

When AI generates the first draft, the calculation changes.

Perhaps we should welcome the boilerplate if it makes assumptions visible. Perhaps the compiler asking awkward questions is doing exactly what we need when a machine can generate plausible code faster than we can review it.

In that future, the winning language might be the one that makes incorrect code hardest to accept.

The language that feels most convenient at the keyboard might lose to the language that gives generated software the tightest boundaries.

Code is becoming cheap. Confidence isn’t.

The provocative version of this argument is that developers are defending their favourite languages using a cost model that AI is changing.

We still ask:

“How quickly can I write this?”

The more useful question may become:

“How cheaply can I establish that this works—and keep it working?”

Those questions lead to different priorities.

A concise implementation is less impressive if reviewing its behaviour takes longer. A beautiful abstraction is less helpful if nobody can explain what happens when a dependency fails. A working demo means little if the next generated change silently breaks an assumption.

Typing fewer characters doesn’t solve those problems.

Neither does generating more characters.

Python deserves a better defence than “it’s easy”

Python is the obvious target because its accessibility is such a prominent part of its appeal.

But dismissing it would be lazy. Libraries, existing systems, integration requirements, and the people maintaining a project all matter. Replacing a working ecosystem because another language looks better on paper can be an expensive mistake.

The challenge is narrower—and more uncomfortable:

If your strongest argument for Python is that it saves human effort while writing code, how strong is that argument when AI does much of the writing?

Defend the ecosystem. Defend its suitability for your workload. Defend the speed at which your team can investigate and fix problems.

But “look how few lines this takes” may stop winning the debate.

The uncomfortable counterargument: humans still have to read it

This is where the prediction could fall apart.

If AI makes code abundant, readable code might become more valuable. Someone still has to investigate incidents, challenge assumptions, and approve changes.

A language that is easy to understand could reduce the cost of supervising AI—even if ease of writing matters less.

That distinction is crucial.

Easy to write is not the same as easy to verify.

Sometimes they overlap. Sometimes a short expression hides enough behaviour to make the reviewer’s job harder.

The future may reward human readability. It just might reward a different kind of readability: explicit contracts, visible effects, predictable behaviour, and fewer surprises.

Programming languages aren’t dying. Our reasons for choosing them need an update.

My bet is that AI shifts the competition between languages.

Less emphasis on saving keystrokes. More emphasis on catching mistakes.

Less admiration for a tiny implementation. More scrutiny of what it guarantees.

Less loyalty to whatever feels comfortable. More attention to the cost of running, reviewing, and changing the system.

There won’t be one universal winner. A data experiment, a mobile app, and a payment service have different constraints.

But developers who refuse to reconsider their language preferences may find themselves optimising a part of the job that no longer costs very much.

If AI writes your next 10,000 lines, would you choose the language that makes them easiest to generate—or the one that makes them hardest to get wrong?

This is a prediction, not a benchmark. I’m interested in counterexamples that challenge its argument.

AI disclosure: I developed the argument in conversation with AI, which helped draft and structure this article.

Inside XEvents: a Telegram event app built with JavaScript, Workers and D1

ehsan mokhtary — Thu, 08 Oct 2026 05:14:54 +0000

XEvents is a Telegram bot and Mini App for event creation, invitations, RSVP, tickets, check-in and shared media. I'm the maintainer, and the project is MIT licensed.

This article explains the current implementation and a few boundaries that matter when building a similar app.

See XEvents in action

These are actual app screens captured in an isolated local environment with fictional events and mocked Telegram calls. The animation is a sequence of screenshots, not a live Telegram recording. Capture details.

Two joining flows with different expectations

A shared booking link and a personal invitation look similar at first, but guests expect different things from them.

In XEvents, shared links let people book or request places, with organiser approval when configured. Named invitations offer Accept, Reject, Maybe and Respond later. They can include group counts, so a host can distinguish one invitation from the number of people attending.

Keeping these flows distinct helps the interface explain what the guest is actually doing. A booking request isn't an RSVP choice, and submitting a payment report isn't proof that a payment arrived.

One Worker serves the hosted application

The hosted app has three main pieces:

A Cloudflare Worker receives bot webhook updates and serves the Mini App and API.
D1 stores events, guest responses, preferences and coordination records.
Telegram hosts uploaded files; the application stores their references.

The frontend uses HTML, CSS and JavaScript modules. Node.js 22 or newer is used for development tools and the optional standalone polling bot. Polling mode is separate: it doesn't serve the hosted Mini App or share its D1 database.

Authentication is only the first check

Private Mini App API requests require signed Telegram launch data. The server verifies that identity, then checks whether the person owns the event, is a co-host or is an eligible guest.

That second check matters. A valid Telegram identity doesn't automatically grant access to another event's locations, guest information or media. The Worker filters private responses on the server; hiding a frontend button isn't enough.

Notifications need durable coordination

Bot operations can update attendance and queue outgoing messages. The application commits the changed records and outgoing messages together, then delivers the messages afterwards. A scheduled task retries queued messages and processes eligible reminders.

This improves delivery durability, but it doesn't establish exactly-once delivery. If a network response is lost after Telegram receives a message, a retry can duplicate it. The architecture guide makes that limitation explicit.

Short-lived check-in codes

Confirmed guests can request a six-digit check-in code. It expires at the next minute, and a refresh action requests another. The app generates codes on demand, rather than continually polling or scheduling code generation.

Organisers enter a code through the check-in keypad to check in the group. QR tickets are optional and start off for new events. Server-side checks still decide whether the ticket can be used.

Media and payments have practical limits

Attendees can share photos in one event collection with no built-in photo-count limit. Telegram and hosting limits apply.

Telegram-hosted media avoids a separate application media bucket, but it isn't an independent backup or unlimited storage promise. The Mini App limits full-file retrieval to 20 MB and offers Send to Telegram for larger files.

Paid events support organiser-reviewed manual payments and Telegram Stars. Direct card processing and automatic organiser payouts aren't implemented. Hosting and provider quotas still apply.

Explore the project

Try the bot: https://t.me/XEvents_bot (Telegram required).
Source: https://github.com/ehsan0921/Telegram-event-management
Architecture: https://github.com/ehsan0921/Telegram-event-management/blob/main/docs/architecture.md
Self-hosting: https://github.com/ehsan0921/Telegram-event-management/blob/main/docs/self-hosting.md

The project welcomes focused contributions, including documentation and accessibility improvements. If you organise club events or meetups, I'd like to hear where the invitation or guest-management experience needs work.

Disclosure: This article was prepared with AI assistance and checked against the project's source and documentation.