Hacker News Reader

Comment by superkuh | Hacker News Reader

That's modern python. There's really no single stable python to target anymore. Only pythons. Every project requires you to set up a container in which you just create a custom python specifically for that project.

Breaking feature removal is more of the same spirit. These are the consequences of popularity and rapid progress. Perl would never be forced into a corner like this and chose to break things.

View on HN

After over a decade of Python as my language of choice, I have stopped developing new projects with it, directly as a result of its instability through releases. Bit rot is a thing, and Python routinely causes more than seems reasonable.

What alternative(s) are you using instead?

I begrudgingly have moved to Go. Mostly because my current day job uses it a lot, so I have been paid to pick up more knowledge about its ecosystem.

Don’t get me wrong: there are plenty of things to dislike about it (or any language, once you start pulling that thread). However, they have made a much stronger commitment to avoid breaking backward compatibility.

Really? I even ported 2.7 code back when 3.6 got good, and it was all far simpler than I had dreaded.

I might be not as eager as some to learn new features though, but I am also not so conservative that I won't do things some new way, especially if the old way is being deprecated (but so far warnings have always given me plenty of heads up).

Quite the opposite, I like Python as much as I did when we first met. Nothing is without warts, but they are rarely really problematic for me in Python.

If your energy levels drop, or you lose interest, ports will become harder.

When you write code that has a short life span none of this matters. But when your software has a several year or decade life expectancy it will matter.

Also economics plays a role. If we have a real economic downturn in IT bit rot will become a huge problem for many small businesses.

If any effort is too much, you're basically stuck on a very select set of dead-ish languages or dialects thereof. But I'm not sure that's a more viable approach then using a language that is still pretty great about backwards compatibility.

2.x era python also had rolling deprecations and removals, so I thought it was a bit similar. For example in 2.5:

> The old regex and regsub modules, which have been deprecated ever since Python 2.0, have finally been deleted. Other deleted modules: statcache, tzparse, whrandom.

https://docs.python.org/3/whatsnew/2.5.html#new-improved-and...

I’m going to have to start specifically version pinning and vendoring pythons at some point.

What’s really funny is my older Python2 code doesn’t shit the bed half as much as the Python3 stuff due to it effectively being frozen in time.

What alternatives are there to Python for general, versatile backend scripting?

Any language that becomes a popular replacement will eventually suffer the same fate. It's the popularity and rapid "improvements" that cause this.

Bash and Perl?

Unironically yes - with a good shellcheck setup and a good local wiki of documented utility functions I’ve found bash to be an absolute powerhouse for writing portable code.

I’ve not used Perl as much in the last decade as I used to, but I’m always pleasantly surprised when I dig up some older stuff and it just works.

That's my main jam lately - shellcheck + shfmt + bash-lsp is a fantastic toolbox.

Ruby has managed to be incredibly self-compatible while adding new features for many many years now. Its main weakness compared to Python is its performance but that’s been steadily improving every year with each new (backwards compatible) Ruby release. And for 99% of apps it’s fast enough.

I always found Ruby super picky about specific versions, hence having shitloads of configs for rvm to use a specific version for each project.

Personal PowerShell

Even nodejs doesn’t do wild shit like this.

Sure it does. I'm still dealing with the fallout of old projects built with old webpack which uses md4 (as a file name cache buster only!) which is gone in recent nodejs+openssl binaries.

That sounds like a horrible design decision. I was using md5s in 2006 which was years before nodejs even existed.

You’re wildly overestimating the impact of this, but if you actually use Node you’ll learn two things: deprecations do happen (just look at the release notes!) but to the extent that you could say it doesn’t that would only be because Node doesn’t have a large stdlib and so the code you need to replace wasn’t deprecated by the core developers but rather the thousands of third-party modules’ maintainers. Either way you can’t ignore maintenance needs but I’ve found it to require more work in the latter model since the schedules aren’t synchronized.

Reply on news.ycombinator.com